From Radia.Perlman at sun.com  Sat Aug  1 14:55:04 2009
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sat, 01 Aug 2009 14:55:04 -0700
Subject: [rbridge] ESADI question
In-Reply-To: <1028365c0907312128p3fed5777i5afdb7d9bdba99be@mail.gmail.com>
References: <ADF757329B387846A8189F0BACC766EE0F19F0A11A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN>
	<1028365c0907312128p3fed5777i5afdb7d9bdba99be@mail.gmail.com>
Message-ID: <4A74B9B8.4020406@sun.com>

I don't completely understand the question either, but let me make a 
stab at it.

First, a clarification -- it's not the DRB that advertises ESADI  for 
VLAN x, it is the Designated Forwarder for
VLAN x.
Keeping in mind that ESADI is optional, and if implemented, may contain 
any subset of the attached "endnodes",
it would be legal for R1, if it is Designated Forwarder for VLAN x on 
one or more links, to advertise
MAC addresses of any attached VLAN x nodes, including neighbor RBridges. 
It wouldn't cause
any confusion.

The "system ID" of neighbor RBridge R2 is advertised in TRILL IS-IS, but 
R2's system ID is not
necessarily the same as R2's MAC address, especially since R2 might have 
different MAC addresses
on each of its links.

I could imagine some failure scenarios in which R2 might not be 
reachable through its system ID, and
it might be useful to be able to reach a specific one of R2's ports 
through R1, which has
advertised that particular MAC address through ESADI.

Radia




Donald Eastlake wrote:
> Hi,
>
> I don't quite understand your question. Are you talking about IS-IS
> DRBs or EASDI virtual link DRBs? In any case, what difference does
> being a DRB or non-DRB make? The EASDI LSPs distribute end stations
> MAC addresses, not RBridge MAC addresses.
>
> Thanks,
> Donald
>
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
>
> On Thu, Jul 30, 2009 at 3:15 AM, Balaji Swaminathan<balajis at hcl.in> wrote:
>   
>> Hi,
>>
>>      The ESADI information is carried in Level1 LSPs as a separate TLV. Will
>> the ESADI information contain the MAC addresses of the non DRBs also OR is
>> it not needed since the non-DRB information is exchanged using the other
>> TLVs of the LSP?
>>
>> Thanks,
>> Balaji.
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   


From d3e3e3 at gmail.com  Sun Aug  2 21:26:01 2009
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 3 Aug 2009 00:26:01 -0400
Subject: [rbridge] Addition to item 5 in Section 4.2.4.4
Message-ID: <1028365c0908022126j1be5bc99m7e0538365e709299@mail.gmail.com>

I suggest we add "RBridges MAY associate advertised connectivity to
different groups of VLANs with specific nicknames they hold." to Item
5 of Section 4.2.4.4. Although draft-ietf-isis-layer2-01.txt is still
being expanded and edited, this is currently provided for in Section
2.4.6 of that draft.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

From jeffpick at broadcom.com  Mon Aug  3 04:46:52 2009
From: jeffpick at broadcom.com (Jeff Pickering)
Date: Mon, 3 Aug 2009 04:46:52 -0700
Subject: [rbridge] nickname-less RBs?
Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F961EB@SJEXCHCCR02.corp.ad.broadcom.com>


The following text has been removed from section 3.7.3 of the latest spec:


   An RBridge that will not act as an ingress, egress, or tree root need
   not have a nickname.

Does this mean nicknames are now reqiured? If so, it should be explicitly stated. Personally, I really

liked the option to not give an RB a nickname if not needed to cut down on routing table size. In the fat tree case,

this amount to around a 60% savings.



Jeff


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

From d3e3e3 at gmail.com  Mon Aug  3 06:35:23 2009
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Mon, 3 Aug 2009 09:35:23 -0400
Subject: [rbridge] nickname-less RBs?
In-Reply-To: <9793EC0A42D76D4EB2A8F94D77E2138893C4F961EB@SJEXCHCCR02.corp.ad.broadcom.com>
References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F961EB@SJEXCHCCR02.corp.ad.broadcom.com>
Message-ID: <1028365c0908030635v7d82dec4qb6973c199a343743@mail.gmail.com>

How would you send a management message to an RBridge without a
nickname, even assuming you are using SNMP over Ethernet? Would you
require an adjacent RBridge to have a nickname? Would you have some
way to address a frame to a System ID? This seems to rapidly get
pretty messy.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

On Mon, Aug 3, 2009 at 7:46 AM, Jeff Pickering<jeffpick at broadcom.com> wrote:
>
> The following text has been removed from section 3.7.3 of the latest spec:
>
>
> ?? An RBridge that will not act as an ingress, egress, or tree root need
> ?? not have a nickname.
>
> Does this mean nicknames are now reqiured? If so, it should be explicitly
> stated. Personally, I really
>
> liked the option to not give an RB a nickname if not needed to cut down on
> routing table size. In the fat tree case,
>
> this amount to around a 60% savings.
>
>
>
> Jeff
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>


From Radia.Perlman at sun.com  Mon Aug  3 08:38:50 2009
From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 03 Aug 2009 08:38:50 -0700
Subject: [rbridge] nickname-less RBs?
In-Reply-To: <1028365c0908030635v7d82dec4qb6973c199a343743@mail.gmail.com>
References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F961EB@SJEXCHCCR02.corp.ad.broadcom.com>
	<1028365c0908030635v7d82dec4qb6973c199a343743@mail.gmail.com>
Message-ID: <4A77048A.7030804@sun.com>

Right. That was why we removed it, because we couldn't figure out how to
send a management message to a nickname-less RBridge.

Jeff-- when you say "60% savings", do you mean 60% fewer nicknames used?
Are we worried about running out of nicknames?

The only way I can think of perhaps talking to a nickname-less RBridge would
be sending a message to its MAC address as a multicast, and then having
nickname-less RBridges look inside all multicast packets to check if the 
(inner) MAC
address is theirs.

Radia


Donald Eastlake wrote:
> How would you send a management message to an RBridge without a
> nickname, even assuming you are using SNMP over Ethernet? Would you
> require an adjacent RBridge to have a nickname? Would you have some
> way to address a frame to a System ID? This seems to rapidly get
> pretty messy.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
> On Mon, Aug 3, 2009 at 7:46 AM, Jeff Pickering<jeffpick at broadcom.com> wrote:
>   
>> The following text has been removed from section 3.7.3 of the latest spec:
>>
>>
>>    An RBridge that will not act as an ingress, egress, or tree root need
>>    not have a nickname.
>>
>> Does this mean nicknames are now reqiured? If so, it should be explicitly
>> stated. Personally, I really
>>
>> liked the option to not give an RB a nickname if not needed to cut down on
>> routing table size. In the fat tree case,
>>
>> this amount to around a 60% savings.
>>
>>
>>
>> Jeff
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   


From jeffpick at broadcom.com  Mon Aug  3 12:33:05 2009
From: jeffpick at broadcom.com (Jeff Pickering)
Date: Mon, 3 Aug 2009 12:33:05 -0700
Subject: [rbridge] nickname-less RBs?
In-Reply-To: <4A77048A.7030804@sun.com>
References: <9793EC0A42D76D4EB2A8F94D77E2138893C4F961EB@SJEXCHCCR02.corp.ad.broadcom.com>
	<1028365c0908030635v7d82dec4qb6973c199a343743@mail.gmail.com>
	<4A77048A.7030804@sun.com>
Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F9625A@SJEXCHCCR02.corp.ad.broadcom.com>


I am worried about running out of hw fdb space. But your point is well taken.
By definition the is an "end station", the rb itself attached to every device.

Jeff
 

-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
Sent: Monday, August 03, 2009 11:39 AM
To: Donald Eastlake
Cc: Jeff Pickering; rbridge at postel.org
Subject: Re: [rbridge] nickname-less RBs?

Right. That was why we removed it, because we couldn't figure out how to
send a management message to a nickname-less RBridge.

Jeff-- when you say "60% savings", do you mean 60% fewer nicknames used?
Are we worried about running out of nicknames?

The only way I can think of perhaps talking to a nickname-less RBridge would
be sending a message to its MAC address as a multicast, and then having
nickname-less RBridges look inside all multicast packets to check if the 
(inner) MAC
address is theirs.

Radia


Donald Eastlake wrote:
> How would you send a management message to an RBridge without a
> nickname, even assuming you are using SNMP over Ethernet? Would you
> require an adjacent RBridge to have a nickname? Would you have some
> way to address a frame to a System ID? This seems to rapidly get
> pretty messy.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
> On Mon, Aug 3, 2009 at 7:46 AM, Jeff Pickering<jeffpick at broadcom.com> wrote:
>   
>> The following text has been removed from section 3.7.3 of the latest spec:
>>
>>
>>    An RBridge that will not act as an ingress, egress, or tree root need
>>    not have a nickname.
>>
>> Does this mean nicknames are now reqiured? If so, it should be explicitly
>> stated. Personally, I really
>>
>> liked the option to not give an RB a nickname if not needed to cut down on
>> routing table size. In the fat tree case,
>>
>> this amount to around a 60% savings.
>>
>>
>>
>> Jeff
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   





From balajis at hcl.in  Tue Aug  4 05:47:29 2009
From: balajis at hcl.in (Balaji Swaminathan)
Date: Tue, 4 Aug 2009 18:17:29 +0530
Subject: [rbridge] ESADI question
In-Reply-To: <4A74B9B8.4020406@sun.com>
References: <ADF757329B387846A8189F0BACC766EE0F19F0A11A@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN>
	<1028365c0907312128p3fed5777i5afdb7d9bdba99be@mail.gmail.com>
	<4A74B9B8.4020406@sun.com>
Message-ID: <ADF757329B387846A8189F0BACC766EE0F19F717EC@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN>

Thanks Radia, for your explanation. It answered my question.

Thanks,
Balaji.


-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com]
Sent: Sunday, August 02, 2009 3:25 AM
To: Donald Eastlake
Cc: Balaji Swaminathan; rbridge at postel.org
Subject: Re: [rbridge] ESADI question

I don't completely understand the question either, but let me make a
stab at it.

First, a clarification -- it's not the DRB that advertises ESADI  for
VLAN x, it is the Designated Forwarder for
VLAN x.
Keeping in mind that ESADI is optional, and if implemented, may contain
any subset of the attached "endnodes",
it would be legal for R1, if it is Designated Forwarder for VLAN x on
one or more links, to advertise
MAC addresses of any attached VLAN x nodes, including neighbor RBridges.
It wouldn't cause
any confusion.

The "system ID" of neighbor RBridge R2 is advertised in TRILL IS-IS, but
R2's system ID is not
necessarily the same as R2's MAC address, especially since R2 might have
different MAC addresses
on each of its links.

I could imagine some failure scenarios in which R2 might not be
reachable through its system ID, and
it might be useful to be able to reach a specific one of R2's ports
through R1, which has
advertised that particular MAC address through ESADI.

Radia




Donald Eastlake wrote:
> Hi,
>
> I don't quite understand your question. Are you talking about IS-IS
> DRBs or EASDI virtual link DRBs? In any case, what difference does
> being a DRB or non-DRB make? The EASDI LSPs distribute end stations
> MAC addresses, not RBridge MAC addresses.
>
> Thanks,
> Donald
>
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
>
> On Thu, Jul 30, 2009 at 3:15 AM, Balaji Swaminathan<balajis at hcl.in> wrote:
>
>> Hi,
>>
>>      The ESADI information is carried in Level1 LSPs as a separate TLV. Will
>> the ESADI information contain the MAC addresses of the non DRBs also OR is
>> it not needed since the non-DRB information is exchanged using the other
>> TLVs of the LSP?
>>
>> Thanks,
>> Balaji.
>>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>


DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. 
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

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


From vijayc at hcl.in  Tue Aug  4 05:51:40 2009
From: vijayc at hcl.in (Vijayanand C)
Date: Tue, 4 Aug 2009 18:21:40 +0530
Subject: [rbridge] separate ISIS instance for ESADI
In-Reply-To: <4A730DF7.4050809@cisco.com>
Message-ID: <66E3DDEEA70F0D469D1FFE238526B6ED0E5BB4CCD4@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN>

A lot of things are not explicit in the drafts.
Is it correct to interpret that MAC-RI TLV  carried inside a level-1 LSP (as stated in draft-isis-layer2)contains the ESADI information.

Regards
Vijay

> -----Original Message-----
> From: Dinesh G Dutt [mailto:ddutt at cisco.com]
> Sent: Friday, July 31, 2009 9:00 PM
> To: Vijayanand C
> Cc: rbridge at postel.org; Balaji Swaminathan
> Subject: Re: [rbridge] separate ISIS instance for ESADI
>
> ESADI is not IS-IS. It uses the encodings of IS-IS, that's all,
>
> Dinesh
> Vijayanand C wrote:
> > The draft-ietf-trill-rbridge-protocol states that Rbrdiges can
> participate in ESADI, but the means to do it  for ISIS is not explicit in
> draft-isis-layer2. Specifically it is not clear whether the MAC-RI TLV
> constituting MAC reachability information should be sent in the regular
> Rbridge Level1 LSP as stated in the drat-isis-layer2 or ESADI frames
> should be part of a separate ISIS instance run specifically for that
> purpose as stated in draft-eastlake-trill-rbridge-isis,
> >
> > Regards
> > Vijay
> >
> >
> > DISCLAIMER:
> > ------------------------------------------------------------------------
> -----------------------------------------------
> >
> > The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
> > It shall not attach any liability on the originator or HCL or its
> affiliates. Any views or opinions presented in
> > this email are solely those of the author and may not necessarily
> reflect the opinions of HCL or its affiliates.
> > Any form of reproduction, dissemination, copying, disclosure,
> modification, distribution and / or publication of
> > this message without the prior written consent of the author of this e-
> mail is strictly prohibited. If you have
> > received this email in error please delete it and notify the sender
> immediately. Before opening any mail and
> > attachments please check them for viruses and defect.
> >
> > ------------------------------------------------------------------------
> -----------------------------------------------
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
>
> --
> We make our world significant by the courage of our questions and by
> the depth of our answers.                               - Carl Sagan




From jeffpick at broadcom.com  Tue Aug  4 07:12:50 2009
From: jeffpick at broadcom.com (Jeff Pickering)
Date: Tue, 4 Aug 2009 07:12:50 -0700
Subject: [rbridge] rbridge Digest, Vol 63, Issue 3
In-Reply-To: <mailman.3.1249326001.25338.rbridge@postel.org>
References: <mailman.3.1249326001.25338.rbridge@postel.org>
Message-ID: <9793EC0A42D76D4EB2A8F94D77E2138893C4F96320@SJEXCHCCR02.corp.ad.broadcom.com>


Donald,

Sounds like the intented use is for management (given the thread inclusion). Can
You expand on this for my edification?

Jeff

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of rbridge-request at postel.org
Sent: Monday, August 03, 2009 3:00 PM
To: rbridge at postel.org
Subject: rbridge Digest, Vol 63, Issue 3

Send rbridge mailing list submissions to
	rbridge at postel.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.postel.org/mailman/listinfo/rbridge
or, via email, send a message with subject or body 'help' to
	rbridge-request at postel.org

You can reach the person managing the list at
	rbridge-owner at postel.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of rbridge digest..."


Today's Topics:

   1. Addition to item 5 in Section 4.2.4.4 (Donald Eastlake)
   2. nickname-less RBs? (Jeff Pickering)
   3. Re: nickname-less RBs? (Donald Eastlake)
   4. Re: nickname-less RBs? (Radia Perlman)


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

Message: 1
Date: Mon, 3 Aug 2009 00:26:01 -0400
From: Donald Eastlake <d3e3e3 at gmail.com>
Subject: [rbridge] Addition to item 5 in Section 4.2.4.4
To: rbridge at postel.org
Message-ID:
	<1028365c0908022126j1be5bc99m7e0538365e709299 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

I suggest we add "RBridges MAY associate advertised connectivity to
different groups of VLANs with specific nicknames they hold." to Item
5 of Section 4.2.4.4. Although draft-ietf-isis-layer2-01.txt is still
being expanded and edited, this is currently provided for in Section
2.4.6 of that draft.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com


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

Message: 2
Date: Mon, 3 Aug 2009 04:46:52 -0700
From: "Jeff Pickering" <jeffpick at broadcom.com>
Subject: [rbridge] nickname-less RBs?
To: "rbridge at postel.org" <rbridge at postel.org>
Message-ID:
	<9793EC0A42D76D4EB2A8F94D77E2138893C4F961EB at SJEXCHCCR02.corp.ad.broadcom.com>
	
Content-Type: text/plain; charset="us-ascii"


The following text has been removed from section 3.7.3 of the latest spec:


   An RBridge that will not act as an ingress, egress, or tree root need
   not have a nickname.

Does this mean nicknames are now reqiured? If so, it should be explicitly stated. Personally, I really

liked the option to not give an RB a nickname if not needed to cut down on routing table size. In the fat tree case,

this amount to around a 60% savings.



Jeff


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090803/227fb526/attachment-0001.html

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

Message: 3
Date: Mon, 3 Aug 2009 09:35:23 -0400
From: Donald Eastlake <d3e3e3 at gmail.com>
Subject: Re: [rbridge] nickname-less RBs?
To: Jeff Pickering <jeffpick at broadcom.com>
Cc: "rbridge at postel.org" <rbridge at postel.org>
Message-ID:
	<1028365c0908030635v7d82dec4qb6973c199a343743 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

How would you send a management message to an RBridge without a
nickname, even assuming you are using SNMP over Ethernet? Would you
require an adjacent RBridge to have a nickname? Would you have some
way to address a frame to a System ID? This seems to rapidly get
pretty messy.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com

On Mon, Aug 3, 2009 at 7:46 AM, Jeff Pickering<jeffpick at broadcom.com> wrote:
>
> The following text has been removed from section 3.7.3 of the latest spec:
>
>
> ?? An RBridge that will not act as an ingress, egress, or tree root need
> ?? not have a nickname.
>
> Does this mean nicknames are now reqiured? If so, it should be explicitly
> stated. Personally, I really
>
> liked the option to not give an RB a nickname if not needed to cut down on
> routing table size. In the fat tree case,
>
> this amount to around a 60% savings.
>
>
>
> Jeff
>
>
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>
>



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

Message: 4
Date: Mon, 03 Aug 2009 08:38:50 -0700
From: Radia Perlman <Radia.Perlman at sun.com>
Subject: Re: [rbridge] nickname-less RBs?
To: Donald Eastlake <d3e3e3 at gmail.com>
Cc: "rbridge at postel.org" <rbridge at postel.org>,	Jeff Pickering
	<jeffpick at broadcom.com>
Message-ID: <4A77048A.7030804 at sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Right. That was why we removed it, because we couldn't figure out how to
send a management message to a nickname-less RBridge.

Jeff-- when you say "60% savings", do you mean 60% fewer nicknames used?
Are we worried about running out of nicknames?

The only way I can think of perhaps talking to a nickname-less RBridge would
be sending a message to its MAC address as a multicast, and then having
nickname-less RBridges look inside all multicast packets to check if the 
(inner) MAC
address is theirs.

Radia


Donald Eastlake wrote:
> How would you send a management message to an RBridge without a
> nickname, even assuming you are using SNMP over Ethernet? Would you
> require an adjacent RBridge to have a nickname? Would you have some
> way to address a frame to a System ID? This seems to rapidly get
> pretty messy.
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-634-2066 (home)
>  155 Beaver Street
>  Milford, MA 01757 USA
>  d3e3e3 at gmail.com
>
> On Mon, Aug 3, 2009 at 7:46 AM, Jeff Pickering<jeffpick at broadcom.com> wrote:
>   
>> The following text has been removed from section 3.7.3 of the latest spec:
>>
>>
>>    An RBridge that will not act as an ingress, egress, or tree root need
>>    not have a nickname.
>>
>> Does this mean nicknames are now reqiured? If so, it should be explicitly
>> stated. Personally, I really
>>
>> liked the option to not give an RB a nickname if not needed to cut down on
>> routing table size. In the fat tree case,
>>
>> this amount to around a 60% savings.
>>
>>
>>
>> Jeff
>>
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> rbridge at postel.org
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   



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

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


End of rbridge Digest, Vol 63, Issue 3
**************************************




From d3e3e3 at gmail.com  Tue Aug  4 14:51:27 2009
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Tue, 4 Aug 2009 17:51:27 -0400
Subject: [rbridge] Addition to item 5 in Section 4.2.4.4
In-Reply-To: <1028365c0908031023u561198d8j48fb4f620424b92@mail.gmail.com>
References: <1028365c0908022126j1be5bc99m7e0538365e709299@mail.gmail.com>
	<4A770283.70708@sun.com>
	<1028365c0908031023u561198d8j48fb4f620424b92@mail.gmail.com>
Message-ID: <1028365c0908041451hfa80ed6q67d5cf7eb694761b@mail.gmail.com>

Hi Jeff,

I think any "thread inclusion" was accidental. This was a new message.

Not sure of all the reasons for this but it would increase the
variance in the nickname for frames being sent to the same RBridge
which might make more variable hashing for multi-path easier.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com


On Tue, Aug 4, 2009 at 10:12 AM, Jeff Pickering<jeffpick at broadcom.com> wrote:
>
> Donald,
>
> Sounds like the intented use is for management (given the thread inclusion). Can
> You expand on this for my edification?
>
> Jeff
>
> Date: Mon, 3 Aug 2009 00:26:01 -0400
> From: Donald Eastlake <d3e3e3 at gmail.com>
> Subject: [rbridge] Addition to item 5 in Section 4.2.4.4
> To: rbridge at postel.org
> Message-ID:
> ? ? ? ?<1028365c0908022126j1be5bc99m7e0538365e709299 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I suggest we add "RBridges MAY associate advertised connectivity to
> different groups of VLANs with specific nicknames they hold." to Item
> 5 of Section 4.2.4.4. Although draft-ietf-isis-layer2-01.txt is still
> being expanded and edited, this is currently provided for in Section
> 2.4.6 of that draft.
>
> Thanks,
> Donald
> =============================
> ?Donald E. Eastlake 3rd ? +1-508-634-2066 (home)
> ?155 Beaver Street
> ?Milford, MA 01757 USA
> ?d3e3e3 at gmail.com


From trillmails at gmail.com  Thu Aug 27 17:08:24 2009
From: trillmails at gmail.com (Selvaraj Rajan)
Date: Thu, 27 Aug 2009 17:08:24 -0700
Subject: [rbridge] need some info on TRILL
Message-ID: <e255b8c20908271708s69233223y5debe489680a15d0@mail.gmail.com>

Hi,
I had some time browsing through few mails in the rbridge mail archive for
follwoing info.
But as I run out of patience I am sending this mail to this group. So excuse
me incase if
this is a duplicate question.

1) What all TRILL protocol needs from IS-IS RFC1195/ISO 10589?


    - Adjacency formation: Is this same as IS-IS but for TRILL by sending
TRILL Hellos ?
    - DR election: Is this same as IS-IS.
    - LSP generation: LSP aging, numbering all are same but for TRILL by
generating TRILL LSPs.

   Essentially is that all are same except the LSP and Hello PDU information
?
  CSNP and PSNPs still remains same for both ?

     It would be better to have one single document for TRILL where in the
sections from ISO 10589 or RFC 1195 shall be cross refered.
     In case the document is already availabe please send me the pointer.

2) Is their any MIB document available for TRILL protocol ?


Thanks,
Selva.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20090827/819b3f43/attachment.html

From d3e3e3 at gmail.com  Thu Aug 27 19:46:48 2009
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Thu, 27 Aug 2009 22:46:48 -0400
Subject: [rbridge] need some info on TRILL
In-Reply-To: <e255b8c20908271708s69233223y5debe489680a15d0@mail.gmail.com>
References: <e255b8c20908271708s69233223y5debe489680a15d0@mail.gmail.com>
Message-ID: <1028365c0908271946o2a92d889n573b0baa35757946@mail.gmail.com>

Hi Selvaraj,

See below:

On Thu, Aug 27, 2009 at 8:08 PM, Selvaraj Rajan<trillmails at gmail.com> wrote:
> Hi,
> I had some time browsing through few mails in the rbridge mail archive for
> follwoing info.
> But as I run out of patience I am sending this mail to this group. So excuse
> me incase if
> this is a duplicate question.

I'll try to answer your questions but you really should read the
current base protocol specification at
http://www.ietf.org/id/draft-ietf-trill-rbridge-protocol-13.txt
I think that would be a better way to lear about TRILL than just
reading recent emails.

> 1) What all TRILL protocol needs from IS-IS RFC1195/ISO 10589?

See sections 4.2, 4.3, and 4.4 of the base protocol spec.

> ??? - Adjacency formation: Is this same as IS-IS but for TRILL by sending
> TRILL Hellos ?

More or less yes.

> ??? - DR election: Is this same as IS-IS.

No, election of DR/DIS/DRB is a little different. In particular, layer
3 routers ignore other systems for the DRB election unless they have
two way connectivity. TRILL does not ignore such other systems. See
Section 4.4.1 of the base protocol spec.

> ??? - LSP generation: LSP aging, numbering all are same but for TRILL by
> generating TRILL LSPs.
> ?? Essentially is that all are same except the LSP and Hello PDU information
> ?
> ? CSNP and PSNPs still remains same for both ?

More or less yes but there are at least additional information items
in the LSPs.

> ???? It would be better to have one single document for TRILL where in the
> sections from ISO 10589 or RFC 1195 shall be cross refered.
> ???? In case the document is already availabe please send me the pointer.

Just references to ISO 10589 would be inadequate. TRILL also uses many
extensions to IS-IS made in various RFCs. See also the following
draft, although it needs changes and additions:
http://tools.ietf.org/id/draft-ietf-isis-layer2-01.txt

> 2) Is their any MIB document available for TRILL protocol ?

Not yet.

> Thanks,
> Selva.

Thanks,
Donald


From dromasca at avaya.com  Sun Aug 30 05:41:37 2009
From: dromasca at avaya.com (Romascanu, Dan (Dan))
Date: Sun, 30 Aug 2009 14:41:37 +0200
Subject: [rbridge] Review of draft-ietf-trill-rbridge-protocol-13.txt
Message-ID: <EDC652A26FB23C4EB6384A4584434A0401984C29@307622ANEX5.global.avaya.com>

I was asked by the TRILL WG chairs to perform a review of
draft-ietf-trill-rbridge-protocol-13.txt. Below please find my findings.


I appreciate the work put by the editors and WG in designing this
solution and writing the document. The editors are to be saluted for
writing an I-D which is in most parts clear and well organized. 

I do believe that this work and the document as it stands still have a
number of problems that need to be solved.

1. I have serious reservations that this document can directly go to
Proposed Standard. For reasons detailed below there is a lot of
incertitude in what concerns the interoperability or coexistence with
the layer 2 protocols designed in the IEEE. Many of these are still work
in progress. For this good reason in many places the document is forced
to make assumptions and cannot make but statements like 'Rbridges are
generally compatible with IEEE ...' (section 2.4.2). Has the WG
discussed the option of issuing the first version of this document as
Experimental? 

2. It looks to me like the motivation of the standard is frozen in time
into a period of evolution of the IEEE 802.1 technology trying to solve
some problems that were in part dealt with by the IEEE in the meantime.
Out of the four spanning tree bullets listed in the introduction as
problems that TRILL solves the second and the fourth seem to have been
dealt with by the IEEE 802.1aq and the IEEE 802.1ak respectively. 

3. All the VLAN discussions in the specification mention only the
C-VLANs. What about provider bridges? Can these be migrated to Rbridges?
The explanation in Appendix E is not sufficient, the compatibility with
provider bridges needs to be dealt in the core part of the I-D. 

4. There needs to be more discussion about the IEEE protocols that do
not define forwarding or tagging. If TRILL makes a claim that the nest
migration policy is to replace IEEE bridges by Rbridges it needs to
define behavior relative to protocols like IEEE 802.1AE Media Access
Control (MAC) Security, IEEE 802.1AB Station and Media Access Control
Connectivity Discovery, and IEEE 802.1aj Two Port Media Relay, as
bridges and end stations that are being replaced may support any or a
combination of these. 

5. For all the reasons above I think it is required that this document
is also reviewed in detail by IEEE 802.1. I suggest that a formal review
be required via a liaison letter before or during IETF Last Call. 

6. It would be good to add a section that provides some estimates about
the operational impact of the deployment of TRILL. For example a claim
is made that TRILL will allow internal forwarding tables to be
substantially smaller than in conventional bridges (Abstract). How much
smaller? Is there an estimation of the level of extra traffic created by
TRILL? Any recommendations on tuning to make it more efficient? 

7. The claim made in the introduction section about TRILL avoiding the
problem of the 'significant configuration' required by the IP routers is
not substantiated but what follows. My reading of section 4.8.1 is that
although management configuration of ports and VLAN parameters is not
mandatory, it is highly recommended, and in its absence the protocol
cannot be expected to perform efficiently. 

8. Speaking about configuration parameters I could not locate the place
where the default interval between TRILL hello messages is defined and
how it can be changed. Maybe I missed it, if not please add this. 

9. In section 2, page 13, there is a recommendation to support SNMPv3
over IP. I think this actually should be mapping of SNMPv3 over UDP over
IPv4 (RFC 3417) and mapping of SNMP over UDP over IPv6 (RFC 3419)

10. I find confusing the claim in section 2.4.2 
   'If the bridges replaced by
   RBridges were zero configuration bridges, then their RBridge
   replacements will not require configuration."

I do not know what 'zero configuration' bridges are. I do not see an
Rbridge behaving better than a IEEE 802 bridge without configuration.
See also my comment #7. 

11. In section 4.1.1 

"  As specified in [802.1Q-2005], the priority field contains an
   unsigned value from 0 through 7 where 1 indicates the lowest
   priority, 7 the highest priority, and the default priority zero is
   considered to be higher than priority 1 but lower than priority 2."

This does not seem accurate, see Annex G in IEEE 802.1D-2005

12. Section 4.3.1 - it would be good to justify where the figure 1470
comes from. Also note that an end-station would not support such an MTU
unless it supports IEEE 802.3as, so it would be good to explain how
problems are avoided when an Rbridge replaces an IEEE 802.1 bridge that
connects to end-stations. 

13. I am confused about the need for section 5. The first part that
talks about assignment of multicast addresses seems redundant with
content in the IANA/IEEE considerations section. The second part tries
to list parameters that are configurable per Rbridge and per port? Than
many of the parameters listed in 4.8 and 4.9 are missing. 

14. Section 7.1 - I do not think that there is a need for registries of
the version numbers or Header reserved bits - these would be defined in
later versions of the protocol. For the TRILL Nicknames registry, the
appropriate RFC 5226 policy term is 'RFC Required' rather than 'RFC
Publication'.

15. Normative References - [802.3] has a 2008 edition

16. Annex E will certainly evolve in time until publication, as the IEEE
802.1 documents are also in evolution. At this point in time I would
suggest to add IEEE 802.1AB, IEEE 802.1AE and IEEE 802.1aj. Also IEEE
802.1aq, IEEE 802.1Qaw and IEEE 802.1Qay have been approved in the
meantime. 

I hope this helps. 

Regards,

Dan