From joydeb at gmail.com  Mon Jan  2 02:06:14 2012
From: joydeb at gmail.com (Joydeb Roy)
Date: Mon, 2 Jan 2012 15:36:14 +0530
Subject: [rbridge] query regd. TRILL scenario
In-Reply-To: <CAOX+dHGbKhgDpo7CwV=dz8+8Gas-qCqYewY__7mZ-3i4c3ZBkw@mail.gmail.com>
References: <CAOX+dHGbKhgDpo7CwV=dz8+8Gas-qCqYewY__7mZ-3i4c3ZBkw@mail.gmail.com>
Message-ID: <CAOX+dHFCxF8yHvcwF7At9L=EyQHHA_c98ffUK=AoX0RQoW=CJQ@mail.gmail.com>

Hi Authors,



Please let me know if my understanding is proper in the below case. If yes,
then please clarify the doubts and if no, then please correct wherever
applicable.


Generally, RBridges learn about end stations on access ports and they
communicate with each other to form adjacency through trunk ports.  But if
we consider the following diagram ?


                                  +---------+
+---------+                       |   RB1   |
|   End   |        +-----+ ------ +---------+
|         | ------ | Hub |
| Station |        +-----+ ------ +---------+
+---------+                       |   RB2   |
                                  +---------+


How do the involved ports in RB1 and RB2 behave in this case? Do both of
them manage to learn about the End Station and one of them becomes the DRB
based upon the configured priorities? Also, do they manage to form an
adjacency between them? If so, then how do they manage so in spite of the
ports being designated as access?



Thank you.



Best regards

Joy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120102/481e89be/attachment.html

From d3e3e3 at gmail.com  Mon Jan  2 06:21:24 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 2 Jan 2012 09:21:24 -0500
Subject: [rbridge] query regd. TRILL scenario
In-Reply-To: <CAOX+dHFCxF8yHvcwF7At9L=EyQHHA_c98ffUK=AoX0RQoW=CJQ@mail.gmail.com>
References: <CAOX+dHGbKhgDpo7CwV=dz8+8Gas-qCqYewY__7mZ-3i4c3ZBkw@mail.gmail.com>
	<CAOX+dHFCxF8yHvcwF7At9L=EyQHHA_c98ffUK=AoX0RQoW=CJQ@mail.gmail.com>
Message-ID: <CAF4+nEHttX5teCwOQb22N8orKDjjCb5isTB6=mu0xYg1EMhHxA@mail.gmail.com>

Hi Joybed,

On Mon, Jan 2, 2012 at 5:06 AM, Joydeb Roy <joydeb at gmail.com> wrote:
> Hi Authors,
>
> Please let me know if my understanding is proper in the below case. If yes,
> then please clarify the doubts and if no, then please correct wherever
> applicable.
>
> Generally, RBridges learn about end stations on access ports and they
> communicate with each other to form adjacency through trunk ports. ?But if
> we consider the following diagram ?

TRILL tries to be zero/minimum configuration. So by default, RBridge
ports are universal ports that can handle both native and TRILL Data
frames. RBridge access and trunk ports are ports that have been
configured to restrict them. While this is commonly a good idea, it is
not necessary for correct operation.

In any case, TRILL Hellos are always sent out RBridge ports unless the
port is disabled or configured as point-to-point (in which case
point-to-point Hellos get sent on them).

> ????????????????????????????????? +---------+
> +---------+?????????????????????? |?? RB1?? |
> |?? End?? |??????? +-----+ ------ +---------+
> |???????? | ------ | Hub |
> | Station |??????? +-----+ ------ +---------+
> +---------+?????????????????????? |?? RB2?? |
> ????????????????????????????????? +---------+
>
> How do the involved ports in RB1 and RB2 behave in this case? Do both of
> them manage to learn about the End Station and one of them becomes the DRB
> based upon the configured priorities? Also, do they manage to form an
> adjacency between them? If so, then how do they manage so in spite of the
> ports being designated as access?

As above, TRILL Hellos are still sent out the ports of RB1 & RB2
whether or not the "access port" configuration bit has been turned on
for those ports. So they form an adjacency and one is elected DRB on
the link. By default, the DRB will handle all the native traffic
to/from the End Station. The other RBridge will see all that traffic
but will throw it away because by default it is not the Appointed
Forwarder for any VLAN on the link. However, the DRB can assign some
or all VLANs to the non-DRB RBridge as Appointed Forwarder.

> Thank you.
>
> Best regards
> Joy

Hope the above helps.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From d3e3e3 at gmail.com  Mon Jan  2 19:31:44 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 2 Jan 2012 22:31:44 -0500
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-01.txt
In-Reply-To: <004b01ccc3c9$938f32e0$baad98a0$@com>
References: <20111222170804.19780.64895.idtracker@ietfa.amsl.com>
	<CAF4+nEHvSkBnek-KSPwOboucL4XPnLRoweQX0db-K8LrtK++pA@mail.gmail.com>
	<004b01ccc3c9$938f32e0$baad98a0$@com>
Message-ID: <CAF4+nEEdphOKes7fHZ+Sr5LB87q3xWp4uYenjWUK2xHa9YUvBg@mail.gmail.com>

Hi Yizhou,

On Mon, Dec 26, 2011 at 7:26 AM, Yizhou Li <liyizhou at huawei.com> wrote:
> Hi Donald,
>
> Some comments and thoughts when I read the draft,
>
> 1. pg4, right below bullets
> ? "Any RBridge receiving a frame with a critical hop-by-hop extension
> ? that it does not implement MUST discard the frame because it is
> ? unsafe to process the frame without understanding such a critical
> ? extension. Any egress RBridge receiving a frame with a critical
> ? ingress-to-egress or hop-by-hop extension it does not implement MUST
> ? drop the frame if it is a known unicast frame; if it is a multi-
> ? destination TRILL Data frame, then it MUST NOT be egressed at that
> ? RBridge but it is still forwarded on the distribution tree. Non-
> ? critical extensions can be safely ignored."
>
> It is unclear to me what a RB should do if it receives a multi-destination
> frame with a critical hop-by-hop extension that it does not implement?
> 1st sentence suggests to discard it and the end of second last sentence
> suggests to forward it on the tree?
> Suggest to remove "or hop-by-hop" in 2nd sentence.

Good point. I will remove "or hop-by-hop" and probably split the
paragraph in to three paragraphs, one on hop-by-hop critical, one on
ingress-egress critical, and one on non-critical.

> 2. pg5, L3, "some such frames them to be" -> some of them to be

OK.

> 3. pg7, section 2.3.1,
> Can we call "extensions after the first word in the extensions area" to be
> "TLV extensions"?

I would prefer to leave the wording as is. In the
draft-ietf-trill-rbridge-options working group draft, there is already
one additional word of non-TLV extension described...

> Another general comment, use a table to show the whole extension area
> structure which contains the Extension Header Flags as that in section 2.3
> and the optional non-flag TLV extensions which is 32-bit aligned.

I could extend that digram and adjust the wording a bit so it is
clearer how the word of flags fits in the TRILL Header extension
area... Something like this:

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.|  CHbH   |   NCHbH   |CRSV | NCRSV |   CItE    |  NCItE  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... additional optional 32-bit aligned words of extension     |
|     including TLV extensions ...

> 4. pg4, bottom, Note section.
> I think there is mixture of slow path & fast path case if future hardware
> can support certain flag directly, e.g. some flag requires forwarding the
> frame in data plane as normal and copy it to the control plane for further
> processing at the same time.

While that could happen for some assortments of options and hardware
support, this note is just a general warning to be cautious in using
extensions. I don't think it needs to be more complicated.

> 5. pg10, section 3. Table 1. Extended Header Flags Area
> Suggest to define bit 3 for a critical hop-by-hop RBridge Channel Alert
> Flag. It may be useful in assisting some channel features, like the source
> routing with strict path specified.

I think including such a flag a good idea. I'll add it unless there
are objections, probably as bit 7 so it is adjacent to the
non-critical Channel Alert Flag currently defined in the draft.

> 6. pg8, section 2.4
> Better to explicitly state that the conflicts may not be resolved to achieve
> the same consequence at every transit RB for a single data frame even
> following the rules described. It highly depends on the capability that an
> RB can support.

OK.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> Thanks,
> Yizhou
>
>
> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
> Behalf Of Donald Eastlake
> Sent: Friday, December 23, 2011 1:18 AM
> To: rbridge at postel.org
> Subject: Re: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-01.txt
>
> This revision just has editorial changes and author information update.
>
> Thanks,
> Donald
> =============================
> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
> ?155 Beaver Street,?Milford, MA 01757 USA
> ?d3e3e3 at gmail.com
>
> On Thu, Dec 22, 2011 at 12:08 PM, ?<internet-drafts at ietf.org> wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Transparent Interconnection of
> Lots of Links Working Group of the IETF.
>>
>> ? ? ? ?Title ? ? ? ? ? : TRILL: Header Extension
>> ? ? ? ?Author(s) ? ? ? : Donald Eastlake
>> ? ? ? ? ? ? ? ? ? ? ? ? ?Anoop Ghanwani
>> ? ? ? ? ? ? ? ? ? ? ? ? ?Vishwas Manral
>> ? ? ? ? ? ? ? ? ? ? ? ? ?Caitlin Bestler
>> ? ? ? ?Filename ? ? ? ?: draft-ietf-trill-rbridge-extension-01.txt
>> ? ? ? ?Pages ? ? ? ? ? : 16
>> ? ? ? ?Date ? ? ? ? ? ?: 2011-12-22
>>
>> ? The TRILL base protocol standard specifies minimal hooks to safely
>> ? support TRILL Header extensions. This document specifies an initial
>> ? extension providing additional flag bits and specifies one of those
>> ? bits.
>>
>>
>>
>> A URL for this Internet-Draft is:
>>
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-01.tx
> t
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>>
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-01.txt
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>


From joydeb at gmail.com  Mon Jan  2 22:51:57 2012
From: joydeb at gmail.com (Joydeb Roy)
Date: Tue, 3 Jan 2012 12:21:57 +0530
Subject: [rbridge] query regd. TRILL scenario
In-Reply-To: <CAF4+nEHttX5teCwOQb22N8orKDjjCb5isTB6=mu0xYg1EMhHxA@mail.gmail.com>
References: <CAOX+dHGbKhgDpo7CwV=dz8+8Gas-qCqYewY__7mZ-3i4c3ZBkw@mail.gmail.com>
	<CAOX+dHFCxF8yHvcwF7At9L=EyQHHA_c98ffUK=AoX0RQoW=CJQ@mail.gmail.com>
	<CAF4+nEHttX5teCwOQb22N8orKDjjCb5isTB6=mu0xYg1EMhHxA@mail.gmail.com>
Message-ID: <CAOX+dHF=2oXm63YV71fM-BfFYq1u-73p2oZB1bUD9Ys_gcfqpw@mail.gmail.com>

Hi Donald,

Thanks a lot for your reply. The understanding is indeed much better now.
Just another query though regarding the AVF part you mentioned in your
comments -

Now, I understand that the default the DRB will carry all the traffic to
and fro the end-user. But when the DRB does decide to distribute the
traffic to other rbridges then what propels it to make that decision?

The last sentence of the Section 2.2 from the RFC 6439 states -

"How the DRB decides what other RBridges on the link, if any, to appoint
forwarder for which VLANs is beyond the scope of this document."

So, is there any other standard document that I can refer to? Is the
behavior totally dynamic in nature e.g. the DRB takes such decision through
the usage of some algorithm? Or should it be configurable, so that the
Network Admin takes the last call?

Thank you.

Best regards
Joy

On Mon, Jan 2, 2012 at 7:51 PM, Donald Eastlake <d3e3e3 at gmail.com> wrote:

> Hi Joybed,
>
> On Mon, Jan 2, 2012 at 5:06 AM, Joydeb Roy <joydeb at gmail.com> wrote:
> > Hi Authors,
> >
> > Please let me know if my understanding is proper in the below case. If
> yes,
> > then please clarify the doubts and if no, then please correct wherever
> > applicable.
> >
> > Generally, RBridges learn about end stations on access ports and they
> > communicate with each other to form adjacency through trunk ports.  But
> if
> > we consider the following diagram ?
>
> TRILL tries to be zero/minimum configuration. So by default, RBridge
> ports are universal ports that can handle both native and TRILL Data
> frames. RBridge access and trunk ports are ports that have been
> configured to restrict them. While this is commonly a good idea, it is
> not necessary for correct operation.
>
> In any case, TRILL Hellos are always sent out RBridge ports unless the
> port is disabled or configured as point-to-point (in which case
> point-to-point Hellos get sent on them).
>
> >                                   +---------+
> > +---------+                       |   RB1   |
> > |   End   |        +-----+ ------ +---------+
> > |         | ------ | Hub |
> > | Station |        +-----+ ------ +---------+
> > +---------+                       |   RB2   |
> >                                   +---------+
> >
> > How do the involved ports in RB1 and RB2 behave in this case? Do both of
> > them manage to learn about the End Station and one of them becomes the
> DRB
> > based upon the configured priorities? Also, do they manage to form an
> > adjacency between them? If so, then how do they manage so in spite of the
> > ports being designated as access?
>
> As above, TRILL Hellos are still sent out the ports of RB1 & RB2
> whether or not the "access port" configuration bit has been turned on
> for those ports. So they form an adjacency and one is elected DRB on
> the link. By default, the DRB will handle all the native traffic
> to/from the End Station. The other RBridge will see all that traffic
> but will throw it away because by default it is not the Appointed
> Forwarder for any VLAN on the link. However, the DRB can assign some
> or all VLANs to the non-DRB RBridge as Appointed Forwarder.
>
> > Thank you.
> >
> > Best regards
> > Joy
>
> Hope the above helps.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120103/5d4c1fa1/attachment.html

From d3e3e3 at gmail.com  Thu Jan  5 11:20:19 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 5 Jan 2012 14:20:19 -0500
Subject: [rbridge] Taipei Minutes Posted
Message-ID: <CAF4+nEGhF85qn4+HmwZw-35e+j_2Dkgx82g1kX1by31rJsNXAQ@mail.gmail.com>

The Taipei TRILL WG minutes have been posted to the IETF-82 meeting
material page.

My apologies for getting these out way late.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From tsenevir at cisco.com  Thu Jan  5 18:11:55 2012
From: tsenevir at cisco.com (Tissa Senevirathne (tsenevir))
Date: Thu, 5 Jan 2012 18:11:55 -0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
	active-active edge and more
Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A55CD019@xmb-sjc-214.amer.cisco.com>

Dear All

 

We have published draft-tissa-trill-cmt-00.txt, in this document we
present a flexible framework to associate child RBridges to different
parent RBRidges for RPF purpose.

 

Active-active forwarding at the TRILL edge is a very important feature.
Representation of the active-active sub system with a single virtual
RBRidge is a common practice to achieve load balancing and to avoid MAC
flip flop. However, use of virtual RBridge lead to RPF failures. In this
document we provide a solution to address the RPF failures. Please
review and share comments.

 

ID can be found in URL:
http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt

 

Summary:

 

Filename:   draft-tissa-trill-cmt

Revision:   00

Title:            Coordinated Multicast Trees (CMT)for TRILL

Creation date:    2012-01-05

WG ID:            Individual Submission

Number of pages: 14

 

Abstract:

   TRILL facilitates loop free connectivity to non TRILL legacy

   networks via choice of an Appointed Forwarder for set of VLANs.

   Appointed Forwarder provides VLAN level load sharing with active-

   standby model. Mission critical operations such as High Performance

   Data Centers require active-active load sharing model. Active-Active

   load sharing model can be accomplished by representing any given non

   TRILL legacy network with a single virtual RBridge. Virtual

   representation of the non-TRILL legacy network with a single RBridge

   poses serious challenges in multi-destination RPF calculations. This

   document presents the required enhancements to build Coordinated

   Multicast Trees (CMT) within the TRILL campus. CMT provides

   flexibility to RBridges to select desired path of association to a

   given distribution tree.

 

 

Thanks

Tissa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120105/8163c5f2/attachment.html

From tsenevir at cisco.com  Fri Jan  6 11:08:17 2012
From: tsenevir at cisco.com (Tissa Senevirathne (tsenevir))
Date: Fri, 6 Jan 2012 11:08:17 -0800
Subject: [rbridge] draft-tissa-trill-oam-03
Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A55CD199@xmb-sjc-214.amer.cisco.com>

Dear All

 

We have published -03 of draft-tissa-trill-oam. -03 contain following
changes

 

1.       Include payload discovery for ECMP path coverage

2.       Traffic Triggered Monitoring - A Framework for use of live
traffic for monitoring and troubleshooting in TRILL networks

3.       Hop-count method for Ping

4.       Other editorial changes/corrections

 

Please share your comments.

 

Thanks

Tissa

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120106/eccd1d11/attachment.html

From d3e3e3 at gmail.com  Fri Jan  6 19:05:56 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 6 Jan 2012 22:05:56 -0500
Subject: [rbridge] query regd. TRILL scenario
In-Reply-To: <CAOX+dHF=2oXm63YV71fM-BfFYq1u-73p2oZB1bUD9Ys_gcfqpw@mail.gmail.com>
References: <CAOX+dHGbKhgDpo7CwV=dz8+8Gas-qCqYewY__7mZ-3i4c3ZBkw@mail.gmail.com>
	<CAOX+dHFCxF8yHvcwF7At9L=EyQHHA_c98ffUK=AoX0RQoW=CJQ@mail.gmail.com>
	<CAF4+nEHttX5teCwOQb22N8orKDjjCb5isTB6=mu0xYg1EMhHxA@mail.gmail.com>
	<CAOX+dHF=2oXm63YV71fM-BfFYq1u-73p2oZB1bUD9Ys_gcfqpw@mail.gmail.com>
Message-ID: <CAF4+nEFmv3i8XdMjx1ZFBch2QPkdMG8o_kCRTKgad+Q74DKz1w@mail.gmail.com>

Hi Joydeb,

On Tue, Jan 3, 2012 at 1:51 AM, Joydeb Roy <joydeb at gmail.com> wrote:
> Hi Donald,
>
> Thanks a lot for your reply. The understanding is indeed much better now.
> Just another query though regarding the AVF part you mentioned in your
> comments -
>
> Now, I understand that the default the DRB will carry all the traffic to and
> fro the end-user. But when the DRB does decide to distribute the traffic to
> other rbridges then what propels it to make that decision?
>
> The last sentence of the Section 2.2 from the RFC 6439 states -
>
> "How the DRB decides what other RBridges on the link, if any, to appoint
> forwarder for which VLANs is beyond the scope of this document."
>
> So, is there any other standard document that I can refer to? Is the
> behavior totally dynamic in nature e.g. the DRB takes such decision through
> the usage of some algorithm? Or should it be configurable, so that the
> Network Admin takes the last call?

I kind of think of how the DRB decides what forwarders to appoint as
an area where implementors can display their individual brilliance :-)

Seriously, there are a lot of factors that could be used in such
decisions. I don't see how it could be standardized. But you might
look at draft-zhang-trill-vlan-assign-02.txt and at Section 10.2 of
draft-eastlake-trill-rbridge-clear-correct-02.txt.

By the way, in connection with your previous question, you might look
at Section 6 of draft-eastlake-trill-rbridge-clear-correct-02.txt.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> Thank you.
> Best regards
> Joy
>
> On Mon, Jan 2, 2012 at 7:51 PM, Donald Eastlake <d3e3e3 at gmail.com> wrote:
>>
>> Hi Joybed,
>>
>> On Mon, Jan 2, 2012 at 5:06 AM, Joydeb Roy <joydeb at gmail.com> wrote:
>> > Hi Authors,
>> >
>> > Please let me know if my understanding is proper in the below case. If
>> > yes,
>> > then please clarify the doubts and if no, then please correct wherever
>> > applicable.
>> >
>> > Generally, RBridges learn about end stations on access ports and they
>> > communicate with each other to form adjacency through trunk ports. ?But
>> > if
>> > we consider the following diagram ?
>>
>> TRILL tries to be zero/minimum configuration. So by default, RBridge
>> ports are universal ports that can handle both native and TRILL Data
>> frames. RBridge access and trunk ports are ports that have been
>> configured to restrict them. While this is commonly a good idea, it is
>> not necessary for correct operation.
>>
>> In any case, TRILL Hellos are always sent out RBridge ports unless the
>> port is disabled or configured as point-to-point (in which case
>> point-to-point Hellos get sent on them).
>>
>> > ????????????????????????????????? +---------+
>> > +---------+?????????????????????? |?? RB1?? |
>> > |?? End?? |??????? +-----+ ------ +---------+
>> > |???????? | ------ | Hub |
>> > | Station |??????? +-----+ ------ +---------+
>> > +---------+?????????????????????? |?? RB2?? |
>> > ????????????????????????????????? +---------+
>> >
>> > How do the involved ports in RB1 and RB2 behave in this case? Do both of
>> > them manage to learn about the End Station and one of them becomes the
>> > DRB
>> > based upon the configured priorities? Also, do they manage to form an
>> > adjacency between them? If so, then how do they manage so in spite of
>> > the
>> > ports being designated as access?
>>
>> As above, TRILL Hellos are still sent out the ports of RB1 & RB2
>> whether or not the "access port" configuration bit has been turned on
>> for those ports. So they form an adjacency and one is elected DRB on
>> the link. By default, the DRB will handle all the native traffic
>> to/from the End Station. The other RBridge will see all that traffic
>> but will throw it away because by default it is not the Appointed
>> Forwarder for any VLAN on the link. However, the DRB can assign some
>> or all VLANs to the non-DRB RBridge as Appointed Forwarder.
>>
>> > Thank you.
>> >
>> > Best regards
>> > Joy
>>
>> Hope the above helps.
>>
>> Thanks,
>> Donald
>> =============================
>> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
>> ?155 Beaver Street,?Milford, MA 01757 USA
>> ?d3e3e3 at gmail.com
>
>


From internet-drafts at ietf.org  Mon Jan  9 05:20:58 2012
From: internet-drafts at ietf.org (internet-drafts@ietf.org)
Date: Mon, 09 Jan 2012 05:20:58 -0800
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.txt
Message-ID: <20120109132058.9151.5560.idtracker@ietfa.amsl.com>


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : TRILL: Header Extension
	Author(s)       : Donald Eastlake
                          Anoop Ghanwani
                          Vishwas Manral
                          Yizhou Li
                          Caitlin Bestler
	Filename        : draft-ietf-trill-rbridge-extension-02.txt
	Pages           : 16
	Date            : 2012-01-09

   The IETF TRILL (Transparent Interconnection of Lots of Links) base
   protocol specifies minimal hooks to safely support TRILL Header
   extensions. This document specifies an initial extension providing
   additional flag bits and specifies two of those bits.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-02.txt



From d3e3e3 at gmail.com  Mon Jan  9 20:18:44 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 9 Jan 2012 23:18:44 -0500
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-extension-02.txt
In-Reply-To: <20120109132058.9151.5560.idtracker@ietfa.amsl.com>
References: <20120109132058.9151.5560.idtracker@ietfa.amsl.com>
Message-ID: <CAF4+nEHFEMYgv=XO0DDYv7pDx0GR8T_wnuemBu-NzsvZwMgHpw@mail.gmail.com>

This version incorporates change discussed on the WG mailing list.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


On Mon, Jan 9, 2012 at 8:20 AM,  <internet-drafts at ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.
>
> ? ? ? ?Title ? ? ? ? ? : TRILL: Header Extension
> ? ? ? ?Author(s) ? ? ? : Donald Eastlake
> ? ? ? ? ? ? ? ? ? ? ? ? ?Anoop Ghanwani
> ? ? ? ? ? ? ? ? ? ? ? ? ?Vishwas Manral
> ? ? ? ? ? ? ? ? ? ? ? ? ?Yizhou Li
> ? ? ? ? ? ? ? ? ? ? ? ? ?Caitlin Bestler
> ? ? ? ?Filename ? ? ? ?: draft-ietf-trill-rbridge-extension-02.txt
> ? ? ? ?Pages ? ? ? ? ? : 16
> ? ? ? ?Date ? ? ? ? ? ?: 2012-01-09
>
> ? The IETF TRILL (Transparent Interconnection of Lots of Links) base
> ? protocol specifies minimal hooks to safely support TRILL Header
> ? extensions. This document specifies an initial extension providing
> ? additional flag bits and specifies two of those bits.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-extension-02.txt


From nordmark at acm.org  Tue Jan 10 05:10:44 2012
From: nordmark at acm.org (Erik Nordmark)
Date: Tue, 10 Jan 2012 05:10:44 -0800
Subject: [rbridge] Should we make draft-eastlake-trill-clear-correct-03.txt
	a WG document?
Message-ID: <4F0C38D4.7050801@acm.org>


Donald presented this document in Taipei, and the authors have revised 
it since then.

I think the document contains useful clarifications. Should we adopt it 
as a WG document?

Please send any comments to the list before January 25th.

    Erik

From mgururam at gmail.com  Tue Jan 10 20:20:38 2012
From: mgururam at gmail.com (gururam m)
Date: Wed, 11 Jan 2012 09:50:38 +0530
Subject: [rbridge] TRILL Multicast Query
Message-ID: <CADaSLpUvZ=wex6EnOaVonYySQv-5WE66TUFszFP1ABgZers3JQ@mail.gmail.com>

What are the RFCs/drafts that define the TRILL multicast support

Regards
Ram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120111/74191417/attachment.html

From d3e3e3 at gmail.com  Tue Jan 10 20:50:58 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 10 Jan 2012 23:50:58 -0500
Subject: [rbridge] TRILL Multicast Query
In-Reply-To: <CADaSLpUvZ=wex6EnOaVonYySQv-5WE66TUFszFP1ABgZers3JQ@mail.gmail.com>
References: <CADaSLpUvZ=wex6EnOaVonYySQv-5WE66TUFszFP1ABgZers3JQ@mail.gmail.com>
Message-ID: <CAF4+nEEq+87rbfo9M-p+TtgPh5GQXxMh4q6+fdaA=TYG0O_mBw@mail.gmail.com>

Start with the base protocol specification, RFC 6325.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com



On Tue, Jan 10, 2012 at 11:20 PM, gururam m <mgururam at gmail.com> wrote:
>
> What are the RFCs/drafts that define the TRILL multicast support
>
> Regards
> Ram
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>


From zhai.hongjun at zte.com.cn  Thu Jan 12 19:58:44 2012
From: zhai.hongjun at zte.com.cn (zhai.hongjun@zte.com.cn)
Date: Fri, 13 Jan 2012 11:58:44 +0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
 active-active edge and more
In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A55CD019@xmb-sjc-214.amer.cisco.com>
Message-ID: <OF31ED4F06.D9817510-ON48257984.0005852D-48257984.0016013E@zte.com.cn>

Hi Tissa,

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In 
this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member 
RBdige of a virtual RBridge group much flexibity in describing the virtual 
RBridge nickname and  specifying the path of association to specific 
distribution tree(S).  However, this new TLV causes some backward 
compatibilty problems between pre Affinity sub-TLV RBridges and new 
RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL 
network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the 
virtual Rbridge nickname and  the specific distribution trees? Maybe it is 
not.

In a given vritual group, each  member Rbridge can advertise a specific 
pseudonode-LSP to annouce the virtual RBridge nickname and the trees 
assigned to it.The nickname and the assigned trees are contained in  the 
given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP 
represents a special virtual link, on which there is only one RBridge, 
i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge 
is assigned different tree(s), RPF check information for the virtual 
Rbrigde in different trees can be correctly calculated on all the Rbridges 
in TRILL network, then the member RBridge can safely use the virtual 
Rbridge nickname to do the necessary TRILL-encapsultion on  received 
native frames.

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is 
removed, while the similar flexibilty of Affinity sub-TLV remains.


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
发件人:  rbridge-bounces at postel.org
2012-01-06 10:11

收件人
<rbridge at postel.org>
抄送

主题
[rbridge] Coordinated Multicast Trees to solve RPF issues on active-active 
edge and more






Dear All
 
We have published draft-tissa-trill-cmt-00.txt, in this document we 
present a flexible framework to associate child RBridges to different 
parent RBRidges for RPF purpose.
 
Active-active forwarding at the TRILL edge is a very important feature. 
Representation of the active-active sub system with a single virtual 
RBRidge is a common practice to achieve load balancing and to avoid MAC 
flip flop. However, use of virtual RBridge lead to RPF failures. In this 
document we provide a solution to address the RPF failures. Please review 
and share comments.
 
ID can be found in URL: 
http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt
 
Summary:
 
Filename:   draft-tissa-trill-cmt
Revision:   00
Title:            Coordinated Multicast Trees (CMT)for TRILL
Creation date:    2012-01-05
WG ID:            Individual Submission
Number of pages: 14
 
Abstract:
   TRILL facilitates loop free connectivity to non TRILL legacy
   networks via choice of an Appointed Forwarder for set of VLANs.
   Appointed Forwarder provides VLAN level load sharing with active-
   standby model. Mission critical operations such as High Performance
   Data Centers require active-active load sharing model. Active-Active
   load sharing model can be accomplished by representing any given non
   TRILL legacy network with a single virtual RBridge. Virtual
   representation of the non-TRILL legacy network with a single RBridge
   poses serious challenges in multi-destination RPF calculations. This
   document presents the required enhancements to build Coordinated
   Multicast Trees (CMT) within the TRILL campus. CMT provides
   flexibility to RBridges to select desired path of association to a
   given distribution tree.
 
 
Thanks
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120113/1a9291df/attachment.html

From tsenevir at cisco.com  Thu Jan 12 20:21:26 2012
From: tsenevir at cisco.com (Tissa Senevirathne (tsenevir))
Date: Thu, 12 Jan 2012 20:21:26 -0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
	active-active edge and more
In-Reply-To: <OF31ED4F06.D9817510-ON48257984.0005852D-48257984.0016013E@zte.com.cn>
References: <344037D7CFEFE84E97E9CC1F56C5F4A55CD019@xmb-sjc-214.amer.cisco.com>
	<OF31ED4F06.D9817510-ON48257984.0005852D-48257984.0016013E@zte.com.cn>
Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A56556C6@xmb-sjc-214.amer.cisco.com>

Hi Hongjun

 

I am not quite clear with the way you are proposing to use assigned nicknames in the pseudonode LSP.

 

Can you please us the diagram below and explain how your proposal will be used. 

 

CE means in the following diagram is an 802.1D device that is attached to RB1 and RB2 through Pt-Pt links and treated as a port channel from CE stand point.

 

                                   RBx

                                     |

                           Trill Campus

               |                                              |

    +----------+                                   +------------+

    |  RB1     |                                  |  RB2       |

    +----------+                                  + ------------+

          \                                                  /

           \                                               /

            \                                            /

              ----------               -----------

                      >   |             |  <  Port channel (LAG)

                           |             |

                    +--------------------+

                   |    CE                    |

                   +---------------------+

 

 

From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

 


Hi Tissa, 

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member RBdige of a virtual RBridge group much flexibity in describing the virtual RBridge nickname and  specifying the path of association to specific distribution tree(S).  However, this new TLV causes some backward compatibilty problems between pre Affinity sub-TLV RBridges and new RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the virtual Rbridge nickname and  the specific distribution trees? Maybe it is not. 

In a given vritual group, each  member Rbridge can advertise a specific pseudonode-LSP to annouce the virtual RBridge nickname and the trees assigned to it.The nickname and the assigned trees are contained in  the given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP represents a special virtual link, on which there is only one RBridge, i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge is assigned different tree(s), RPF check information for the virtual Rbrigde in different trees can be correctly calculated on all the Rbridges in TRILL network, then the member RBridge can safely use the virtual Rbridge nickname to do the necessary TRILL-encapsultion on  received native frames. 

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is removed, while the similar flexibilty of Affinity sub-TLV remains. 


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
发件人:  rbridge-bounces at postel.org 

2012-01-06 10:11 

收件人

<rbridge at postel.org> 

抄送

	
主题

[rbridge] Coordinated Multicast Trees to solve RPF issues on        active-active edge and more

 

		




Dear All 
  
We have published draft-tissa-trill-cmt-00.txt, in this document we present a flexible framework to associate child RBridges to different parent RBRidges for RPF purpose. 
  
Active-active forwarding at the TRILL edge is a very important feature. Representation of the active-active sub system with a single virtual RBRidge is a common practice to achieve load balancing and to avoid MAC flip flop. However, use of virtual RBridge lead to RPF failures. In this document we provide a solution to address the RPF failures. Please review and share comments. 
  
ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt <http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt>  
  
Summary: 
  
Filename:   draft-tissa-trill-cmt 
Revision:   00 
Title:            Coordinated Multicast Trees (CMT)for TRILL 
Creation date:    2012-01-05 
WG ID:            Individual Submission 
Number of pages: 14 
  
Abstract: 
   TRILL facilitates loop free connectivity to non TRILL legacy 
   networks via choice of an Appointed Forwarder for set of VLANs. 
   Appointed Forwarder provides VLAN level load sharing with active- 
   standby model. Mission critical operations such as High Performance 
   Data Centers require active-active load sharing model. Active-Active 
   load sharing model can be accomplished by representing any given non 
   TRILL legacy network with a single virtual RBridge. Virtual 
   representation of the non-TRILL legacy network with a single RBridge 
   poses serious challenges in multi-destination RPF calculations. This 
   document presents the required enhancements to build Coordinated 
   Multicast Trees (CMT) within the TRILL campus. CMT provides 
   flexibility to RBridges to select desired path of association to a 
   given distribution tree. 
  
  
Thanks 
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge



 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120112/3654c500/attachment-0001.html

From zhai.hongjun at zte.com.cn  Thu Jan 12 21:05:29 2012
From: zhai.hongjun at zte.com.cn (zhai.hongjun@zte.com.cn)
Date: Fri, 13 Jan 2012 13:05:29 +0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
 active-active edge and more
In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A56556C6@xmb-sjc-214.amer.cisco.com>
Message-ID: <OF5B6393CA.6DBC99E2-ON48257984.00183801-48257984.001C1D94@zte.com.cn>

Hi Tissa，

In the diagram you given, assume 4 distribution trees are acturally 
calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned 
to RB1, T3 and T4 are assigned to RB2.

Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a 
pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) 
nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode 
LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are 
the only two neigbors)  of this pseudonode.  After receiving this 
pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on 
T1 or T2, shown in the following diagram.

                                  RBx
                                     |
                           Trill Campus
               |                                              |
    +----------+                                   +------------+
    |  RB1     |                                  |  RB2       |
    +----------+                                  + ------------+
          \ 
          /  \ 
        /RBv \ 
       ---------
                scheme of T1 or T2

RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity 
sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned 
trees T1 and T2.

RB2 also annouce similar informtion in its pseudonode LSP, then RBx can 
know the path to RBv through RB2 on T3 and T4.

                                  RBx
                                     |
                           Trill Campus
               |                                              |
    +----------+                                   +------------+
    |  RB1     |                                  |  RB2       |
    +----------+                                  + ------------+
          \                                                  /
           \                                               /
            \                                            /
              ----------               -----------
                      >   |             |  <  Port channel (LAG)
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+




Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
2012-01-13 12:21

收件人
<zhai.hongjun at zte.com.cn>
抄送
<rbridge at postel.org>, <rbridge-bounces at postel.org>
主题
RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more






Hi Hongjun
 
I am not quite clear with the way you are proposing to use assigned 
nicknames in the pseudonode LSP.
 
Can you please us the diagram below and explain how your proposal will be 
used. 
 
CE means in the following diagram is an 802.1D device that is attached to 
RB1 and RB2 through Pt-Pt links and treated as a port channel from CE 
stand point.
 
                                   RBx
                                     |
                           Trill Campus
               |                                              |
    +----------+                                   +------------+
    |  RB1     |                                  |  RB2       |
    +----------+                                  + ------------+
          \                                                  /
           \                                               /
            \                                            /
              ----------               -----------
                      >   |             |  <  Port channel (LAG)
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+
 
 
From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more
 

Hi Tissa, 

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In 
this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member 
RBdige of a virtual RBridge group much flexibity in describing the virtual 
RBridge nickname and  specifying the path of association to specific 
distribution tree(S).  However, this new TLV causes some backward 
compatibilty problems between pre Affinity sub-TLV RBridges and new 
RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL 
network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the 
virtual Rbridge nickname and  the specific distribution trees? Maybe it is 
not. 

In a given vritual group, each  member Rbridge can advertise a specific 
pseudonode-LSP to annouce the virtual RBridge nickname and the trees 
assigned to it.The nickname and the assigned trees are contained in  the 
given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP 
represents a special virtual link, on which there is only one RBridge, 
i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge 
is assigned different tree(s), RPF check information for the virtual 
Rbrigde in different trees can be correctly calculated on all the Rbridges 
in TRILL network, then the member RBridge can safely use the virtual 
Rbridge nickname to do the necessary TRILL-encapsultion on  received 
native frames. 

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is 
removed, while the similar flexibilty of Affinity sub-TLV remains. 


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""




"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
发件人:  rbridge-bounces at postel.org 
2012-01-06 10:11 


收件人
<rbridge at postel.org> 
抄送

主题
[rbridge] Coordinated Multicast Trees to solve RPF issues on active-active 
edge and more
 








Dear All 
  
We have published draft-tissa-trill-cmt-00.txt, in this document we 
present a flexible framework to associate child RBridges to different 
parent RBRidges for RPF purpose. 
  
Active-active forwarding at the TRILL edge is a very important feature. 
Representation of the active-active sub system with a single virtual 
RBRidge is a common practice to achieve load balancing and to avoid MAC 
flip flop. However, use of virtual RBridge lead to RPF failures. In this 
document we provide a solution to address the RPF failures. Please review 
and share comments. 
  
ID can be found in URL: 
http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt 
  
Summary: 
  
Filename:   draft-tissa-trill-cmt 
Revision:   00 
Title:            Coordinated Multicast Trees (CMT)for TRILL 
Creation date:    2012-01-05 
WG ID:            Individual Submission 
Number of pages: 14 
  
Abstract: 
   TRILL facilitates loop free connectivity to non TRILL legacy 
   networks via choice of an Appointed Forwarder for set of VLANs. 
   Appointed Forwarder provides VLAN level load sharing with active- 
   standby model. Mission critical operations such as High Performance 
   Data Centers require active-active load sharing model. Active-Active 
   load sharing model can be accomplished by representing any given non 
   TRILL legacy network with a single virtual RBridge. Virtual 
   representation of the non-TRILL legacy network with a single RBridge 
   poses serious challenges in multi-destination RPF calculations. This 
   document presents the required enhancements to build Coordinated 
   Multicast Trees (CMT) within the TRILL campus. CMT provides 
   flexibility to RBridges to select desired path of association to a 
   given distribution tree. 
  
  
Thanks 
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120113/96994e90/attachment-0001.html

From mgururam at gmail.com  Fri Jan 13 01:54:10 2012
From: mgururam at gmail.com (gururam m)
Date: Fri, 13 Jan 2012 15:24:10 +0530
Subject: [rbridge] TRILL behavior over 802.1AX interface (link aggregation)
Message-ID: <CADaSLpW+V13LeHaJ1EcU6MPEiRvukJ+s-pUQq-X=EAFFZMV-hw@mail.gmail.com>

Hi,
     Can anyone point me to TRILL RFC/draft that describes TRILL support
over multiple links/link aggregation (802.1AX) that provides details
related to

 1. Hello generation/reception
 2. Adjacency Formation
 3. DRB Election
 4. LSP generation

Regards
Ram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120113/3a3a1ea4/attachment.html

From jana at force10networks.com  Fri Jan 13 05:48:56 2012
From: jana at force10networks.com (Janardhanan Pathangi Narasimhan)
Date: Fri, 13 Jan 2012 19:18:56 +0530
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
 active-active edge and more
In-Reply-To: <OF5B6393CA.6DBC99E2-ON48257984.00183801-48257984.001C1D94@zte.com.cn>
References: <344037D7CFEFE84E97E9CC1F56C5F4A56556C6@xmb-sjc-214.amer.cisco.com>
	<OF5B6393CA.6DBC99E2-ON48257984.00183801-48257984.001C1D94@zte.com.cn>
Message-ID: <CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>

Hi Hongjun,

I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. Is that correct?

Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees.

Thanks
Jana


From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of zhai.hongjun at zte.com.cn
Sent: Friday, January 13, 2012 10:35 AM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more


Hi Tissa，

In the diagram you given, assume 4 distribution trees are acturally calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned to RB1, T3 and T4 are assigned to RB2.

Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are the only two neigbors)  of this pseudonode.  After receiving this pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on T1 or T2, shown in the following diagram.

                                  RBx
                                     |
                           Trill Campus
               |                                              |
    +----------+                                   +------------+
    |  RB1     |                                  |  RB2       |
    +----------+                                  + ------------+
          \
          /  \
        /RBv \
       ---------
                scheme of T1 or T2

RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned trees T1 and T2.

RB2 also annouce similar informtion in its pseudonode LSP, then RBx can know the path to RBv through RB2 on T3 and T4.

                                  RBx
                                     |
                           Trill Campus
               |                                              |
    +----------+                                   +------------+
    |  RB1     |                                  |  RB2       |
    +----------+                                  + ------------+
          \                                                  /
           \                                               /
            \                                            /
              ----------               -----------
                      >   |             |  <  Port channel (LAG)
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+




Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""



"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com>

2012-01-13 12:21

收件人

<zhai.hongjun at zte.com.cn>

抄送

<rbridge at postel.org>, <rbridge-bounces at postel.org>

主题

RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more







Hi Hongjun

I am not quite clear with the way you are proposing to use assigned nicknames in the pseudonode LSP.

Can you please us the diagram below and explain how your proposal will be used.

CE means in the following diagram is an 802.1D device that is attached to RB1 and RB2 through Pt-Pt links and treated as a port channel from CE stand point.

                                   RBx
                                     |
                           Trill Campus
               |                                              |
    +----------+                                   +------------+
    |  RB1     |                                  |  RB2       |
    +----------+                                  + ------------+
          \                                                  /
           \                                               /
            \                                            /
              ----------               -----------
                      >   |             |  <  Port channel (LAG)
                           |             |
                    +--------------------+
                   |    CE                    |
                   +---------------------+


From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn]
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more


Hi Tissa,

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member RBdige of a virtual RBridge group much flexibity in describing the virtual RBridge nickname and  specifying the path of association to specific distribution tree(S).  However, this new TLV causes some backward compatibilty problems between pre Affinity sub-TLV RBridges and new RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the virtual Rbridge nickname and  the specific distribution trees? Maybe it is not.

In a given vritual group, each  member Rbridge can advertise a specific pseudonode-LSP to annouce the virtual RBridge nickname and the trees assigned to it.The nickname and the assigned trees are contained in  the given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP represents a special virtual link, on which there is only one RBridge, i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge is assigned different tree(s), RPF check information for the virtual Rbrigde in different trees can be correctly calculated on all the Rbridges in TRILL network, then the member RBridge can safely use the virtual Rbridge nickname to do the necessary TRILL-encapsultion on  received native frames.

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is removed, while the similar flexibilty of Affinity sub-TLV remains.


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com>
发件人:  rbridge-bounces at postel.org

2012-01-06 10:11


收件人

<rbridge at postel.org>

抄送

主题

[rbridge] Coordinated Multicast Trees to solve RPF issues on        active-active edge and more











Dear All

We have published draft-tissa-trill-cmt-00.txt, in this document we present a flexible framework to associate child RBridges to different parent RBRidges for RPF purpose.

Active-active forwarding at the TRILL edge is a very important feature. Representation of the active-active sub system with a single virtual RBRidge is a common practice to achieve load balancing and to avoid MAC flip flop. However, use of virtual RBridge lead to RPF failures. In this document we provide a solution to address the RPF failures. Please review and share comments.

ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt

Summary:

Filename:   draft-tissa-trill-cmt
Revision:   00
Title:            Coordinated Multicast Trees (CMT)for TRILL
Creation date:    2012-01-05
WG ID:            Individual Submission
Number of pages: 14

Abstract:
  TRILL facilitates loop free connectivity to non TRILL legacy
  networks via choice of an Appointed Forwarder for set of VLANs.
  Appointed Forwarder provides VLAN level load sharing with active-
  standby model. Mission critical operations such as High Performance
  Data Centers require active-active load sharing model. Active-Active
  load sharing model can be accomplished by representing any given non
  TRILL legacy network with a single virtual RBridge. Virtual
  representation of the non-TRILL legacy network with a single RBridge
  poses serious challenges in multi-destination RPF calculations. This
  document presents the required enhancements to build Coordinated
  Multicast Trees (CMT) within the TRILL campus. CMT provides
  flexibility to RBridges to select desired path of association to a
  given distribution tree.


Thanks
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.



--------------------------------------------------------

ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.

This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120113/384a1bea/attachment-0001.html

From d3e3e3 at gmail.com  Fri Jan 13 06:59:45 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 13 Jan 2012 09:59:45 -0500
Subject: [rbridge] TRILL behavior over 802.1AX interface (link
	aggregation)
In-Reply-To: <CADaSLpW+V13LeHaJ1EcU6MPEiRvukJ+s-pUQq-X=EAFFZMV-hw@mail.gmail.com>
References: <CADaSLpW+V13LeHaJ1EcU6MPEiRvukJ+s-pUQq-X=EAFFZMV-hw@mail.gmail.com>
Message-ID: <CAF4+nEH=pNZRMiHjbpXksafwdhkv3_MUXYbMmqPUCYhJqfiEww@mail.gmail.com>

Hi Ram,

On Fri, Jan 13, 2012 at 4:54 AM, gururam m <mgururam at gmail.com> wrote:
> Hi,
> ???? Can anyone point me to TRILL RFC/draft that describes TRILL support
> over multiple links/link aggregation (802.1AX) that provides details related
> to
>
> ?1. Hello generation/reception
> ?2. Adjacency Formation
> ?3. DRB Election
> ?4. LSP generation

TRILL operates above the ports of an RBridge and RFC 6325 mentions
802.1AX as a function that is implemented inside RBridge ports. In
particular, Appendix C says link aggregation occurs "below TRILL". On
multi-destination traffic over parallel non-pseudo-node links visible
to TRILL, see Section 4.5.2, particularly item 3, of RFC 6325.

draft-ietf-trill-rbridge-bfd-01 says:

   If lower level mechanisms, such as link aggregation [802.1AX], are in
   use that present a single logical interface to TRILL IS-IS, only a
   single TRILL BFD session can be established to any other RBridge over
   this logical interface.  However, lower layer OAM could be aware of
   and/or run separately on each of the components of an aggregation.

Section 3.5 of RFC 6327 says:

   There can be multiple parallel adjacencies between neighbor RBridges
   that are visible to TRILL.  (Multiple low-level links that have been
   bonded together by technologies such as link aggregation [802.1AX]
   appear to TRILL as a single link over which only a single TRILL
   adjacency could be established.)

   Any such links that have pseudonodes (see Section 6) are
   distinguished in the topology; such adjacencies, if they are in the
   Report state, appear in LSPs as per Section 6.  However, there can be
   multiple parallel adjacencies without pseudonodes because they are
   point-to-point adjacencies or LAN adjacencies for which a pseudonode
   is not being created.  Such parallel, non-pseudonode adjacencies in
   the Report state appear in LSPs as a single adjacency.  ...

In general, TRILL as currently specified, operates at layer two and a
half, below Layer 3 routing but above bridging. The idea is that link
aggregation is invisible to TRILL. As far as TRILL is concerned, the
aggregation is just a single point-to-point link. Or, more precisely,
the termination of the link aggregation over more than one RBridge
port appears to TRILL to be a single port.

Note that you could have RB1==CB==RB2 where CB is a customer bridge
between two RBridges. Since RBridge ports are, for the most part,
customer bridge ports, you could, for example, have link aggregation
over, say, three physical links from RB1 to CB and just a single
physical link from CB to RB2. Or you could have a link aggregation
over 3 physical links between RB1 and CB and a link aggregation of
five physical links between CB and RB2. All this is invisible to TRILL
on RB1 and RB2 that each just see a single port.

If there are multiple parallel links visible to TRILL, then all the
Adjacency mechanisms in RFC 6327/6325 operate separately on them. The
only thing to keep in mind is that all the non-pseudo-node parallel
adjacencies visible to TRILL are reported in LSP as a single
adjacency.

> Regards
> Ram

Hope the above helps,

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From aldrin.ietf at gmail.com  Fri Jan 13 11:03:36 2012
From: aldrin.ietf at gmail.com (Sam Aldrin)
Date: Fri, 13 Jan 2012 11:03:36 -0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
	active-active edge and more
In-Reply-To: <CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>
References: <344037D7CFEFE84E97E9CC1F56C5F4A56556C6@xmb-sjc-214.amer.cisco.com>
	<OF5B6393CA.6DBC99E2-ON48257984.00183801-48257984.001C1D94@zte.com.cn>
	<CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>
Message-ID: <09194D4B-96EB-48A8-8394-0354200F8BA1@gmail.com>

I agree with Jana.
Scaling will be a major factor if we go the other route. Affinity TLV provides much better option while providing the same service with two trees.

Sam

Sent from my iPad

On Jan 13, 2012, at 5:48 AM, Janardhanan Pathangi Narasimhan <jana at force10networks.com> wrote:

> Hi Hongjun,
>  
> I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. Is that correct?
>  
> Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees.
>  
> Thanks
> Jana
>  
>  
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of zhai.hongjun at zte.com.cn
> Sent: Friday, January 13, 2012 10:35 AM
> To: Tissa Senevirathne (tsenevir)
> Cc: rbridge at postel.org; rbridge-bounces at postel.org
> Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
>  
> 
> Hi Tissa? 
> 
> In the diagram you given, assume 4 distribution trees are acturally calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned to RB1, T3 and T4 are assigned to RB2. 
> 
> Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are the only two neigbors)  of this pseudonode.  After receiving this pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on T1 or T2, shown in the following diagram. 
> 
>                                   RBx 
>                                      | 
>                            Trill Campus 
>                |                                              | 
>     +----------+                                   +------------+ 
>     |  RB1     |                                  |  RB2       | 
>     +----------+                                  + ------------+ 
>           \                                                   
>           /  \                                             
>         /RBv \                               
>        --------- 
>                 scheme of T1 or T2 
> 
> RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned trees T1 and T2. 
> 
> RB2 also annouce similar informtion in its pseudonode LSP, then RBx can know the path to RBv through RB2 on T3 and T4. 
> 
>                                   RBx 
>                                      | 
>                            Trill Campus 
>                |                                              | 
>     +----------+                                   +------------+ 
>     |  RB1     |                                  |  RB2       | 
>     +----------+                                  + ------------+ 
>           \                                                  / 
>            \                                               / 
>             \                                            / 
>               ----------               ----------- 
>                       >   |             |  <  Port channel (LAG) 
>                            |             | 
>                     +--------------------+ 
>                    |    CE                    | 
>                    +---------------------+ 
> 
> 
> 
> 
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> 
> Zhai Hongjun
> 
> Tel: +86-25-52877345
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 
> 
> 
> 
> "Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com>
> 2012-01-13 12:21
> 
> ???
> <zhai.hongjun at zte.com.cn>
> ??
> <rbridge at postel.org>, <rbridge-bounces at postel.org>
> ??
> RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
>  
> 
> 
> 
> Hi Hongjun 
>   
> I am not quite clear with the way you are proposing to use assigned nicknames in the pseudonode LSP. 
>   
> Can you please us the diagram below and explain how your proposal will be used. 
>   
> CE means in the following diagram is an 802.1D device that is attached to RB1 and RB2 through Pt-Pt links and treated as a port channel from CE stand point. 
>   
>                                    RBx 
>                                      | 
>                            Trill Campus 
>                |                                              | 
>     +----------+                                   +------------+ 
>     |  RB1     |                                  |  RB2       | 
>     +----------+                                  + ------------+ 
>           \                                                  / 
>            \                                               / 
>             \                                            / 
>               ----------               ----------- 
>                       >   |             |  <  Port channel (LAG) 
>                            |             | 
>                     +--------------------+ 
>                    |    CE                    | 
>                    +---------------------+ 
>   
>   
> From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
> Sent: Thursday, January 12, 2012 7:59 PM
> To: Tissa Senevirathne (tsenevir)
> Cc: rbridge at postel.org; rbridge-bounces at postel.org
> Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more 
>   
> 
> Hi Tissa, 
> 
> I have read your draft-tissa-trill-cmt-00.txt with great interests.  In this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member RBdige of a virtual RBridge group much flexibity in describing the virtual RBridge nickname and  specifying the path of association to specific distribution tree(S).  However, this new TLV causes some backward compatibilty problems between pre Affinity sub-TLV RBridges and new RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL network,the RPF check for virtual Rbridge will fail on this RBridge.
> 
> Is the Affinity Sub-TLV necessary for a member RBridge to announce the virtual Rbridge nickname and  the specific distribution trees? Maybe it is not. 
> 
> In a given vritual group, each  member Rbridge can advertise a specific pseudonode-LSP to annouce the virtual RBridge nickname and the trees assigned to it.The nickname and the assigned trees are contained in  the given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP represents a special virtual link, on which there is only one RBridge, i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge is assigned different tree(s), RPF check information for the virtual Rbrigde in different trees can be correctly calculated on all the Rbridges in TRILL network, then the member RBridge can safely use the virtual Rbridge nickname to do the necessary TRILL-encapsultion on  received native frames. 
> 
> Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is removed, while the similar flexibilty of Affinity sub-TLV remains. 
> 
> 
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> 
> Zhai Hongjun
> 
> Tel: +86-25-52877345
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 
> 
> "Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
> ???:  rbridge-bounces at postel.org
> 2012-01-06 10:11
> 
>  
> ???
> <rbridge at postel.org>
> ??
> ??
> [rbridge] Coordinated Multicast Trees to solve RPF issues on        active-active edge and more
> 
>  
>  
> 
> 
> 
> 
> 
> Dear All 
>  
> We have published draft-tissa-trill-cmt-00.txt, in this document we present a flexible framework to associate child RBridges to different parent RBRidges for RPF purpose. 
>  
> Active-active forwarding at the TRILL edge is a very important feature. Representation of the active-active sub system with a single virtual RBRidge is a common practice to achieve load balancing and to avoid MAC flip flop. However, use of virtual RBridge lead to RPF failures. In this document we provide a solution to address the RPF failures. Please review and share comments. 
>  
> ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt 
>  
> Summary: 
>  
> Filename:   draft-tissa-trill-cmt 
> Revision:   00 
> Title:            Coordinated Multicast Trees (CMT)for TRILL 
> Creation date:    2012-01-05 
> WG ID:            Individual Submission 
> Number of pages: 14 
>  
> Abstract: 
>   TRILL facilitates loop free connectivity to non TRILL legacy 
>   networks via choice of an Appointed Forwarder for set of VLANs. 
>   Appointed Forwarder provides VLAN level load sharing with active- 
>   standby model. Mission critical operations such as High Performance 
>   Data Centers require active-active load sharing model. Active-Active 
>   load sharing model can be accomplished by representing any given non 
>   TRILL legacy network with a single virtual RBridge. Virtual 
>   representation of the non-TRILL legacy network with a single RBridge 
>   poses serious challenges in multi-destination RPF calculations. This 
>   document presents the required enhancements to build Coordinated 
>   Multicast Trees (CMT) within the TRILL campus. CMT provides 
>   flexibility to RBridges to select desired path of association to a 
>   given distribution tree. 
>  
>  
> Thanks 
> Tissa_______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
>   
> -------------------------------------------------------- 
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. 
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> 
>  
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120113/62f41800/attachment-0001.html

From jon.hudson at gmail.com  Fri Jan 13 11:44:42 2012
From: jon.hudson at gmail.com (Jon Hudson)
Date: Fri, 13 Jan 2012 11:44:42 -0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
	active-active edge and more
In-Reply-To: <CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>
References: <344037D7CFEFE84E97E9CC1F56C5F4A56556C6@xmb-sjc-214.amer.cisco.com>
	<OF5B6393CA.6DBC99E2-ON48257984.00183801-48257984.001C1D94@zte.com.cn>
	<CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>
Message-ID: <E6715CA2-AC9B-4779-9509-6BF21EF7D72A@gmail.com>

Great explanation Jana!

Scaling is the challenge.

On Jan 13, 2012, at 5:48 AM, Janardhanan Pathangi Narasimhan <jana at force10networks.com> wrote:

> Hi Hongjun,
>  
> I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. Is that correct?
>  
> Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees.
>  
> Thanks
> Jana
>  
>  
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of zhai.hongjun at zte.com.cn
> Sent: Friday, January 13, 2012 10:35 AM
> To: Tissa Senevirathne (tsenevir)
> Cc: rbridge at postel.org; rbridge-bounces at postel.org
> Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
>  
> 
> Hi Tissa? 
> 
> In the diagram you given, assume 4 distribution trees are acturally calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned to RB1, T3 and T4 are assigned to RB2. 
> 
> Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are the only two neigbors)  of this pseudonode.  After receiving this pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on T1 or T2, shown in the following diagram. 
> 
>                                   RBx 
>                                      | 
>                            Trill Campus 
>                |                                              | 
>     +----------+                                   +------------+ 
>     |  RB1     |                                  |  RB2       | 
>     +----------+                                  + ------------+ 
>           \                                                   
>           /  \                                             
>         /RBv \                               
>        --------- 
>                 scheme of T1 or T2 
> 
> RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned trees T1 and T2. 
> 
> RB2 also annouce similar informtion in its pseudonode LSP, then RBx can know the path to RBv through RB2 on T3 and T4. 
> 
>                                   RBx 
>                                      | 
>                            Trill Campus 
>                |                                              | 
>     +----------+                                   +------------+ 
>     |  RB1     |                                  |  RB2       | 
>     +----------+                                  + ------------+ 
>           \                                                  / 
>            \                                               / 
>             \                                            / 
>               ----------               ----------- 
>                       >   |             |  <  Port channel (LAG) 
>                            |             | 
>                     +--------------------+ 
>                    |    CE                    | 
>                    +---------------------+ 
> 
> 
> 
> 
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> 
> Zhai Hongjun
> 
> Tel: +86-25-52877345
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 
> 
> 
> 
> "Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com>
> 2012-01-13 12:21
> 
> ???
> <zhai.hongjun at zte.com.cn>
> ??
> <rbridge at postel.org>, <rbridge-bounces at postel.org>
> ??
> RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
>  
> 
> 
> 
> Hi Hongjun 
>   
> I am not quite clear with the way you are proposing to use assigned nicknames in the pseudonode LSP. 
>   
> Can you please us the diagram below and explain how your proposal will be used. 
>   
> CE means in the following diagram is an 802.1D device that is attached to RB1 and RB2 through Pt-Pt links and treated as a port channel from CE stand point. 
>   
>                                    RBx 
>                                      | 
>                            Trill Campus 
>                |                                              | 
>     +----------+                                   +------------+ 
>     |  RB1     |                                  |  RB2       | 
>     +----------+                                  + ------------+ 
>           \                                                  / 
>            \                                               / 
>             \                                            / 
>               ----------               ----------- 
>                       >   |             |  <  Port channel (LAG) 
>                            |             | 
>                     +--------------------+ 
>                    |    CE                    | 
>                    +---------------------+ 
>   
>   
> From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
> Sent: Thursday, January 12, 2012 7:59 PM
> To: Tissa Senevirathne (tsenevir)
> Cc: rbridge at postel.org; rbridge-bounces at postel.org
> Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more 
>   
> 
> Hi Tissa, 
> 
> I have read your draft-tissa-trill-cmt-00.txt with great interests.  In this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member RBdige of a virtual RBridge group much flexibity in describing the virtual RBridge nickname and  specifying the path of association to specific distribution tree(S).  However, this new TLV causes some backward compatibilty problems between pre Affinity sub-TLV RBridges and new RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL network,the RPF check for virtual Rbridge will fail on this RBridge.
> 
> Is the Affinity Sub-TLV necessary for a member RBridge to announce the virtual Rbridge nickname and  the specific distribution trees? Maybe it is not. 
> 
> In a given vritual group, each  member Rbridge can advertise a specific pseudonode-LSP to annouce the virtual RBridge nickname and the trees assigned to it.The nickname and the assigned trees are contained in  the given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP represents a special virtual link, on which there is only one RBridge, i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge is assigned different tree(s), RPF check information for the virtual Rbrigde in different trees can be correctly calculated on all the Rbridges in TRILL network, then the member RBridge can safely use the virtual Rbridge nickname to do the necessary TRILL-encapsultion on  received native frames. 
> 
> Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is removed, while the similar flexibilty of Affinity sub-TLV remains. 
> 
> 
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> 
> Zhai Hongjun
> 
> Tel: +86-25-52877345
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 
> 
> "Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
> ???:  rbridge-bounces at postel.org
> 2012-01-06 10:11
> 
>  
> ???
> <rbridge at postel.org>
> ??
> ??
> [rbridge] Coordinated Multicast Trees to solve RPF issues on        active-active edge and more
> 
>  
>  
> 
> 
> 
> 
> 
> Dear All 
>  
> We have published draft-tissa-trill-cmt-00.txt, in this document we present a flexible framework to associate child RBridges to different parent RBRidges for RPF purpose. 
>  
> Active-active forwarding at the TRILL edge is a very important feature. Representation of the active-active sub system with a single virtual RBRidge is a common practice to achieve load balancing and to avoid MAC flip flop. However, use of virtual RBridge lead to RPF failures. In this document we provide a solution to address the RPF failures. Please review and share comments. 
>  
> ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt 
>  
> Summary: 
>  
> Filename:   draft-tissa-trill-cmt 
> Revision:   00 
> Title:            Coordinated Multicast Trees (CMT)for TRILL 
> Creation date:    2012-01-05 
> WG ID:            Individual Submission 
> Number of pages: 14 
>  
> Abstract: 
>   TRILL facilitates loop free connectivity to non TRILL legacy 
>   networks via choice of an Appointed Forwarder for set of VLANs. 
>   Appointed Forwarder provides VLAN level load sharing with active- 
>   standby model. Mission critical operations such as High Performance 
>   Data Centers require active-active load sharing model. Active-Active 
>   load sharing model can be accomplished by representing any given non 
>   TRILL legacy network with a single virtual RBridge. Virtual 
>   representation of the non-TRILL legacy network with a single RBridge 
>   poses serious challenges in multi-destination RPF calculations. This 
>   document presents the required enhancements to build Coordinated 
>   Multicast Trees (CMT) within the TRILL campus. CMT provides 
>   flexibility to RBridges to select desired path of association to a 
>   given distribution tree. 
>  
>  
> Thanks 
> Tissa_______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
>   
> -------------------------------------------------------- 
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. 
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> 
>  
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120113/c4516206/attachment-0001.html

From zhai.hongjun at zte.com.cn  Fri Jan 13 20:16:44 2012
From: zhai.hongjun at zte.com.cn (zhai.hongjun@zte.com.cn)
Date: Sat, 14 Jan 2012 12:16:44 +0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
 active-active edge and more
In-Reply-To: <CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>
Message-ID: <OF22F4768A.8888FDD2-ON48257985.000F1213-48257985.0017AB39@zte.com.cn>

Hi Jana, Jon and Tissa,

> I think your proposal is that form a tree rooted at RB1 and another tree 
rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link, 
> and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you 
are forcing the affinity of RB1 or RB2 to RBV by placing the root on the 
RBridges themselves. 
> Is that correct? 

No, It didn't mean that the trees must rooted at RB1, RB2, respectively. 
It has no any needs of where the roots of these trees are. These trees are 
ordinary trees calculated by all RBridges in TRILL campus wide.

For example, there are 4 actually-calculated trees in TRILL campus, T1 
through T4. T1 roots at RBi, T2 roots at RBj, T3 roots at RBm and T4 roots 
at RBn. If T1 and T2 are assigned to member RBridge RB1, and the rest 
trees to RB2. The method used to assign trees to a member RBridge is the 
same as given in Section 5.1 in draft CMT. 

In the below topology, Since RB1 knows it is a member RBridge of Rbridge 
Group RBv1 and that T1/T2 are assigned to it, RB1 can originate a 
pseudonode LSP(even if it has not seen any neighbors in RBv by hellos) and 
advertize it in TRILL campus. This pseudonode LSP contains a Nickname 
sub-TLV where nickname of RBv1 is carried, and a Trees sub_TLV where the 
wanted-to-using tress(i.e., T1 and T2) are carried, as well as a neighbor 
TLV where RB1 is the only neighbor contained in this pseudonode LSP.

After receiving this  psuedonode LSP, another RBridge, e.g., RBx,  knows 
the paths to RBv through RB1 on T1 and T2. Then RPF information for RBv1 
can be calculated correctly by RBx on these two trees.
                                 RBx 
                                     | 
                           Trill Campus 
               |                                              | 
    +----------+                                   +------------+ 
    |  RB1     |                                  |  RB2       | 
    +----------+                                  + ------------+ 
          \                                                  / 
           \                                               / 
            \                                            / 
              ----------               ----------- 
                      >   |             |  <  Port channel (LAG) 
                           |             | 
                    +--------------------+ 
                   |    CE                    | 
                   +---------------------+ 

Besides RBv1, If RB1joins another Rbridge Group RBv2, and T2/T3 are 
assigned to RB1, RB1 can originates another pseudonode LSP, where nickname 
of RBv2 and T2/T3 are carried in Nickname sub-TLV and Trees sub-TLV, 
respectively. After receiving this LSP, RBx can knows path to RBv2 through 
RB1 on T2 and T3. RPF check information can also calculated correctly by 
RBx on thes two trees.

Similar things RB2 can do, and RPF check information can be calculated 
correctly by RBx on the assigned trees
 
> Yes, this mechanism would work, but would not scale up. For e.g. in the 
network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, 
RB3-RB4 providing RBV2, 
> and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 
and so on are present, we will have to minimum build 20 trees (10 pairs of 
RB). 
> This will not scale, while with affinity TLV irrespective of number of 
such RB pairs which are providing such services we would need only two 
trees.

No, It does not require much more trees to build if using pseudonode LSP, 
instead of affinity TLV,  to notify other RBridges the affinity of RBv via 
RB1. It just needs to originate much more pseudonode LSPs if an Rbridge 
joins more than one RBridge Group.



Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





Janardhanan Pathangi Narasimhan <jana at force10networks.com> 
发件人:  rbridge-bounces at postel.org
2012-01-13 21:48

收件人
"zhai.hongjun at zte.com.cn" <zhai.hongjun at zte.com.cn>, "Tissa Senevirathne 
(tsenevir)" <tsenevir at cisco.com>
抄送
"rbridge at postel.org" <rbridge at postel.org>, "rbridge-bounces at postel.org" 
<rbridge-bounces at postel.org>
主题
Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more






Hi Hongjun,
 
I think your proposal is that form a tree rooted at RB1 and another tree 
rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and 
similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are 
forcing the affinity of RB1 or RB2 to RBV by placing the root on the 
RBridges themselves. Is that correct? 
 
Yes, this mechanism would work, but would not scale up. For e.g. in the 
network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, 
RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, 
RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 
trees (10 pairs of RB). This will not scale, while with affinity TLV 
irrespective of number of such RB pairs which are providing such services 
we would need only two trees.
 
Thanks
Jana
 
 
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On 
Behalf Of zhai.hongjun at zte.com.cn
Sent: Friday, January 13, 2012 10:35 AM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more
 

Hi Tissa， 

In the diagram you given, assume 4 distribution trees are acturally 
calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned 
to RB1, T3 and T4 are assigned to RB2. 

Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a 
pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) 
nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode 
LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are 
the only two neigbors)  of this pseudonode.  After receiving this 
pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on 
T1 or T2, shown in the following diagram. 

                                  RBx 
                                     | 
                           Trill Campus 
               |                                              | 
    +----------+                                   +------------+ 
    |  RB1     |                                  |  RB2       | 
    +----------+                                  + ------------+ 
          \ 
          /  \                                             
        /RBv \ 
       --------- 
                scheme of T1 or T2 

RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity 
sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned 
trees T1 and T2. 

RB2 also annouce similar informtion in its pseudonode LSP, then RBx can 
know the path to RBv through RB2 on T3 and T4. 

                                  RBx 
                                     | 
                           Trill Campus 
               |                                              | 
    +----------+                                   +------------+ 
    |  RB1     |                                  |  RB2       | 
    +----------+                                  + ------------+ 
          \                                                  / 
           \                                               / 
            \                                            / 
              ----------               ----------- 
                      >   |             |  <  Port channel (LAG) 
                           |             | 
                    +--------------------+ 
                   |    CE                    | 
                   +---------------------+ 




Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""




"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
2012-01-13 12:21 


收件人
<zhai.hongjun at zte.com.cn> 
抄送
<rbridge at postel.org>, <rbridge-bounces at postel.org> 
主题
RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more
 








Hi Hongjun 
  
I am not quite clear with the way you are proposing to use assigned 
nicknames in the pseudonode LSP. 
  
Can you please us the diagram below and explain how your proposal will be 
used. 
  
CE means in the following diagram is an 802.1D device that is attached to 
RB1 and RB2 through Pt-Pt links and treated as a port channel from CE 
stand point. 
  
                                   RBx 
                                     | 
                           Trill Campus 
               |                                              | 
    +----------+                                   +------------+ 
    |  RB1     |                                  |  RB2       | 
    +----------+                                  + ------------+ 
          \                                                  / 
           \                                               / 
            \                                            / 
              ----------               ----------- 
                      >   |             |  <  Port channel (LAG) 
                           |             | 
                    +--------------------+ 
                   |    CE                    | 
                   +---------------------+ 
  
  
From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more 
  

Hi Tissa, 

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In 
this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member 
RBdige of a virtual RBridge group much flexibity in describing the virtual 
RBridge nickname and  specifying the path of association to specific 
distribution tree(S).  However, this new TLV causes some backward 
compatibilty problems between pre Affinity sub-TLV RBridges and new 
RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL 
network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the 
virtual Rbridge nickname and  the specific distribution trees? Maybe it is 
not. 

In a given vritual group, each  member Rbridge can advertise a specific 
pseudonode-LSP to annouce the virtual RBridge nickname and the trees 
assigned to it.The nickname and the assigned trees are contained in  the 
given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP 
represents a special virtual link, on which there is only one RBridge, 
i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge 
is assigned different tree(s), RPF check information for the virtual 
Rbrigde in different trees can be correctly calculated on all the Rbridges 
in TRILL network, then the member RBridge can safely use the virtual 
Rbridge nickname to do the necessary TRILL-encapsultion on  received 
native frames. 

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is 
removed, while the similar flexibilty of Affinity sub-TLV remains. 


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
发件人:  rbridge-bounces at postel.org 
2012-01-06 10:11 
 


收件人
<rbridge at postel.org> 
抄送

主题
[rbridge] Coordinated Multicast Trees to solve RPF issues on active-active 
edge and more

  
 









Dear All 
 
We have published draft-tissa-trill-cmt-00.txt, in this document we 
present a flexible framework to associate child RBridges to different 
parent RBRidges for RPF purpose. 
 
Active-active forwarding at the TRILL edge is a very important feature. 
Representation of the active-active sub system with a single virtual 
RBRidge is a common practice to achieve load balancing and to avoid MAC 
flip flop. However, use of virtual RBridge lead to RPF failures. In this 
document we provide a solution to address the RPF failures. Please review 
and share comments. 
 
ID can be found in URL: 
http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt 
 
Summary: 
 
Filename:   draft-tissa-trill-cmt 
Revision:   00 
Title:            Coordinated Multicast Trees (CMT)for TRILL 
Creation date:    2012-01-05 
WG ID:            Individual Submission 
Number of pages: 14 
 
Abstract: 
  TRILL facilitates loop free connectivity to non TRILL legacy 
  networks via choice of an Appointed Forwarder for set of VLANs. 
  Appointed Forwarder provides VLAN level load sharing with active- 
  standby model. Mission critical operations such as High Performance 
  Data Centers require active-active load sharing model. Active-Active 
  load sharing model can be accomplished by representing any given non 
  TRILL legacy network with a single virtual RBridge. Virtual 
  representation of the non-TRILL legacy network with a single RBridge 
  poses serious challenges in multi-destination RPF calculations. This 
  document presents the required enhancements to build Coordinated 
  Multicast Trees (CMT) within the TRILL campus. CMT provides 
  flexibility to RBridges to select desired path of association to a 
  given distribution tree. 
 
 
Thanks 
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

  
-------------------------------------------------------- 
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others. 
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender. 
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system. 
 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system._______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120114/afa1c3e3/attachment-0001.html

From tsenevir at cisco.com  Sat Jan 14 07:04:34 2012
From: tsenevir at cisco.com (Tissa Senevirathne (tsenevir))
Date: Sat, 14 Jan 2012 07:04:34 -0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
	active-active edge and more
In-Reply-To: <OF22F4768A.8888FDD2-ON48257985.000F1213-48257985.0017AB39@zte.com.cn>
References: <CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>
	<OF22F4768A.8888FDD2-ON48257985.000F1213-48257985.0017AB39@zte.com.cn>
Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A56559B6@xmb-sjc-214.amer.cisco.com>

Hi Hongjun

 

Technically speaking what you are proposing is similar to Affinity TLV approach. With the difference of using Pseudonode LSP instead of the Affinity TLV .

 

Main issue with PSN-LSP approach is the scale, Let me explain that in bit more details.

 

Affinity TLV is a single sub-TLV announced by each of the members of active-active pair or pairs.

 

Similarly PSN-LSP is also announced by each of the members of active-active pair or pairs.

 

However, PSN-LSP is a fully contained LSP that contain  multiple TLV s that needed to fully form a PSN.

 

This will increase the size of the LSP-DB of the campus and introduce X more additional TLVs.

 

There can be many  active-active pair/pairs in the network, and with this approach we have so many more additional LSP in the network.

 

As we know size of LSP-DB is a major scaling issue and always want to keep it as small as possible, where possible.

 

Lets also look at why PSN-LSP approach being proposed. It is to solve a possible backward compatibility issue.

 

TRILL still in infancy and there are not many TRILL networks.  So the backward compatibility is not a wide spread issue. Also affinity draft has backward compatibility mode.

 

What we should look at is having a solution that help us to scale better as TRILL become widely deployed in Large data-centers/Enterprises where such active-active edge is widely used.

 

With PSN-LSP approach I think we are unnecessarily injecting additional LSP and TLVs and making it more complicated and less scalable when we can solve with a single sub-TLV. Also Affinity TLV draft discuss backward compatibility approach, in the event there older Rbridges.

 

Thanks

Tissa

 

From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
Sent: Friday, January 13, 2012 8:17 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge at postel.org; rbridge-bounces at postel.org; Tissa Senevirathne (tsenevir)
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

 


Hi Jana, Jon and Tissa, 

> I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,   
> and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. 
> Is that correct? 

No, It didn't mean that the trees must rooted at RB1, RB2, respectively.  It has no any needs of where the roots of these trees are. These trees are ordinary trees calculated by all RBridges in TRILL campus wide. 

For example, there are 4 actually-calculated trees in TRILL campus, T1 through T4. T1 roots at RBi, T2 roots at RBj, T3 roots at RBm and T4 roots at RBn. If T1 and T2 are assigned to member RBridge RB1, and the rest trees to RB2. The method used to assign trees to a member RBridge is the same as given in Section 5.1 in draft CMT. 

In the below topology, Since RB1 knows it is a member RBridge of Rbridge Group RBv1 and that T1/T2 are assigned to it, RB1 can originate a pseudonode LSP(even if it has not seen any neighbors in RBv by hellos) and advertize it in TRILL campus. This pseudonode LSP contains a Nickname sub-TLV where nickname of RBv1 is carried, and a Trees sub_TLV where the wanted-to-using tress(i.e., T1 and T2) are carried, as well as a neighbor TLV where RB1 is the only neighbor contained in this pseudonode LSP. 

After receiving this  psuedonode LSP, another RBridge, e.g., RBx,  knows the paths to RBv through RB1 on T1 and T2. Then RPF information for RBv1 can be calculated correctly by RBx on these two trees. 
                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                  / 
          \                                               / 
           \                                            / 
             ----------               ----------- 
                     >   |             |  <  Port channel (LAG) 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

Besides RBv1, If RB1joins another Rbridge Group RBv2, and T2/T3 are assigned to RB1, RB1 can originates another pseudonode LSP, where nickname of RBv2 and T2/T3 are carried in Nickname sub-TLV and Trees sub-TLV, respectively. After receiving this LSP, RBx can knows path to RBv2 through RB1 on T2 and T3. RPF check information can also calculated correctly by RBx on thes two trees. 

Similar things RB2 can do, and RPF check information can be calculated correctly by RBx on the assigned trees 
  
> Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, 
> and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). 
> This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees. 

No, It does not require much more trees to build if using pseudonode LSP, instead of affinity TLV,  to notify other RBridges the affinity of RBv via RB1. It just needs to originate much more pseudonode LSPs if an Rbridge joins more than one RBridge Group. 



Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





Janardhanan Pathangi Narasimhan <jana at force10networks.com> 
发件人:  rbridge-bounces at postel.org 

2012-01-13 21:48 

收件人

"zhai.hongjun at zte.com.cn" <zhai.hongjun at zte.com.cn>, "Tissa Senevirathne        (tsenevir)" <tsenevir at cisco.com> 

抄送

"rbridge at postel.org" <rbridge at postel.org>, "rbridge-bounces at postel.org" <rbridge-bounces at postel.org> 

主题

Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more

 

		




Hi Hongjun, 
  
I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. Is that correct? 
  
Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees. 
  
Thanks 
Jana 
  
  
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of zhai.hongjun at zte.com.cn
Sent: Friday, January 13, 2012 10:35 AM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more 
  

Hi Tissa， 

In the diagram you given, assume 4 distribution trees are acturally calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned to RB1, T3 and T4 are assigned to RB2. 

Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are the only two neigbors)  of this pseudonode.  After receiving this pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on T1 or T2, shown in the following diagram. 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                   
         /  \                                             
       /RBv \                               
      --------- 
               scheme of T1 or T2 

RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned trees T1 and T2. 

RB2 also annouce similar informtion in its pseudonode LSP, then RBx can know the path to RBv through RB2 on T3 and T4. 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                  / 
          \                                               / 
           \                                            / 
             ----------               ----------- 
                     >   |             |  <  Port channel (LAG) 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 




Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""



"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 

2012-01-13 12:21 

 

收件人

<zhai.hongjun at zte.com.cn> 

抄送

<rbridge at postel.org>, <rbridge-bounces at postel.org> 

主题

RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more


  

 

		





Hi Hongjun 
 
I am not quite clear with the way you are proposing to use assigned nicknames in the pseudonode LSP. 
 
Can you please us the diagram below and explain how your proposal will be used. 
 
CE means in the following diagram is an 802.1D device that is attached to RB1 and RB2 through Pt-Pt links and treated as a port channel from CE stand point. 
 
                                  RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                  / 
          \                                               / 
           \                                            / 
             ----------               ----------- 
                     >   |             |  <  Port channel (LAG) 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 
 
 
From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more 
 

Hi Tissa, 

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member RBdige of a virtual RBridge group much flexibity in describing the virtual RBridge nickname and  specifying the path of association to specific distribution tree(S).  However, this new TLV causes some backward compatibilty problems between pre Affinity sub-TLV RBridges and new RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the virtual Rbridge nickname and  the specific distribution trees? Maybe it is not. 

In a given vritual group, each  member Rbridge can advertise a specific pseudonode-LSP to annouce the virtual RBridge nickname and the trees assigned to it.The nickname and the assigned trees are contained in  the given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP represents a special virtual link, on which there is only one RBridge, i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge is assigned different tree(s), RPF check information for the virtual Rbrigde in different trees can be correctly calculated on all the Rbridges in TRILL network, then the member RBridge can safely use the virtual Rbridge nickname to do the necessary TRILL-encapsultion on  received native frames. 

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is removed, while the similar flexibilty of Affinity sub-TLV remains. 


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
发件人:  rbridge-bounces at postel.org 

2012-01-06 10:11 

  

 

收件人

<rbridge at postel.org> 

抄送

	
主题

[rbridge] Coordinated Multicast Trees to solve RPF issues on        active-active edge and more



  

  

 

		





Dear All 

We have published draft-tissa-trill-cmt-00.txt, in this document we present a flexible framework to associate child RBridges to different parent RBRidges for RPF purpose. 

Active-active forwarding at the TRILL edge is a very important feature. Representation of the active-active sub system with a single virtual RBRidge is a common practice to achieve load balancing and to avoid MAC flip flop. However, use of virtual RBridge lead to RPF failures. In this document we provide a solution to address the RPF failures. Please review and share comments. 

ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt <http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt>  

Summary: 

Filename:   draft-tissa-trill-cmt 
Revision:   00 
Title:            Coordinated Multicast Trees (CMT)for TRILL 
Creation date:    2012-01-05 
WG ID:            Individual Submission 
Number of pages: 14 

Abstract: 
 TRILL facilitates loop free connectivity to non TRILL legacy 
 networks via choice of an Appointed Forwarder for set of VLANs. 
 Appointed Forwarder provides VLAN level load sharing with active- 
 standby model. Mission critical operations such as High Performance 
 Data Centers require active-active load sharing model. Active-Active 
 load sharing model can be accomplished by representing any given non 
 TRILL legacy network with a single virtual RBridge. Virtual 
 representation of the non-TRILL legacy network with a single RBridge 
 poses serious challenges in multi-destination RPF calculations. This 
 document presents the required enhancements to build Coordinated 
 Multicast Trees (CMT) within the TRILL campus. CMT provides 
 flexibility to RBridges to select desired path of association to a 
 given distribution tree. 


Thanks 
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

 
-------------------------------------------------------- 
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. 
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. 
This message has been scanned for viruses and Spam by ZTE Anti-Spam system. 
  
-------------------------------------------------------- 
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. 
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. 
This message has been scanned for viruses and Spam by ZTE Anti-Spam system._______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge



 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120114/f8e26d04/attachment-0001.html

From jon.hudson at gmail.com  Sat Jan 14 20:10:19 2012
From: jon.hudson at gmail.com (Jon Hudson)
Date: Sat, 14 Jan 2012 20:10:19 -0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
	active-active edge and more
In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A56559B6@xmb-sjc-214.amer.cisco.com>
References: <CE35792847FBE84687FF9117132C8EFD42EDDBE3AD@EXCH-CLUSTER-11.force10networks.com>
	<OF22F4768A.8888FDD2-ON48257985.000F1213-48257985.0017AB39@zte.com.cn>
	<344037D7CFEFE84E97E9CC1F56C5F4A56559B6@xmb-sjc-214.amer.cisco.com>
Message-ID: <DC4A9BA3-6C0F-4AA0-B94C-0D7A7806CECF@gmail.com>


Just to add a few data points

As of now only Cisco and Brocade have been shipping a "TRILL based" product 

By late 2011 numbers of units in production networks
Cisco >500
Brocade >300 

So with growth let's assume 1000-1200 total.

However neither Brocade or Ciscos solution is pure openTRILL. Both have work to do on that front.

As I understand it Force10 & Extreme will ship soon but have not yet.

In addition the affinity-TLV does not require a hardware change for anyone (that I am aware of). And since those ~1000 today will need some software updates anyway to become compliant, backwards comparability is essentially a non issue for the affinity TLV.

If the PSN-LSP solution increased scalability, or added functionality then it (or anything else that does) deserves careful consideration.  

PSN-LSP seems to only gain something that isn't hyper critical in this case and adds scaling concerns.

I often have to alleviate concerns that TRILL contains scaling issues in its use of IS-IS, I don't wish to add fuel to that fire. 

My 0x2 bits

On Jan 14, 2012, at 7:04 AM, "Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> wrote:

> Hi Hongjun
>  
> Technically speaking what you are proposing is similar to Affinity TLV approach. With the difference of using Pseudonode LSP instead of the Affinity TLV .
>  
> Main issue with PSN-LSP approach is the scale, Let me explain that in bit more details.
>  
> Affinity TLV is a single sub-TLV announced by each of the members of active-active pair or pairs.
>  
> Similarly PSN-LSP is also announced by each of the members of active-active pair or pairs.
>  
> However, PSN-LSP is a fully contained LSP that contain  multiple TLV s that needed to fully form a PSN.
>  
> This will increase the size of the LSP-DB of the campus and introduce X more additional TLVs.
>  
> There can be many  active-active pair/pairs in the network, and with this approach we have so many more additional LSP in the network.
>  
> As we know size of LSP-DB is a major scaling issue and always want to keep it as small as possible, where possible.
>  
> Lets also look at why PSN-LSP approach being proposed. It is to solve a possible backward compatibility issue.
>  
> TRILL still in infancy and there are not many TRILL networks.  So the backward compatibility is not a wide spread issue. Also affinity draft has backward compatibility mode.
>  
> What we should look at is having a solution that help us to scale better as TRILL become widely deployed in Large data-centers/Enterprises where such active-active edge is widely used.
>  
> With PSN-LSP approach I think we are unnecessarily injecting additional LSP and TLVs and making it more complicated and less scalable when we can solve with a single sub-TLV. Also Affinity TLV draft discuss backward compatibility approach, in the event there older Rbridges.
>  
> Thanks
> Tissa
>  
> From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
> Sent: Friday, January 13, 2012 8:17 PM
> To: Janardhanan Pathangi Narasimhan
> Cc: rbridge at postel.org; rbridge-bounces at postel.org; Tissa Senevirathne (tsenevir)
> Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
>  
> 
> Hi Jana, Jon and Tissa, 
> 
> > I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,   
> > and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. 
> > Is that correct? 
> 
> No, It didn't mean that the trees must rooted at RB1, RB2, respectively.  It has no any needs of where the roots of these trees are. These trees are ordinary trees calculated by all RBridges in TRILL campus wide. 
> 
> For example, there are 4 actually-calculated trees in TRILL campus, T1 through T4. T1 roots at RBi, T2 roots at RBj, T3 roots at RBm and T4 roots at RBn. If T1 and T2 are assigned to member RBridge RB1, and the rest trees to RB2. The method used to assign trees to a member RBridge is the same as given in Section 5.1 in draft CMT. 
> 
> In the below topology, Since RB1 knows it is a member RBridge of Rbridge Group RBv1 and that T1/T2 are assigned to it, RB1 can originate a pseudonode LSP(even if it has not seen any neighbors in RBv by hellos) and advertize it in TRILL campus. This pseudonode LSP contains a Nickname sub-TLV where nickname of RBv1 is carried, and a Trees sub_TLV where the wanted-to-using tress(i.e., T1 and T2) are carried, as well as a neighbor TLV where RB1 is the only neighbor contained in this pseudonode LSP. 
> 
> After receiving this  psuedonode LSP, another RBridge, e.g., RBx,  knows the paths to RBv through RB1 on T1 and T2. Then RPF information for RBv1 can be calculated correctly by RBx on these two trees. 
>                                  RBx 
>                                     | 
>                           Trill Campus 
>               |                                              | 
>    +----------+                                   +------------+ 
>    |  RB1     |                                  |  RB2       | 
>    +----------+                                  + ------------+ 
>          \                                                  / 
>           \                                               / 
>            \                                            / 
>              ----------               ----------- 
>                      >   |             |  <  Port channel (LAG) 
>                           |             | 
>                    +--------------------+ 
>                   |    CE                    | 
>                   +---------------------+ 
> 
> Besides RBv1, If RB1joins another Rbridge Group RBv2, and T2/T3 are assigned to RB1, RB1 can originates another pseudonode LSP, where nickname of RBv2 and T2/T3 are carried in Nickname sub-TLV and Trees sub-TLV, respectively. After receiving this LSP, RBx can knows path to RBv2 through RB1 on T2 and T3. RPF check information can also calculated correctly by RBx on thes two trees. 
> 
> Similar things RB2 can do, and RPF check information can be calculated correctly by RBx on the assigned trees 
>   
> > Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, 
> > and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). 
> > This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees. 
> 
> No, It does not require much more trees to build if using pseudonode LSP, instead of affinity TLV,  to notify other RBridges the affinity of RBv via RB1. It just needs to originate much more pseudonode LSPs if an Rbridge joins more than one RBridge Group. 
> 
> 
> 
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> 
> Zhai Hongjun
> 
> Tel: +86-25-52877345
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 
> 
> 
> 
> Janardhanan Pathangi Narasimhan <jana at force10networks.com> 
> ???:  rbridge-bounces at postel.org
> 2012-01-13 21:48
> 
> ???
> "zhai.hongjun at zte.com.cn" <zhai.hongjun at zte.com.cn>, "Tissa Senevirathne        (tsenevir)" <tsenevir at cisco.com>
> ??
> "rbridge at postel.org" <rbridge at postel.org>, "rbridge-bounces at postel.org" <rbridge-bounces at postel.org>
> ??
> Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
>  
> 
> 
> 
> Hi Hongjun, 
>   
> I think your proposal is that form a tree rooted at RB1 and another tree rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are forcing the affinity of RB1 or RB2 to RBV by placing the root on the RBridges themselves. Is that correct? 
>   
> Yes, this mechanism would work, but would not scale up. For e.g. in the network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 trees (10 pairs of RB). This will not scale, while with affinity TLV irrespective of number of such RB pairs which are providing such services we would need only two trees. 
>   
> Thanks 
> Jana 
>   
>   
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of zhai.hongjun at zte.com.cn
> Sent: Friday, January 13, 2012 10:35 AM
> To: Tissa Senevirathne (tsenevir)
> Cc: rbridge at postel.org; rbridge-bounces at postel.org
> Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more 
>   
> 
> Hi Tissa? 
> 
> In the diagram you given, assume 4 distribution trees are acturally calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned to RB1, T3 and T4 are assigned to RB2. 
> 
> Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are the only two neigbors)  of this pseudonode.  After receiving this pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on T1 or T2, shown in the following diagram. 
> 
>                                  RBx 
>                                     | 
>                           Trill Campus 
>               |                                              | 
>    +----------+                                   +------------+ 
>    |  RB1     |                                  |  RB2       | 
>    +----------+                                  + ------------+ 
>          \                                                   
>          /  \                                             
>        /RBv \                               
>       --------- 
>                scheme of T1 or T2 
> 
> RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned trees T1 and T2. 
> 
> RB2 also annouce similar informtion in its pseudonode LSP, then RBx can know the path to RBv through RB2 on T3 and T4. 
> 
>                                  RBx 
>                                     | 
>                           Trill Campus 
>               |                                              | 
>    +----------+                                   +------------+ 
>    |  RB1     |                                  |  RB2       | 
>    +----------+                                  + ------------+ 
>          \                                                  / 
>           \                                               / 
>            \                                            / 
>              ----------               ----------- 
>                      >   |             |  <  Port channel (LAG) 
>                           |             | 
>                    +--------------------+ 
>                   |    CE                    | 
>                   +---------------------+ 
> 
> 
> 
> 
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> 
> Zhai Hongjun
> 
> Tel: +86-25-52877345
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 
> 
> "Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com>
> 2012-01-13 12:21
> 
>  
> ???
> <zhai.hongjun at zte.com.cn>
> ??
> <rbridge at postel.org>, <rbridge-bounces at postel.org>
> ??
> RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more
> 
>  
>  
> 
> 
> 
> 
> 
> Hi Hongjun 
>  
> I am not quite clear with the way you are proposing to use assigned nicknames in the pseudonode LSP. 
>  
> Can you please us the diagram below and explain how your proposal will be used. 
>  
> CE means in the following diagram is an 802.1D device that is attached to RB1 and RB2 through Pt-Pt links and treated as a port channel from CE stand point. 
>  
>                                   RBx 
>                                     | 
>                           Trill Campus 
>               |                                              | 
>    +----------+                                   +------------+ 
>    |  RB1     |                                  |  RB2       | 
>    +----------+                                  + ------------+ 
>          \                                                  / 
>           \                                               / 
>            \                                            / 
>              ----------               ----------- 
>                      >   |             |  <  Port channel (LAG) 
>                           |             | 
>                    +--------------------+ 
>                   |    CE                    | 
>                   +---------------------+ 
>  
>  
> From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
> Sent: Thursday, January 12, 2012 7:59 PM
> To: Tissa Senevirathne (tsenevir)
> Cc: rbridge at postel.org; rbridge-bounces at postel.org
> Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on active-active edge and more 
>  
> 
> Hi Tissa, 
> 
> I have read your draft-tissa-trill-cmt-00.txt with great interests.  In this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member RBdige of a virtual RBridge group much flexibity in describing the virtual RBridge nickname and  specifying the path of association to specific distribution tree(S).  However, this new TLV causes some backward compatibilty problems between pre Affinity sub-TLV RBridges and new RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL network,the RPF check for virtual Rbridge will fail on this RBridge.
> 
> Is the Affinity Sub-TLV necessary for a member RBridge to announce the virtual Rbridge nickname and  the specific distribution trees? Maybe it is not. 
> 
> In a given vritual group, each  member Rbridge can advertise a specific pseudonode-LSP to annouce the virtual RBridge nickname and the trees assigned to it.The nickname and the assigned trees are contained in  the given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP represents a special virtual link, on which there is only one RBridge, i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge is assigned different tree(s), RPF check information for the virtual Rbrigde in different trees can be correctly calculated on all the Rbridges in TRILL network, then the member RBridge can safely use the virtual Rbridge nickname to do the necessary TRILL-encapsultion on  received native frames. 
> 
> Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is removed, while the similar flexibilty of Affinity sub-TLV remains. 
> 
> 
> Thanks,
> Zhai Hongjun
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
> No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
> 
> Zhai Hongjun
> 
> Tel: +86-25-52877345
> Email: zhai.hongjun at zte.com.cn
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> 
> "Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
> ???:  rbridge-bounces at postel.org
> 2012-01-06 10:11
> 
>  
>  
> 
> ???
> <rbridge at postel.org>
> ??
> ??
> [rbridge] Coordinated Multicast Trees to solve RPF issues on        active-active edge and more
> 
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> 
> Dear All 
> 
> We have published draft-tissa-trill-cmt-00.txt, in this document we present a flexible framework to associate child RBridges to different parent RBRidges for RPF purpose. 
> 
> Active-active forwarding at the TRILL edge is a very important feature. Representation of the active-active sub system with a single virtual RBRidge is a common practice to achieve load balancing and to avoid MAC flip flop. However, use of virtual RBridge lead to RPF failures. In this document we provide a solution to address the RPF failures. Please review and share comments. 
> 
> ID can be found in URL: http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt 
> 
> Summary: 
> 
> Filename:   draft-tissa-trill-cmt 
> Revision:   00 
> Title:            Coordinated Multicast Trees (CMT)for TRILL 
> Creation date:    2012-01-05 
> WG ID:            Individual Submission 
> Number of pages: 14 
> 
> Abstract: 
>  TRILL facilitates loop free connectivity to non TRILL legacy 
>  networks via choice of an Appointed Forwarder for set of VLANs. 
>  Appointed Forwarder provides VLAN level load sharing with active- 
>  standby model. Mission critical operations such as High Performance 
>  Data Centers require active-active load sharing model. Active-Active 
>  load sharing model can be accomplished by representing any given non 
>  TRILL legacy network with a single virtual RBridge. Virtual 
>  representation of the non-TRILL legacy network with a single RBridge 
>  poses serious challenges in multi-destination RPF calculations. This 
>  document presents the required enhancements to build Coordinated 
>  Multicast Trees (CMT) within the TRILL campus. CMT provides 
>  flexibility to RBridges to select desired path of association to a 
>  given distribution tree. 
> 
> 
> Thanks 
> Tissa_______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
>  
> -------------------------------------------------------- 
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. 
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system. 
>   
> -------------------------------------------------------- 
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. 
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system._______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
> 
>  
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120114/cf190943/attachment-0001.html

From zhai.hongjun at zte.com.cn  Sun Jan 15 18:17:55 2012
From: zhai.hongjun at zte.com.cn (zhai.hongjun@zte.com.cn)
Date: Mon, 16 Jan 2012 10:17:55 +0800
Subject: [rbridge] Coordinated Multicast Trees to solve RPF issues on
 active-active edge and more
In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A56559B6@xmb-sjc-214.amer.cisco.com>
Message-ID: <OFE894F71A.BAAA2BD5-ON48257987.000A3915-48257987.000CC700@zte.com.cn>

Hi Tissa:

Thanks for your detailed explanation. 

> Technically speaking what you are proposing is similar to Affinity TLV 
approach. With the difference of using Pseudonode LSP instead of the 
Affinity TLV .
Yes, they are similar in technically speaking. PSN-LSP approach is 
proposed to solve a backward compatibility issue.

> As we know size of LSP-DB is a major scaling issue and always want to 
keep it as small as possible, where possible.
If size of LSP-DB is really a major scaling issue, I think we should speed 
up the standardiztion of Multi-level TRILL, a draft proposed by Radia 
Perlman. I think that Multi-level TRILL is the best way to reduce the size 
of LSP-DB in a big TRILL campus.

> TRILL still in infancy and there are not many TRILL networks.  So the 
backward compatibility is not a wide spread issue. 
> Also affinity draft has backward compatibility mode.
OK, At present(TRILL still in infancy), if backward compatibility issue 
caused by Affinity TLV can be accepted, Affinity TLV is OK. I just gave my 
suggestion to solve the back compatibility issue caused by affinity TLV. 
I'm glad to see any one good technology to be standardized.


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""





"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
2012-01-14 23:04

收件人
<zhai.hongjun at zte.com.cn>, "Janardhanan Pathangi Narasimhan" 
<jana at force10networks.com>
抄送
<rbridge at postel.org>, <rbridge-bounces at postel.org>
主题
RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more






Hi Hongjun
 
Technically speaking what you are proposing is similar to Affinity TLV 
approach. With the difference of using Pseudonode LSP instead of the 
Affinity TLV .
 
Main issue with PSN-LSP approach is the scale, Let me explain that in bit 
more details.
 
Affinity TLV is a single sub-TLV announced by each of the members of 
active-active pair or pairs.
 
Similarly PSN-LSP is also announced by each of the members of 
active-active pair or pairs.
 
However, PSN-LSP is a fully contained LSP that contain  multiple TLV s 
that needed to fully form a PSN.
 
This will increase the size of the LSP-DB of the campus and introduce X 
more additional TLVs.
 
There can be many  active-active pair/pairs in the network, and with this 
approach we have so many more additional LSP in the network.
 
As we know size of LSP-DB is a major scaling issue and always want to keep 
it as small as possible, where possible.
 
Lets also look at why PSN-LSP approach being proposed. It is to solve a 
possible backward compatibility issue.
 
TRILL still in infancy and there are not many TRILL networks.  So the 
backward compatibility is not a wide spread issue. Also affinity draft has 
backward compatibility mode.
 
What we should look at is having a solution that help us to scale better 
as TRILL become widely deployed in Large data-centers/Enterprises where 
such active-active edge is widely used.
 
With PSN-LSP approach I think we are unnecessarily injecting additional 
LSP and TLVs and making it more complicated and less scalable when we can 
solve with a single sub-TLV. Also Affinity TLV draft discuss backward 
compatibility approach, in the event there older Rbridges.
 
Thanks
Tissa
 
From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
Sent: Friday, January 13, 2012 8:17 PM
To: Janardhanan Pathangi Narasimhan
Cc: rbridge at postel.org; rbridge-bounces at postel.org; Tissa Senevirathne 
(tsenevir)
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more
 

Hi Jana, Jon and Tissa, 

> I think your proposal is that form a tree rooted at RB1 and another tree 
rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,   
> and similarly the tree rooted at RB2 would have RB2-RBV link. Hence you 
are forcing the affinity of RB1 or RB2 to RBV by placing the root on the 
RBridges themselves. 
> Is that correct? 

No, It didn't mean that the trees must rooted at RB1, RB2, respectively. 
It has no any needs of where the roots of these trees are. These trees are 
ordinary trees calculated by all RBridges in TRILL campus wide. 

For example, there are 4 actually-calculated trees in TRILL campus, T1 
through T4. T1 roots at RBi, T2 roots at RBj, T3 roots at RBm and T4 roots 
at RBn. If T1 and T2 are assigned to member RBridge RB1, and the rest 
trees to RB2. The method used to assign trees to a member RBridge is the 
same as given in Section 5.1 in draft CMT. 

In the below topology, Since RB1 knows it is a member RBridge of Rbridge 
Group RBv1 and that T1/T2 are assigned to it, RB1 can originate a 
pseudonode LSP(even if it has not seen any neighbors in RBv by hellos) and 
advertize it in TRILL campus. This pseudonode LSP contains a Nickname 
sub-TLV where nickname of RBv1 is carried, and a Trees sub_TLV where the 
wanted-to-using tress(i.e., T1 and T2) are carried, as well as a neighbor 
TLV where RB1 is the only neighbor contained in this pseudonode LSP. 

After receiving this  psuedonode LSP, another RBridge, e.g., RBx,  knows 
the paths to RBv through RB1 on T1 and T2. Then RPF information for RBv1 
can be calculated correctly by RBx on these two trees. 
                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                  / 
          \                                               / 
           \                                            / 
             ----------               ----------- 
                     >   |             |  <  Port channel (LAG) 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 

Besides RBv1, If RB1joins another Rbridge Group RBv2, and T2/T3 are 
assigned to RB1, RB1 can originates another pseudonode LSP, where nickname 
of RBv2 and T2/T3 are carried in Nickname sub-TLV and Trees sub-TLV, 
respectively. After receiving this LSP, RBx can knows path to RBv2 through 
RB1 on T2 and T3. RPF check information can also calculated correctly by 
RBx on thes two trees. 

Similar things RB2 can do, and RPF check information can be calculated 
correctly by RBx on the assigned trees 
  
> Yes, this mechanism would work, but would not scale up. For e.g. in the 
network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, 
RB3-RB4 providing RBV2, 
> and so on, then to ensure that RB1-RBV1, RB2-RBV1, RB3-RBV2, RB4-RBV2 
and so on are present, we will have to minimum build 20 trees (10 pairs of 
RB). 
> This will not scale, while with affinity TLV irrespective of number of 
such RB pairs which are providing such services we would need only two 
trees. 

No, It does not require much more trees to build if using pseudonode LSP, 
instead of affinity TLV,  to notify other RBridges the affinity of RBv via 
RB1. It just needs to originate much more pseudonode LSPs if an Rbridge 
joins more than one RBridge Group. 



Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""




Janardhanan Pathangi Narasimhan <jana at force10networks.com> 
发件人:  rbridge-bounces at postel.org 
2012-01-13 21:48 


收件人
"zhai.hongjun at zte.com.cn" <zhai.hongjun at zte.com.cn>, "Tissa Senevirathne   
  (tsenevir)" <tsenevir at cisco.com> 
抄送
"rbridge at postel.org" <rbridge at postel.org>, "rbridge-bounces at postel.org" 
<rbridge-bounces at postel.org> 
主题
Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more
 








Hi Hongjun, 
  
I think your proposal is that form a tree rooted at RB1 and another tree 
rooted at RB2. The tree rooted at RB1 would have RBV-RB1 link,  and 
similarly the tree rooted at RB2 would have RB2-RBV link. Hence you are 
forcing the affinity of RB1 or RB2 to RBV by placing the root on the 
RBridges themselves. Is that correct? 
  
Yes, this mechanism would work, but would not scale up. For e.g. in the 
network, if we have 10 such pairs of RB, i.e. RB1-RB2 providing RBV1, 
RB3-RB4 providing RBV2, and so on, then to ensure that RB1-RBV1, RB2-RBV1, 
RB3-RBV2, RB4-RBV2 and so on are present, we will have to minimum build 20 
trees (10 pairs of RB). This will not scale, while with affinity TLV 
irrespective of number of such RB pairs which are providing such services 
we would need only two trees. 
  
Thanks 
Jana 
  
  
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On 
Behalf Of zhai.hongjun at zte.com.cn
Sent: Friday, January 13, 2012 10:35 AM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: Re: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more 
  

Hi Tissa， 

In the diagram you given, assume 4 distribution trees are acturally 
calculated in TRILL campus, i.e., T1 through T4.  T1 and T2 are assigned 
to RB1, T3 and T4 are assigned to RB2. 

Even if RB1 can not see  RB2 by hellos, (I think that) RB1 can generate a 
pseudonode LSP, Pseu-LSP-RB1,  to announce the virtual RBridge (RBv) 
nickname and the trees assigned to it, i.e, T1 and T2.  In this pseudonode 
LSP,  RB1 is the only one neighbor (or RB1 and the virtual RBridge RBv are 
the only two neigbors)  of this pseudonode.  After receiving this 
pseudonode LSP,  RBx can  know the path to  pseudonode RBv through RB1 on 
T1 or T2, shown in the following diagram. 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \ 
         /  \                                             
       /RBv \ 
      --------- 
               scheme of T1 or T2 

RB1 uses Nickname Sub-TLV and Trees Sub-TLV (instead of the Affinity 
sub-TLV) in Pseu-LSP-RB1, to contains the RBv's nickname and the assigned 
trees T1 and T2. 

RB2 also annouce similar informtion in its pseudonode LSP, then RBx can 
know the path to RBv through RB2 on T3 and T4. 

                                 RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                  / 
          \                                               / 
           \                                            / 
             ----------               ----------- 
                     >   |             |  <  Port channel (LAG) 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 




Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""


"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
2012-01-13 12:21 
 


收件人
<zhai.hongjun at zte.com.cn> 
抄送
<rbridge at postel.org>, <rbridge-bounces at postel.org> 
主题
RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more

  
 









Hi Hongjun 
 
I am not quite clear with the way you are proposing to use assigned 
nicknames in the pseudonode LSP. 
 
Can you please us the diagram below and explain how your proposal will be 
used. 
 
CE means in the following diagram is an 802.1D device that is attached to 
RB1 and RB2 through Pt-Pt links and treated as a port channel from CE 
stand point. 
 
                                  RBx 
                                    | 
                          Trill Campus 
              |                                              | 
   +----------+                                   +------------+ 
   |  RB1     |                                  |  RB2       | 
   +----------+                                  + ------------+ 
         \                                                  / 
          \                                               / 
           \                                            / 
             ----------               ----------- 
                     >   |             |  <  Port channel (LAG) 
                          |             | 
                   +--------------------+ 
                  |    CE                    | 
                  +---------------------+ 
 
 
From: zhai.hongjun at zte.com.cn [mailto:zhai.hongjun at zte.com.cn] 
Sent: Thursday, January 12, 2012 7:59 PM
To: Tissa Senevirathne (tsenevir)
Cc: rbridge at postel.org; rbridge-bounces at postel.org
Subject: RE: [rbridge] Coordinated Multicast Trees to solve RPF issues on 
active-active edge and more 
 

Hi Tissa, 

I have read your draft-tissa-trill-cmt-00.txt with great interests.  In 
this draft, a new TLV, Affinity Sub-TLV, is introduced to give a member 
RBdige of a virtual RBridge group much flexibity in describing the virtual 
RBridge nickname and  specifying the path of association to specific 
distribution tree(S).  However, this new TLV causes some backward 
compatibilty problems between pre Affinity sub-TLV RBridges and new 
RBridges. Even if there is only one pre Affinity sub-TLV RBridge in TRILL 
network,the RPF check for virtual Rbridge will fail on this RBridge.

Is the Affinity Sub-TLV necessary for a member RBridge to announce the 
virtual Rbridge nickname and  the specific distribution trees? Maybe it is 
not. 

In a given vritual group, each  member Rbridge can advertise a specific 
pseudonode-LSP to annouce the virtual RBridge nickname and the trees 
assigned to it.The nickname and the assigned trees are contained in  the 
given Nickname Sub-TLV and Trees Sub-TLV in RFC6326. This pseudonode-LSP 
represents a special virtual link, on which there is only one RBridge, 
i.e.,  the RBridge advertising this LSP.  Only if different member Rbridge 
is assigned different tree(s), RPF check information for the virtual 
Rbrigde in different trees can be correctly calculated on all the Rbridges 
in TRILL network, then the member RBridge can safely use the virtual 
Rbridge nickname to do the necessary TRILL-encapsultion on  received 
native frames. 

Therefore, backward compatibilty problems, caused by Affinity sub-TLV, is 
removed, while the similar flexibilty of Affinity sub-TLV remains. 


Thanks,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012

Zhai Hongjun

Tel: +86-25-52877345
Email: zhai.hongjun at zte.com.cn
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

"Tissa Senevirathne (tsenevir)" <tsenevir at cisco.com> 
发件人:  rbridge-bounces at postel.org 
2012-01-06 10:11 
  
 


收件人
<rbridge at postel.org> 
抄送

主题
[rbridge] Coordinated Multicast Trees to solve RPF issues on active-active 
edge and more


  
  
 









Dear All 

We have published draft-tissa-trill-cmt-00.txt, in this document we 
present a flexible framework to associate child RBridges to different 
parent RBRidges for RPF purpose. 

Active-active forwarding at the TRILL edge is a very important feature. 
Representation of the active-active sub system with a single virtual 
RBRidge is a common practice to achieve load balancing and to avoid MAC 
flip flop. However, use of virtual RBridge lead to RPF failures. In this 
document we provide a solution to address the RPF failures. Please review 
and share comments. 

ID can be found in URL: 
http://www.ietf.org/id/draft-tissa-trill-cmt-00.txt 

Summary: 

Filename:   draft-tissa-trill-cmt 
Revision:   00 
Title:            Coordinated Multicast Trees (CMT)for TRILL 
Creation date:    2012-01-05 
WG ID:            Individual Submission 
Number of pages: 14 

Abstract: 
 TRILL facilitates loop free connectivity to non TRILL legacy 
 networks via choice of an Appointed Forwarder for set of VLANs. 
 Appointed Forwarder provides VLAN level load sharing with active- 
 standby model. Mission critical operations such as High Performance 
 Data Centers require active-active load sharing model. Active-Active 
 load sharing model can be accomplished by representing any given non 
 TRILL legacy network with a single virtual RBridge. Virtual 
 representation of the non-TRILL legacy network with a single RBridge 
 poses serious challenges in multi-destination RPF calculations. This 
 document presents the required enhancements to build Coordinated 
 Multicast Trees (CMT) within the TRILL campus. CMT provides 
 flexibility to RBridges to select desired path of association to a 
 given distribution tree. 


Thanks 
Tissa_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

 
-------------------------------------------------------- 
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others. 
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender. 
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system. 
  
-------------------------------------------------------- 
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others. 
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender. 
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system._______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120116/89cb6c1b/attachment-0001.html

From d3e3e3 at gmail.com  Mon Jan 16 14:05:35 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 16 Jan 2012 17:05:35 -0500
Subject: [rbridge] Tweaks to draf-ietf-trill-rbridge-channel
Message-ID: <CAF4+nEGJHDy_EtHbT5nQfh4SW2daeegU4k0kKNqoz_s+tHcgQg@mail.gmail.com>

Unless there is some objection, I'd like to update
draft-ietf-trill-rbridge-channel-03 for the following:
- addition of a critical (as well as the previous non-critical)
RBridge Channel Alert Flag (see draft-ietf-trill-rbridge-extension-02)
- change of the CFI bit into the DEI bit (see
draft-eastlake-trill-rbridge-clear-correct-03)
- change in author info

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


From mgururam at gmail.com  Tue Jan 17 23:22:43 2012
From: mgururam at gmail.com (gururam m)
Date: Wed, 18 Jan 2012 12:52:43 +0530
Subject: [rbridge] Special VLANs and Flags Sub-TLV query..
Message-ID: <CADaSLpVTfwb7VygGsALT9zzZ3nAi=6QqgxzM8biXnk8=DDtB3A@mail.gmail.com>

Hi,
      In RFC 6326 the special VLANs and Flags Sub-TLV has "Sender Nickname"
filed. If an RBridge has single nickname then that will be included in the
"Sender Nickname" field. But what if the RBridge supports multiple
nicknames let us say 4 of them. Then which one of the 4 nicknames is sent
in the "Sender Nickname" field  in the above sub-TLV.

Regards
Ram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120118/5e7583f5/attachment.html

From d3e3e3 at gmail.com  Wed Jan 18 00:54:46 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 18 Jan 2012 03:54:46 -0500
Subject: [rbridge] Special VLANs and Flags Sub-TLV query..
In-Reply-To: <CADaSLpVTfwb7VygGsALT9zzZ3nAi=6QqgxzM8biXnk8=DDtB3A@mail.gmail.com>
References: <CADaSLpVTfwb7VygGsALT9zzZ3nAi=6QqgxzM8biXnk8=DDtB3A@mail.gmail.com>
Message-ID: <CAF4+nEH=Q+3rPvEkX1hc0x1RYEfQOY_1fMkaRut48C6Lw4hePw@mail.gmail.com>

Hi,

It is an implementation choice. I can't off hand see any reason why it
would make any difference. The only uses of this "Sender Nickname"
field in Hellos are

(1) To tell end stations that are doing TRILL encapsulation what
nickname to put in the ingress nickname field of the TRILL Header.
(see point 8 near the start of Section 4.6.2 of RFC 6325)

(2) If the relevant part of the clarifications an corrections draft is
adopted, it would also be used for self appointment sub-TLVs as per
Section 10.1 of draft-eastlake-trill-rbridge-clear-correct-03.txt.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com



On Wed, Jan 18, 2012 at 2:22 AM, gururam m <mgururam at gmail.com> wrote:
> Hi,
> ?? ?? In RFC 6326 the special VLANs and Flags Sub-TLV has "Sender Nickname"
> filed. If an RBridge has single nickname then that will be included in the
> "Sender Nickname" field. But what if the RBridge supports multiple nicknames
> let us say 4 of them. Then which one of the 4 nicknames is sent in the
> "Sender Nickname" field? in the above sub-TLV.
>
> Regards
> Ram
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>


From kesavka at gmail.com  Wed Jan 18 04:44:42 2012
From: kesavka at gmail.com (keshav karedla)
Date: Wed, 18 Jan 2012 18:14:42 +0530
Subject: [rbridge] Tree adjacency check and RPF check
Message-ID: <CAFAgR7fzLAMb7E-fWN1Yp-Un2WrzwJh_uRoVCQ6GDk4nvdGBiw@mail.gmail.com>

Hi Authors,

Can you please tell us the scenarios where Tree adjacency check fails and
RPF check passes and vice-versa.
I am not clear whether these two checks are required or not, what I am
thinking is only RPF check will do the both jobs.

please Clarify.

Regards,
Keshav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120118/b73395b7/attachment.html

From d3e3e3 at gmail.com  Wed Jan 18 06:07:54 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Wed, 18 Jan 2012 09:07:54 -0500
Subject: [rbridge] Tree adjacency check and RPF check
In-Reply-To: <CAFAgR7fzLAMb7E-fWN1Yp-Un2WrzwJh_uRoVCQ6GDk4nvdGBiw@mail.gmail.com>
References: <CAFAgR7fzLAMb7E-fWN1Yp-Un2WrzwJh_uRoVCQ6GDk4nvdGBiw@mail.gmail.com>
Message-ID: <CAF4+nEGKW9q11vJKo61Su=AJyMX7GhnObDgujzU=XdROpazCKg@mail.gmail.com>

Hi Keshav,

On Wed, Jan 18, 2012 at 7:44 AM, keshav karedla <kesavka at gmail.com> wrote:
> Hi Authors,
>
> Can you please tell us the scenarios where Tree adjacency check fails and
> RPF check passes and vice-versa.

I assume you are talking about the checks in Section 4.5.2 of RFC 6325.

The Tree adjacency check only applies on a multi-access link, such as
an Ethernet link, where they might be a station sending to you that is
not a Tree adjacency. It is basically a test on the source MAC address
and tree root nickname.

The RPF check is a check on the triplet (receiving port, ingress
nickname, tree root nickname) to see it if corresponds to one allowed
by the receiver based on the distribution trees it has built. It does
not involve the source MAC.

> I am not clear whether these two checks are required or not, what I am
> thinking is only RPF check will do the both jobs.

Well, the TRILL base protocol specification currently requires both
tests. You could certainly combine them by testing a quadruplet of
fields that included the source MAC.

If everything is stable and operating properly, you don't need to do
any tests at all. If there are routing transients and ports/links
going up and down and/or some end station trying to forge stuff, I
think you are better off applying both tests.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> please Clarify.
>
> Regards,
> Keshav


From internet-drafts at ietf.org  Wed Jan 18 13:18:19 2012
From: internet-drafts at ietf.org (internet-drafts@ietf.org)
Date: Wed, 18 Jan 2012 13:18:19 -0800
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-channel-04.txt
Message-ID: <20120118211819.28779.25195.idtracker@ietfa.amsl.com>


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : TRILL: RBridge Channel Support
	Author(s)       : Donald Eastlake
                          Vishwas Manral
                          Yizhou Li
                          Sam Aldrin
                          Dave Ward
	Filename        : draft-ietf-trill-rbridge-channel-04.txt
	Pages           : 25
	Date            : 2012-01-18

   This document specifies a general channel mechanism for sending
   messages, such as OAM (Operations, Administration, and Maintenance)
   messages, between RBridges (Routing Bridges) and between RBridges and
   end stations in an RBridge campus through extensions to the TRILL
   (TRansparent Interconnection of Lots of Links) protocol.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-channel-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-channel-04.txt



From internet-drafts at ietf.org  Tue Jan 24 15:53:13 2012
From: internet-drafts at ietf.org (internet-drafts@ietf.org)
Date: Tue, 24 Jan 2012 15:53:13 -0800
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-bfd-02.txt
Message-ID: <20120124235313.29775.78710.idtracker@ietfa.amsl.com>


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : Rbridges: Bidirectional Forwarding Detection (BFD) support for TRILL
	Author(s)       : Vishwas Manral
                          Donald Eastlake
                          Dave Ward
                          Ayan Banerjee
	Filename        : draft-ietf-trill-rbridge-bfd-02.txt
	Pages           : 10
	Date            : 2012-01-24

   This document specifies use of the BFD (Bidirectional Forwarding
   Detection) protocol in RBridge campuses based on the Rbridge Channel
   extension to the the TRILL (TRansparent Interconnection of Lots of
   Links) protocol.

   BFD is a widely deployed OAM (Operations, Administration, and
   Maintenance) mechanism in IP and MPLS networks, using UDP and ACH
   encapsulation respectively.  This document specifies the BFD
   encapsulation over TRILL.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-02.txt



From jon.hudson at gmail.com  Tue Jan 24 23:55:47 2012
From: jon.hudson at gmail.com (Jon Hudson)
Date: Tue, 24 Jan 2012 23:55:47 -0800
Subject: [rbridge] Should we make
 draft-eastlake-trill-clear-correct-03.txt a WG document?
In-Reply-To: <4F0C38D4.7050801@acm.org>
References: <4F0C38D4.7050801@acm.org>
Message-ID: <CANbjNQF0d_N_OkJfKqxhW8JEdqVemp4tKmj7QDBDoFHQu5M==A@mail.gmail.com>

I agree.

I also support the adoption of draft-eastlake-trill-clear-correct-03.txt as
a WG document.

Jon

On Tue, Jan 10, 2012 at 5:10 AM, Erik Nordmark <nordmark at acm.org> wrote:

>
> Donald presented this document in Taipei, and the authors have revised
> it since then.
>
> I think the document contains useful clarifications. Should we adopt it
> as a WG document?
>
> Please send any comments to the list before January 25th.
>
>    Erik
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>



-- 
"Do not lie. And do not do what you hate."
"Don't worry, be happy"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120124/8409fbe5/attachment.html

From jana at force10networks.com  Wed Jan 25 02:13:18 2012
From: jana at force10networks.com (Janardhanan Pathangi Narasimhan)
Date: Wed, 25 Jan 2012 15:43:18 +0530
Subject: [rbridge] Should we make
 draft-eastlake-trill-clear-correct-03.txt a WG document?
In-Reply-To: <CANbjNQF0d_N_OkJfKqxhW8JEdqVemp4tKmj7QDBDoFHQu5M==A@mail.gmail.com>
References: <4F0C38D4.7050801@acm.org>
	<CANbjNQF0d_N_OkJfKqxhW8JEdqVemp4tKmj7QDBDoFHQu5M==A@mail.gmail.com>
Message-ID: <CE35792847FBE84687FF9117132C8EFD437D0E41F2@EXCH-CLUSTER-11.force10networks.com>

+1

Thanks
Jana


From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Jon Hudson
Sent: Wednesday, January 25, 2012 1:26 PM
To: rbridge at postel.org
Cc: Erik Nordmark
Subject: Re: [rbridge] Should we make draft-eastlake-trill-clear-correct-03.txt a WG document?

I agree.

I also support the adoption of draft-eastlake-trill-clear-correct-03.txt as a WG document.

Jon

On Tue, Jan 10, 2012 at 5:10 AM, Erik Nordmark <nordmark at acm.org<mailto:nordmark at acm.org>> wrote:

Donald presented this document in Taipei, and the authors have revised
it since then.

I think the document contains useful clarifications. Should we adopt it
as a WG document?

Please send any comments to the list before January 25th.

   Erik
_______________________________________________
rbridge mailing list
rbridge at postel.org<mailto:rbridge at postel.org>
http://mailman.postel.org/mailman/listinfo/rbridge



--
"Do not lie. And do not do what you hate."
"Don't worry, be happy"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120125/b77b9159/attachment.html

From radiaperlman at gmail.com  Wed Jan 25 06:54:52 2012
From: radiaperlman at gmail.com (Radia Perlman)
Date: Wed, 25 Jan 2012 06:54:52 -0800
Subject: [rbridge] Should we make
 draft-eastlake-trill-clear-correct-03.txt a WG document?
In-Reply-To: <CANbjNQF0d_N_OkJfKqxhW8JEdqVemp4tKmj7QDBDoFHQu5M==A@mail.gmail.com>
References: <4F0C38D4.7050801@acm.org>
	<CANbjNQF0d_N_OkJfKqxhW8JEdqVemp4tKmj7QDBDoFHQu5M==A@mail.gmail.com>
Message-ID: <CAFOuuo7BMfx6q_aVfCbxGwaWa6a6je4eNSrOhojzafYyONeMig@mail.gmail.com>

I also support adoption of draft-eastlake-trill-clear-correct-03.txt as a
WG document.

Radia

On Tue, Jan 24, 2012 at 11:55 PM, Jon Hudson <jon.hudson at gmail.com> wrote:

> I agree.
>
> I also support the adoption of draft-eastlake-trill-clear-correct-03.txt
> as a WG document.
>
> Jon
>
> On Tue, Jan 10, 2012 at 5:10 AM, Erik Nordmark <nordmark at acm.org> wrote:
>
>>
>> Donald presented this document in Taipei, and the authors have revised
>> it since then.
>>
>> I think the document contains useful clarifications. Should we adopt it
>> as a WG document?
>>
>> Please send any comments to the list before January 25th.
>>
>>    Erik
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>
>
>
> --
> "Do not lie. And do not do what you hate."
> "Don't worry, be happy"
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120125/69f12b54/attachment.html

From narten at us.ibm.com  Wed Jan 25 08:27:04 2012
From: narten at us.ibm.com (Thomas Narten)
Date: Wed, 25 Jan 2012 11:27:04 -0500
Subject: [rbridge] Should we make
	draft-eastlake-trill-clear-correct-03.txt a WG document?
In-Reply-To: <4F0C38D4.7050801@acm.org>
References: <4F0C38D4.7050801@acm.org>
Message-ID: <201201251627.q0PGR53a006267@cichlid.raleigh.ibm.com>

Support.

Thomas


From tsenevir at cisco.com  Wed Jan 25 08:37:21 2012
From: tsenevir at cisco.com (Tissa Senevirathne (tsenevir))
Date: Wed, 25 Jan 2012 08:37:21 -0800
Subject: [rbridge] Should we make
	draft-eastlake-trill-clear-correct-03.txt a WG document?
In-Reply-To: <CANbjNQF0d_N_OkJfKqxhW8JEdqVemp4tKmj7QDBDoFHQu5M==A@mail.gmail.com>
References: <4F0C38D4.7050801@acm.org>
	<CANbjNQF0d_N_OkJfKqxhW8JEdqVemp4tKmj7QDBDoFHQu5M==A@mail.gmail.com>
Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A5790603@xmb-sjc-214.amer.cisco.com>

I agree too.

 

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Jon Hudson
Sent: Tuesday, January 24, 2012 11:56 PM
To: rbridge at postel.org
Cc: Erik Nordmark
Subject: Re: [rbridge] Should we make
draft-eastlake-trill-clear-correct-03.txt a WG document?

 

I agree. 

 

I also support the adoption of draft-eastlake-trill-clear-correct-03.txt
as a WG document. 

 

Jon

 

On Tue, Jan 10, 2012 at 5:10 AM, Erik Nordmark <nordmark at acm.org> wrote:


Donald presented this document in Taipei, and the authors have revised
it since then.

I think the document contains useful clarifications. Should we adopt it
as a WG document?

Please send any comments to the list before January 25th.

   Erik
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge





 

-- 
"Do not lie. And do not do what you hate."
"Don't worry, be happy"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120125/4e750e5e/attachment-0001.html

From vishwas.ietf at gmail.com  Wed Jan 25 11:27:35 2012
From: vishwas.ietf at gmail.com (Vishwas Manral)
Date: Wed, 25 Jan 2012 11:27:35 -0800
Subject: [rbridge] Should we make
 draft-eastlake-trill-clear-correct-03.txt a WG document?
In-Reply-To: <4F0C38D4.7050801@acm.org>
References: <4F0C38D4.7050801@acm.org>
Message-ID: <CAOyVPHTTWh62O+TZdkmWVrP844fj5xfeCELBrzX0kswN9H5yvg@mail.gmail.com>

Support as an author.

-Vishwas

On 1/10/12, Erik Nordmark <nordmark at acm.org> wrote:
>
> Donald presented this document in Taipei, and the authors have revised
> it since then.
>
> I think the document contains useful clarifications. Should we adopt it
> as a WG document?
>
> Please send any comments to the list before January 25th.
>
>     Erik
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

From internet-drafts at ietf.org  Thu Jan 26 13:18:09 2012
From: internet-drafts at ietf.org (internet-drafts@ietf.org)
Date: Thu, 26 Jan 2012 13:18:09 -0800
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-mib-05.txt
Message-ID: <20120126211809.4288.12618.idtracker@ietfa.amsl.com>


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : Definitions of Managed Objects for RBridges (Routing Bridges)
	Author(s)       : Anil Rijhsinghani
                          Kate Zebrose
	Filename        : draft-ietf-trill-rbridge-mib-05.txt
	Pages           : 56
	Date            : 2012-01-26

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing an RBridge (Routing Bridge), also known as a
   TRILL Switch, based on the IETF TRILL (Transparent Interconnection of
   Lots of Links) protocol described in RFC 6325.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-05.txt



From nordmark at acm.org  Thu Jan 26 13:45:16 2012
From: nordmark at acm.org (Erik Nordmark)
Date: Thu, 26 Jan 2012 13:45:16 -0800
Subject: [rbridge] Accepted draft-eastlake-trill-clear-correct-03.txt as a
	WG document
In-Reply-To: <4F0C38D4.7050801@acm.org>
References: <4F0C38D4.7050801@acm.org>
Message-ID: <4F21C96C.7050302@acm.org>


Based on the feedback on the mailing list we'll make this a WG document.

Thanks,
     Erik

On 1/10/12 5:10 AM, Erik Nordmark wrote:
>
> Donald presented this document in Taipei, and the authors have revised
> it since then.
>
> I think the document contains useful clarifications. Should we adopt it
> as a WG document?
>
> Please send any comments to the list before January 25th.
>
>      Erik
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>


From nitks.abhinav at gmail.com  Thu Jan 26 21:37:27 2012
From: nitks.abhinav at gmail.com (Abhinav Bhatia)
Date: Fri, 27 Jan 2012 11:07:27 +0530
Subject: [rbridge] Queries on RFC 6325 - Forming neighbors on L2 access port
Message-ID: <CAKn+7dKk+N4QSXpRF51wb32z=2dLtn7huZsN+RzPXSFfiGLUoA@mail.gmail.com>

Hi,

I have a query regarding forming neighbors between L2 access ports.

"  A TRILL IS-IS frame on an 802.3 link is structured as shown below.
   All such frames are Ethertype encoded.  The RBridge port out of which
   such a frame is sent will strip the outer VLAN tag if configured to
   do so."

If a port is configured as layer 2 access port , then while sending the
trill control frame it will strip off the vlan id.

What should be the behavior on the recieving side (if RBridge), since we
expect trill control frames to be on dvlan or some other vlan , should the
frame be dropped and neighbor is avoided?. If not then how we will come to
know on which vlan the fame has arrived and is there any vlan mapping or
not?

Regards,
Abhinav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120127/b14e1280/attachment.html

From d3e3e3 at gmail.com  Fri Jan 27 05:58:03 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 27 Jan 2012 08:58:03 -0500
Subject: [rbridge] Queries on RFC 6325 - Forming neighbors on L2 access
	port
In-Reply-To: <CAKn+7dKk+N4QSXpRF51wb32z=2dLtn7huZsN+RzPXSFfiGLUoA@mail.gmail.com>
References: <CAKn+7dKk+N4QSXpRF51wb32z=2dLtn7huZsN+RzPXSFfiGLUoA@mail.gmail.com>
Message-ID: <CAF4+nEGN_j=OxFNkgrGUUvowm6ZRr5V8aiY7R2ONy+oRFTWH=A@mail.gmail.com>

Hi Abhinav,

On Fri, Jan 27, 2012 at 12:37 AM, Abhinav Bhatia
<nitks.abhinav at gmail.com> wrote:
> Hi,
>
> I have a query regarding forming neighbors between L2 access ports.
>
> "  A TRILL IS-IS frame on an 802.3 link is structured as shown below.
>    All such frames are Ethertype encoded.  The RBridge port out of which
>    such a frame is sent will strip the outer VLAN tag if configured to
>    do so."
>
> If a port is configured as layer 2 access port , then while sending the
> trill control frame it will strip off the vlan id.

I'm not 100% sure what you mean by "layer 2 access port". There is the
TRILL access port configuration bit, formally known as the TRILL
traffic disable bit, which has to do with stopping the port from being
used by TRILL Data frames and has nothing to do with VLAN labeling.
But I think you mean the 802.1Q port configuration which controls
whether or not there is actually an outer VLAN tag when the frame is
transmitted on the link. These two configurations can be set
independently from each other.

> What should be the behavior on the recieving side (if RBridge), since we
> expect trill control frames to be on dvlan or some other vlan , should the
> frame be dropped and neighbor is avoided?.

Just like the 802.1Q customer bridge forwarding function, the
TRILL/RBridge logic and forwarding function have no idea whether the
frame was actually VLAN tagged on the wire. If the received frame
makes it through the lower levels of the port logic, which are the
same for an RBridge and for an 802.1Q customer bridge, by the time it
gets to the higher level logic, there will always be a VLAN ID
associated with it. I'm not sure what "avoiding" a neighbor would
mean.

> If not then how we will come to
> know on which vlan the fame has arrived and is there any vlan mapping or
> not?

The lower layers of RBridge ports are just like 802.1Q customer bridge
ports. The vlan "on which ... the frame has arrived" is just whatever
the EISS interface reports to higher layers. If the frame was untagged
on the link, it is the port VLAN ID. If you have a multi-access link
with multiple RBridge ports on it and those ports are configured
inconsistently as to their port VLAN ID, then the same TRILL frame
that was transmitted untagged will appear to "arrive" on different
VLANs on different ports.
     If the TRILL frame is a TRILL IS-IS Hello frame, then at most one
of such ports could find that the VLAN of the frame matches the saved
copy of the VLAN on which the frame was sent. All other ports will
detect VLAN mapping and the DRB will take appropriate action
concerning appointed forwarders, if necessary. However, TRILL IS-IS
frames are still processed regardless of what VLAN they appear to
arrive on.
     If the TRILL frame is a TRILL Data frame, TRILL doesn't care what
VLAN it "arrives on". The Outer.VLAN, just like the outer source and
destination MAC addresses, are just transport artifacts to get the
TRILL Data payload (which starts with the TRILL Header) from one
RBridge to the next. (Also, TRILL unicast and multi-destination Data
forwarding are not affected by appointed forwarders or port
inhibition.)

I hope the above makes things clearer.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com

> Regards,
> Abhinav


From internet-drafts at ietf.org  Fri Jan 27 14:09:56 2012
From: internet-drafts at ietf.org (internet-drafts@ietf.org)
Date: Fri, 27 Jan 2012 14:09:56 -0800
Subject: [rbridge] I-D Action: draft-ietf-trill-clear-correct-00.txt
Message-ID: <20120127220956.32307.80501.idtracker@ietfa.amsl.com>


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : TRILL: Clarifications, Corrections, and Updates
	Author(s)       : Donald Eastlake
                          Mingui Zhang
                          Anoop Ghanwani
                          Ayan Banerjee
                          Vishwas Manral
	Filename        : draft-ietf-trill-clear-correct-00.txt
	Pages           : 28
	Date            : 2012-01-27

   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol provides least cost pair-wise data forwarding without
   configuration in multi-hop networks with arbitrary topology, safe
   forwarding even during periods of temporary loops, and support for
   multipathing of both unicast and multicast traffic. TRILL
   accomplishes this by using IS-IS (Intermediate System to Intermediate
   System) link state routing and by encapsulating traffic using a
   header that includes a hop count. Since the TRILL base protocol was
   approved in March 2010, active development of TRILL has revealed a
   few errata in the original RFC 6325 and some cases that could use
   clarifications or updates.

   RFC 6327, RFC 6439, and RFC XXXX, provide clarifications with respect
   to Adjacency, Appointed Forwarders, and the TRILL ESADI protocol.
   This document provide other known clarifications, corrections, and
   updates to RFC 6325, RFC 6327, and RFC 6439.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-clear-correct-00.txt



From d3e3e3 at gmail.com  Fri Jan 27 14:34:38 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 27 Jan 2012 17:34:38 -0500
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-mib-05.txt
In-Reply-To: <20120126211809.4288.12618.idtracker@ietfa.amsl.com>
References: <20120126211809.4288.12618.idtracker@ietfa.amsl.com>
Message-ID: <CAF4+nEH6EJ_VMCMsTJzOWowN0C2NwnAdkfyNzQ5LEyrHO1ZggQ@mail.gmail.com>

The revision below is to resolve IESG comments...

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com

On Thu, Jan 26, 2012 at 4:18 PM,  <internet-drafts at ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.
>
> ? ? ? ?Title ? ? ? ? ? : Definitions of Managed Objects for RBridges (Routing Bridges)
> ? ? ? ?Author(s) ? ? ? : Anil Rijhsinghani
> ? ? ? ? ? ? ? ? ? ? ? ? ?Kate Zebrose
> ? ? ? ?Filename ? ? ? ?: draft-ietf-trill-rbridge-mib-05.txt
> ? ? ? ?Pages ? ? ? ? ? : 56
> ? ? ? ?Date ? ? ? ? ? ?: 2012-01-26
>
> ? This memo defines a portion of the Management Information Base (MIB)
> ? for use with network management protocols. ?In particular it defines
> ? objects for managing an RBridge (Routing Bridge), also known as a
> ? TRILL Switch, based on the IETF TRILL (Transparent Interconnection of
> ? Lots of Links) protocol described in RFC 6325.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-05.txt
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge


From internet-drafts at ietf.org  Mon Jan 30 11:52:31 2012
From: internet-drafts at ietf.org (internet-drafts@ietf.org)
Date: Mon, 30 Jan 2012 11:52:31 -0800
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-mib-06.txt
Message-ID: <20120130195231.29627.59442.idtracker@ietfa.amsl.com>


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.

	Title           : Definitions of Managed Objects for RBridges (Routing Bridges)
	Author(s)       : Anil Rijhsinghani
                          Kate Zebrose
	Filename        : draft-ietf-trill-rbridge-mib-06.txt
	Pages           : 56
	Date            : 2012-01-30

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it defines
   objects for managing an RBridge (Routing Bridge), also known as a
   TRILL Switch, based on the IETF TRILL (Transparent Interconnection of
   Lots of Links) protocol.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-06.txt



From mgururam at gmail.com  Tue Jan 31 03:15:11 2012
From: mgururam at gmail.com (gururam m)
Date: Tue, 31 Jan 2012 16:45:11 +0530
Subject: [rbridge] Multiple Nickname support RFC 6325 query..
Message-ID: <CADaSLpUyMBsMP6W8DO-w3MPwNQijQAf410iyUNX26OvoLxv4Pw@mail.gmail.com>

Hi,
   I have question related to ingress nickname usage when multiple
nicknames are supported. As per RFC 6325 "section 3.7.2 Ingress RBridge
Nickname" an RBridge should use the same nickname in the ingress field
whenever it encapsulates a frame with any particular Inner.MacSA and
Inner.VLAN value when multiple nicknames are supported.

Let us say if we have 8 nicknames(n1,n2... n8) supported on a RBridge as
per my understanding of the above statement we could use nickname n1 for
all traffic ingressing from VLAN ID 1 to VLAN ID 512 and n2 for all traffic
ingressing from VLAN ID 513  to VLAN ID 1024 and so on and so forth.

Let me know if there any other draft inprogress or any part of the RFC that
mentions a different approach to set the ingress nickname when
encapsulating traffic on RBridge that supports multiple nicknames.

Regards
Ram
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120131/530bd302/attachment.html

From d3e3e3 at gmail.com  Tue Jan 31 05:37:22 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 31 Jan 2012 08:37:22 -0500
Subject: [rbridge] I-D Action: draft-ietf-trill-rbridge-mib-06.txt
In-Reply-To: <20120130195231.29627.59442.idtracker@ietfa.amsl.com>
References: <20120130195231.29627.59442.idtracker@ietfa.amsl.com>
Message-ID: <CAF4+nEEYJ8bw_NgqXeokFN4AN8UaB5D3x7WY+ZuLkygvmv0ang@mail.gmail.com>

The further very minor changes in this version are part of the
continuing effort resolve IESG comments.

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


On Mon, Jan 30, 2012 at 2:52 PM,  <internet-drafts at ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF.
>
> ? ? ? ?Title ? ? ? ? ? : Definitions of Managed Objects for RBridges (Routing Bridges)
> ? ? ? ?Author(s) ? ? ? : Anil Rijhsinghani
> ? ? ? ? ? ? ? ? ? ? ? ? ?Kate Zebrose
> ? ? ? ?Filename ? ? ? ?: draft-ietf-trill-rbridge-mib-06.txt
> ? ? ? ?Pages ? ? ? ? ? : 56
> ? ? ? ?Date ? ? ? ? ? ?: 2012-01-30
>
> ? This memo defines a portion of the Management Information Base (MIB)
> ? for use with network management protocols. ?In particular it defines
> ? objects for managing an RBridge (Routing Bridge), also known as a
> ? TRILL Switch, based on the IETF TRILL (Transparent Interconnection of
> ? Lots of Links) protocol.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-06.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-trill-rbridge-mib-06.txt


From radiaperlman at gmail.com  Tue Jan 31 08:54:34 2012
From: radiaperlman at gmail.com (Radia Perlman)
Date: Tue, 31 Jan 2012 08:54:34 -0800
Subject: [rbridge] Multiple Nickname support RFC 6325 query..
In-Reply-To: <CADaSLpUyMBsMP6W8DO-w3MPwNQijQAf410iyUNX26OvoLxv4Pw@mail.gmail.com>
References: <CADaSLpUyMBsMP6W8DO-w3MPwNQijQAf410iyUNX26OvoLxv4Pw@mail.gmail.com>
Message-ID: <CAFOuuo65hq=p65K=MZxpTDqu7RbrEkp8=mqCoOcDK3A0yn-p9A@mail.gmail.com>

Why is it useful to use multiple nicknames for ingressing?  Multiple
nicknames are useful for having multiple trees rooted at the same place,
but I can't think of any reason why using different nicknames when
ingressing frames would be useful.

Radia

On Tue, Jan 31, 2012 at 3:15 AM, gururam m <mgururam at gmail.com> wrote:

>
> Hi,
>    I have question related to ingress nickname usage when multiple
> nicknames are supported. As per RFC 6325 "section 3.7.2 Ingress RBridge
> Nickname" an RBridge should use the same nickname in the ingress field
> whenever it encapsulates a frame with any particular Inner.MacSA and
> Inner.VLAN value when multiple nicknames are supported.
>
> Let us say if we have 8 nicknames(n1,n2... n8) supported on a RBridge as
> per my understanding of the above statement we could use nickname n1 for
> all traffic ingressing from VLAN ID 1 to VLAN ID 512 and n2 for all traffic
> ingressing from VLAN ID 513  to VLAN ID 1024 and so on and so forth.
>
> Let me know if there any other draft inprogress or any part of the RFC
> that mentions a different approach to set the ingress nickname when
> encapsulating traffic on RBridge that supports multiple nicknames.
>
> Regards
> Ram
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20120131/c7c149c5/attachment.html