Subject: [rbridge] Multiple instance/hierarchical RBridge topologies

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 22 Dec 2006 22:35:44 -0800

After talking to a bunch of people, I think I understand a feature, and 
here are thoughts on how
to implement it.

The two problems we might solve:

a) ensure that two different RBridged clouds don't accidentally merge

b) allow a hierarchy of RBridged clouds (yes, similar to L2VPN or 
provider backbone bridges)

In the case of b) it would be useful to encapsulate data packets with a 
customer ID, whereas such
a field would not be necessary for a customer campus/CRED/RBridged-cloud.

IS-IS already has a field "area address" that can be configured to keep 
two IS-IS instances separate.
So, for instance,
the default can be area=0, but if there are two different RBridged 
clouds that are intended to be kept
separate, but they are physically close enough that someone is afraid 
they might accidentally merge, then
you can configure the area address in all of the RBridges
in at least one of the clouds to prevent two alien RBridges from talking to
each other.

For hierarchy, we could do the same thing (configure the higher layer 
RBridge cloud to have an
area address something other than 0). That way customer RBridged nets 
would not accidentally merge
with the core instance. But as I'll explain, I think the backbone 
RBridges would need to be slightly
different from the lower-level RBridges.

There are two "community" things that we want to keep separate, and 
let's call them "customers" and
"VLANs within customer". RBridges as currently specified keep VLANs 
separated. However, if
we have a higher level of RBridges connecting customers, each of whom 
are using VLANs, the
core RBridges need to keep separate communities of (customer, VLAN) pairs.

So let's think of a "community" as having a hierarchically assigned 
"community" name, which would be
"customer ID" concatenated with VLAN tag, or (customer, VLAN). The rule 
is that two endnodes can only
talk to each other if they are in the same tuple (customer, VLAN).

This really results in all the same algorithms as RBridges already do in 
terms of filtering so that multicasts
within a VLAN stay within a VLAN, except that it's a bigger field: it's 
(customer, VLAN) now.

Therefore, the difference between case a) and b) above is that RBridges 
also have to know
how many components are in the community tag. In a) RBridges assume the 
community is
specified by the VLAN tag in the inner packet. In b), we need for 
RBridges in the backbone to
add another field to specify another level of hierarchy in the tag. In 
an earlier note, we were suggesting
using a VLAN tag in the outer header. But perhaps it would be more 
cleanly expressed as another
field in the shim header used by the backbone RBridges.

So, here is a suggestion:

Make the "area address" in IS-IS have two parts: (level of hierarchy | 
name).
The default is level=0, and name=0.
Backbone RBridges would use level=1, and name could be anything, but all 
RBridges in the
same cloud all have
to be configured with the same name (0 would work).

RBridges at level 1 will encapsulate data packets with an extra field 
(say 16-bits),
that separates communities. So at level 1, we'd add to the shim a 16-bit 
field, that we could think
of as "customer ID". So if the shim header is 6 bytes at level 0, it 
would be 8 bytes at level 1, since
it would also have the extra "customer" field.

I don't think we'd ever need more than 2 levels, but we might want to 
think about that -- I'd guess
we'd assume 2 "customer ID" fields in the shim at level 2.

At level 1, in the per-VLAN instance which passes around endnode 
information and IP multicast membership,
the only difference would be like having a VLAN tag which is 28 bits (12 
plus 16), and in theory, one
could have 2^28 instances of IS-IS passing around endnode information 
across the backbone.

Comments? I hope I'm being reasonably clear.

Radia

Date: Fri, 22 Dec 2006 22:35:44 -0800
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Multiple instance/hierarchical RBridge topologies
Status: RO
Content-Length: 3848

After talking to a bunch of people, I think I understand a feature, and 
here are thoughts on how
to implement it.

The two problems we might solve:

a) ensure that two different RBridged clouds don't accidentally merge

b) allow a hierarchy of RBridged clouds (yes, similar to L2VPN or 
provider backbone bridges)

In the case of b) it would be useful to encapsulate data packets with a 
customer ID, whereas such
a field would not be necessary for a customer campus/CRED/RBridged-cloud.

IS-IS already has a field "area address" that can be configured to keep 
two IS-IS instances separate.
So, for instance,
the default can be area=0, but if there are two different RBridged 
clouds that are intended to be kept
separate, but they are physically close enough that someone is afraid 
they might accidentally merge, then
you can configure the area address in all of the RBridges
in at least one of the clouds to prevent two alien RBridges from talking to
each other.

For hierarchy, we could do the same thing (configure the higher layer 
RBridge cloud to have an
area address something other than 0). That way customer RBridged nets 
would not accidentally merge
with the core instance. But as I'll explain, I think the backbone 
RBridges would need to be slightly
different from the lower-level RBridges.

There are two "community" things that we want to keep separate, and 
let's call them "customers" and
"VLANs within customer". RBridges as currently specified keep VLANs 
separated. However, if
we have a higher level of RBridges connecting customers, each of whom 
are using VLANs, the
core RBridges need to keep separate communities of (customer, VLAN) pairs.

So let's think of a "community" as having a hierarchically assigned 
"community" name, which would be
"customer ID" concatenated with VLAN tag, or (customer, VLAN). The rule 
is that two endnodes can only
talk to each other if they are in the same tuple (customer, VLAN).

This really results in all the same algorithms as RBridges already do in 
terms of filtering so that multicasts
within a VLAN stay within a VLAN, except that it's a bigger field: it's 
(customer, VLAN) now.

Therefore, the difference between case a) and b) above is that RBridges 
also have to know
how many components are in the community tag. In a) RBridges assume the 
community is
specified by the VLAN tag in the inner packet. In b), we need for 
RBridges in the backbone to
add another field to specify another level of hierarchy in the tag. In 
an earlier note, we were suggesting
using a VLAN tag in the outer header. But perhaps it would be more 
cleanly expressed as another
field in the shim header used by the backbone RBridges.

So, here is a suggestion:

Make the "area address" in IS-IS have two parts: (level of hierarchy | 
name).
The default is level=0, and name=0.
Backbone RBridges would use level=1, and name could be anything, but all 
RBridges in the
same cloud all have
to be configured with the same name (0 would work).

RBridges at level 1 will encapsulate data packets with an extra field 
(say 16-bits),
that separates communities. So at level 1, we'd add to the shim a 16-bit 
field, that we could think
of as "customer ID". So if the shim header is 6 bytes at level 0, it 
would be 8 bytes at level 1, since
it would also have the extra "customer" field.

I don't think we'd ever need more than 2 levels, but we might want to 
think about that -- I'd guess
we'd assume 2 "customer ID" fields in the shim at level 2.

At level 1, in the per-VLAN instance which passes around endnode 
information and IP multicast membership,
the only difference would be like having a VLAN tag which is 28 bits (12 
plus 16), and in theory, one
could have 2^28 instances of IS-IS passing around endnode information 
across the backbone.

Comments? I hope I'm being reasonably clear.

Radia

Content-class: urn:content-classes:message
Date: Thu, 21 Dec 2006 23:41:15 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Draft-trill-rbridge-protocol-01.txt
Status: RO
Content-Length: 1478

Hi,

I just noticed that no message from the Secretariat seems to have gotten
through to the working group mailing list when this draft was uploaded
into the ID directories. Anyway, its been there for a bit over a week.
Below are some quick comments on it.

Thanks,
Donald

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

Quick Comments on draft-ietf-trill-rbridge-protocol-01.txt

Section 1, next to last bullet point at bottom of page 4:
	Text has not been updated for the designation of two Rbridges in
the shim.

Section 1, third paragraph at the top of page 5:
	I would think there would also be cases where the VLAN tag was
removed by the endnode.

Section 2.1.1, on page 7:
	The 2nd and 3rd paragraphs of this section have a significant
amount of redundancy between them.

Section 2.1.1, near the top of page 8:
	The list of core-Rbridge information seems to be missing the
Rbridge nickname.

Section 2.3, first paragraph on page 11:
	"the specified Rbridge in the shim" sounds like wording from
when
there was only one. Suggest rewording this.

Section 2.3, first bullet point on page 11:
	Should that be "IP multicast routers"?

Section 2.5, first paragraph, page 13:
	Suggest changing "it is desirable" to "it may be desirable".

Section 2.5 second paragraph, Page 11:
	Typo: B2-B2-R1 should be B2-B1-R1.

Section 28.1, first normative reference on page 22:
	The D should be capitalized in 802.1D. Perhaps a reference to
802.1Q should be added.

Date: Wed, 20 Dec 2006 10:55:21 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Suggested updates to our milestones
Status: RO
Content-Length: 1384

The current milestones remaining (i.e. not already marked as DONE) are:

Aug 2006    Submit architecture document to IEEE/IETF expert review

Aug 2006    Submit routing protocol requirements to the IESG for
	    publication as an Informational RFC
Aug 2006    Submit problem statement and applicability to IESG for
	    Informational RFC
Nov 2006    Submit architecture document to the IESG for publication as
	    an Informational RFC
Dec 2006    Choose routing protocol(s) that can meet the requirements

Dec 2006    Submit base protocol specification to IEEE/IETF expert
	    review
Mar 2007    Base protocol specification submitted to the IESG for
	    publication as a Proposed Standard RFC
Jul 2007    Re-charter or shut down the WG

Suggested new milestone dates:

Jan 2007    Submit architecture document to IEEE/IETF expert review

Jan 2007    Submit routing protocol requirements to the IESG for
	    publication as an Informational RFC

Mar 2007    Choose routing protocol(s) that can meet the requirements

Mar 2007    Submit architecture document to the IESG for publication as
	    an Informational RFC

Apr 2007    Submit problem statement and applicability to IESG for
	    Informational RFC

May 2007    Base protocol specification submitted to the IESG for
	    publication as a Proposed Standard RFC

Jul 2007    Re-charter or shut down the WG

    Erik & Donald

Date: Fri, 15 Dec 2006 19:16:04 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: Don Fedyk <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 11958

Don,
See inline
Guillermo
Don Fedyk escribi?:
> Hi Guillermo
>
> See Inline.
>
>   
>> -----Original Message-----
>> From: Guillermo Ib??ez [mailto:[email-masked]] 
>>
>>
>> My previous message perhaps was not too clear. Please bear 
>> with me and 
>> my english :-)
>> - 802.1ah assumes no legacy bridges in the middle.
>>     
> This is false. 802.1ah is backwards compatible with legacy bridges.  However I think it would be safe to say this is not a plug and play option.  802.1ah would need to be configured to know the legacy bridges capabilities. But 802.1ah header is compatible with 802.1Q header for forwarding. The same trick that a TRILL RBridge uses. 
>
>   
I am not at all expert on 802.1ah , but I does not look simple to manage 
legacy bridges interposed. And away from the zero configuration target.
>> - AFAK, 802.1ah does not assume routing between nodes. If so, 
>> it would 
>> likely require TTL field.
>>     
> 802.1ah bridges from ingress to egress PBB nodes. Whether the service is IP or Ethernet on the ingress/egress PBB is a box question not outside the scope of 802.1ah architecture. 
>
>   
802.1ah bridges, does not route.
>> - TRILL does assume legacy bridges between Rbridges
>> - TRILL is not a subset of 802.1ah, it is different thing
>>     
> I don't think people ever said TRILL was a subset of 802.1ah.  
> What I said was certain versions of the TRILL header look remarkably like the 802.1ah header.  Following this logic I then said start from 802.1ah. This has not yielded any results because the part that looks like 802.1ah is hop by hop part and 802.1ah does not have a hop by hop DA part.   
>
>   
That is the key point. Hop by hop part, directly related to handle the 
intermediate legacy bridges problem.
>> - 802.1ah is not a example of simplicity.
>>     
> I don't think this type of generalization adds any value. We are talking headers and every field in 802.1ah has a purpose and good value for the bits. 
>
>   
Sorry. I meant "in the campus networks context".
>> - It is too late to question TRILL basic assumptions and try to merge 
>> 802.1ah with TRILL encapsulation.
>>     
> If you asked me if I see value in merging right now I would say no since the point to point header is not mainstream TRILL. 
>
>   
Agree. The key point again.
>> - If the whole TRILL approach is questioned (I assume it is not the 
>> case), 802.1ah does not seem the way to go regarding simplicity in 
>> campus networks.
>>     
> No one suggested you put a provider backbone bridge in place of an Rbridge.  The comment was could you use the same Frame format for the packet encaps and related functions?  And that is not looking promising.  
>
> Regards,
> Don 
>
>
>   
>> Guillermo
>>
>> Guillermo Ib??ez escribi?:
>>     
>>> Just a side comment.
>>> I think the ongoing discussion is not about encapsulation 
>>>       
>> but about the  
>>     
>>> fundamentals of RBridges approach versus 802.1ah's. So, 
>>>       
>> while agreeing 
>>     
>>> on the great  sinergies of a common encapsulation, lack of 
>>>       
>> TTL is an 
>>     
>>> essential point that reflects the essential difference in 
>>>       
>> the deployment 
>>     
>>> fields assumed.
>>> If we assume a deployment field as for 802.1ah, encapsulations and 
>>> proposals much simpler than 802.1ah are possible (one is 
>>>       
>> described in my 
>>     
>>> ABridges draft). If this is the case we should restart WG 
>>>       
>> discussion 
>>     
>>> from the beguinning.
>>>  Encapsulation for RBridges is not simple, and 802.1ah isn't simple 
>>> either, specially considering the campus networks of 
>>>       
>> moderate sizes that 
>>     
>>> are the target for RBridges.
>>> Guillermo
>>>  
>>>
>>> Gray, Eric escribi?:
>>>       
>>>> Don,
>>>>
>>>> 	I think you've garbled the discussion, somewhat.
>>>>
>>>> 	Please see below...
>>>>
>>>> --
>>>> Eric 
>>>>
>>>>   
>>>>         
>>>>> -----Original Message-----
>>>>> From: Don Fedyk [mailto:[email-masked]] 
>>>>> Sent: Wednesday, December 13, 2006 1:19 PM
>>>>> To: Gray, Eric
>>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
>>>>> Sajassi (sajassi); Silvano Gai
>>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps
>>>>>
>>>>> Hi Eric 
>>>>>
>>>>>     
>>>>>           
>>>>>> -----Original Message-----
>>>>>> From: Gray, Eric [mailto:[email-masked]] 
>>>>>>
>>>>>> Don,
>>>>>>
>>>>>> 	I don't follow your reasoning.
>>>>>>       
>>>>>>             
>>>>> That's OK I cant follow you sometimes either ;-)
>>>>>
>>>>>     
>>>>>           
>>>>>> 	I certainly am not saying that using "ANY standard header"
>>>>>> is a bad idea.
>>>>>>       
>>>>>>             
>>>>> Then why not start from ah?  The bit that Silvano said was we 
>>>>> could use ah and you said it is a bad idea.  
>>>>>     
>>>>>           
>>>> I don't think I am quoting too much out of context, when I quote
>>>> the following from Silvano's reply to Joe Touch:
>>>>
>>>> SILVANO > My comment is that IEEE 802.1ah has no space for both 
>>>> SILVANO > the ultimate source/dest and the next hop source/dest.
>>>>
>>>> SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
>>>> SILVANO > share a common metro backbone. It does a fine job in 
>>>> SILVANO > that area. It does not support well an arbitrary 
>>>> SILVANO > intermixing of Bridges and Rbridges.
>>>>
>>>> SILVANO > In contrast Trill does a fine job in supporting 
>>>> SILVANO > arbitrary topologies and mixing of RBridges and 
>>>> SILVANO > Bridges thanks to the availability of both the
>>>> SILVANO > ultimate source/dest and the next hop source/dest.
>>>>
>>>> SILVANO > In TRILL the network between the "ingress" and 
>>>> SILVANO > "egress" RBridge isn't a single Ethernet (like in 
>>>> SILVANO > 802.1ah), but rather a sequence of RBridges that 
>>>> SILVANO > may be connected by Ethernets.
>>>>
>>>> SILVANO > Things look similar, but are substantially different.
>>>>
>>>> Given that this is what (I believe, at least) Silvano said 
>>>> about using 802.1ah, where do you get the impression that 
>>>> Silvano has said that "we could use ah"?
>>>>
>>>>   
>>>>         
>>>>> Please describe "BAD idea" then.
>>>>>     
>>>>>           
>>>> In this, I think quite a few of us are now in agreement.
>>>>
>>>> It is rarely a good idea to use a header format just because
>>>> most of the bits look similar to one proposal that has all
>>>> of the information you require.
>>>>
>>>> Suppose you started to think that using 802.1ah - because it 
>>>> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
>>>> - was an example of one of the rare instances in which this 
>>>> might be a good idea.  Wouldn't you suspect that the need to 
>>>> consider potentially adding a TTL field to the header might 
>>>> be an indication that you are probably wrong?
>>>>
>>>> So, to answer your question, a "BAD idea" is one that takes
>>>> valuable resources to explore and offers no believable cause
>>>> to suspect that it will work better than other ideas already
>>>> on the table.
>>>>
>>>> In this case, we have reason to believe (MAC+SHIM)-in-MAC
>>>> will work and no reason to believe that 802.1ah will work 
>>>> better - even assuming we went down that rat-hole.
>>>>  
>>>>   
>>>>         
>>>>>> 	As for "creating a new forwarding paradigm" - yes, we're
>>>>>> doing a little bit of that.  Ideally, we'll be doing as little
>>>>>> of that as we can get away with.  The "little bit" we have to
>>>>>> do is to use some additional header information to:
>>>>>>
>>>>>> 	1) forward frames on the shortest path between RBridges,
>>>>>> 	   and
>>>>>> 	2) reduce or eliminate potential looping of frames during
>>>>>> 	   a perturbation of the shortest path.
>>>>>>       
>>>>>>             
>>>>> You have so far chosen to do this in a mode that 
>>>>>           
>> optimizes for mixed
>>     
>>>>> bridges at the cost of ignoring the effciencies you could 
>>>>>           
>> get between
>>     
>>>>> directly connected Rbridges. 802.1ah opimizes forwarding 
>>>>>           
>> for connected
>>     
>>>>> Provider Backbone Bridges and interworks with legacy at a common
>>>>> denominator. 
>>>>>     
>>>>>           
>>>> Right, and 802.1ah assumes either a green-field deployment, or a 
>>>> firmware modifiable deployment of PBB-(enabled/compatible) bridges.
>>>>
>>>> This is not consistent with our goals.
>>>>  
>>>>   
>>>>         
>>>>>> This may be somewhat of a simplification, but that's fair in 
>>>>>> light of the general trend for casual observers to do the
>>>>>> opposite.
>>>>>>
>>>>>> 	Currently, we define a SHIM to carry this information and 
>>>>>> we expect to use one or more "standard headers" to encapsulate
>>>>>> frames being forwarded between RBridges.
>>>>>>
>>>>>> 	Does this make things clearer?
>>>>>>       
>>>>>>             
>>>>> Eric I understand what is proposed but I still question 
>>>>>           
>> if a greater
>>     
>>>>> synergy cannot be achieved between encapsulating headers. 
>>>>>           
>>  A shim is a
>>     
>>>>> not a typical solution but encapsulations are.
>>>>>     
>>>>>           
>>>> Greater synergy is always demonstrably possible if you're willing
>>>> to wait long enough.
>>>>
>>>> That's - for example - why we only have one link-state routing 
>>>> protocol, and why Ethernet was the one and only MAC-like format
>>>> for L2 frames ever to have been used.
>>>>
>>>> What planet are we on?  :-)
>>>>
>>>>   
>>>>         
>>>>> Regards,
>>>>> Don   
>>>>>
>>>>>
>>>>>     
>>>>>           
>>>>>> --
>>>>>> Eric
>>>>>>
>>>>>>       
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: Don Fedyk [mailto:[email-masked]] 
>>>>>>> Sent: Wednesday, December 13, 2006 12:18 PM
>>>>>>> To: Gray, Eric; Silvano Gai
>>>>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
>>>>>>> Sajassi (sajassi)
>>>>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps
>>>>>>>
>>>>>>> Hi Eric
>>>>>>>
>>>>>>> This argument says if you use ANY standard header then it 
>>>>>>>         
>>>>>>>               
>>>>>> would be a bad
>>>>>>       
>>>>>>             
>>>>>>> idea.
>>>>>>>
>>>>>>> So you are creating a new forwarding paradigm and the down 
>>>>>>>         
>>>>>>>               
>>>>>> side of that
>>>>>>       
>>>>>>             
>>>>>>> as Ali pointed out is now you have to create most of the 
>>>>>>>         
>>>>>>>               
>>>>>> other things
>>>>>>       
>>>>>>             
>>>>>>> that go along with new forwarding paradigm.  
>>>>>>>
>>>>>>> Don  
>>>>>>>
>>>>>>>         
>>>>>>>               
>>>>>>>> -----Original Message-----
>>>>>>>> From: Gray, Eric [mailto:[email-masked]] 
>>>>>>>> Sent: Tuesday, December 12, 2006 4:29 PM
>>>>>>>>
>>>>>>>> Silvano,
>>>>>>>>
>>>>>>>> 	IFF we were going to use 802.1ah, it could allow us to  
>>>>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the
>>>>>>>> "customer" DA/SA for egress/ingress RBridges.  But that would 
>>>>>>>> be using it in a way that is not consistent with the intended
>>>>>>>> use of 802.1ah - simply because that usage would make use of 
>>>>>>>> the fields in a way that matches the way that your proposed 
>>>>>>>> "short-hand" SHIM header would use them.
>>>>>>>>
>>>>>>>> 	If you did that, there would be room for using the B-tag
>>>>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags.
>>>>>>>>
>>>>>>>> 	I think this is a VERY BAD idea.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Eric
>>>>>>>>           
>>>>>>>>                 
>>>>>>> <snip>
>>>>>>>
>>>>>>>         
>>>>>>>               
>>>> _______________________________________________
>>>> rbridge mailing list
>>>> [email-masked]
>>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>>   
>>>>         
>>> _______________________________________________
>>> rbridge mailing list
>>> [email-masked]
>>> http://mailman.postel.org/mailman/listinfo/rbridge
>>>
>>>       
>>     

Content-class: urn:content-classes:message
Date: Fri, 15 Dec 2006 12:37:11 -0500
From: "Don Fedyk" <[email-masked]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 10609

Hi Guillermo

See Inline.

> -----Original Message-----
> From: Guillermo Ib??ez [mailto:[email-masked]] 
>
> 
> My previous message perhaps was not too clear. Please bear 
> with me and 
> my english :-)
> - 802.1ah assumes no legacy bridges in the middle.
This is false. 802.1ah is backwards compatible with legacy bridges.  However I think it would be safe to say this is not a plug and play option.  802.1ah would need to be configured to know the legacy bridges capabilities. But 802.1ah header is compatible with 802.1Q header for forwarding. The same trick that a TRILL RBridge uses. 

> - AFAK, 802.1ah does not assume routing between nodes. If so, 
> it would 
> likely require TTL field.
802.1ah bridges from ingress to egress PBB nodes. Whether the service is IP or Ethernet on the ingress/egress PBB is a box question not outside the scope of 802.1ah architecture. 

> - TRILL does assume legacy bridges between Rbridges
> - TRILL is not a subset of 802.1ah, it is different thing
I don't think people ever said TRILL was a subset of 802.1ah.  
What I said was certain versions of the TRILL header look remarkably like the 802.1ah header.  Following this logic I then said start from 802.1ah. This has not yielded any results because the part that looks like 802.1ah is hop by hop part and 802.1ah does not have a hop by hop DA part.   

> - 802.1ah is not a example of simplicity.
I don't think this type of generalization adds any value. We are talking headers and every field in 802.1ah has a purpose and good value for the bits. 

> - It is too late to question TRILL basic assumptions and try to merge 
> 802.1ah with TRILL encapsulation.
If you asked me if I see value in merging right now I would say no since the point to point header is not mainstream TRILL. 

> - If the whole TRILL approach is questioned (I assume it is not the 
> case), 802.1ah does not seem the way to go regarding simplicity in 
> campus networks.
No one suggested you put a provider backbone bridge in place of an Rbridge.  The comment was could you use the same Frame format for the packet encaps and related functions?  And that is not looking promising.  

Regards,
Don 

> Guillermo
> 
> Guillermo Ib??ez escribi?:
> > Just a side comment.
> > I think the ongoing discussion is not about encapsulation 
> but about the  
> > fundamentals of RBridges approach versus 802.1ah's. So, 
> while agreeing 
> > on the great  sinergies of a common encapsulation, lack of 
> TTL is an 
> > essential point that reflects the essential difference in 
> the deployment 
> > fields assumed.
> > If we assume a deployment field as for 802.1ah, encapsulations and 
> > proposals much simpler than 802.1ah are possible (one is 
> described in my 
> > ABridges draft). If this is the case we should restart WG 
> discussion 
> > from the beguinning.
> >  Encapsulation for RBridges is not simple, and 802.1ah isn't simple 
> > either, specially considering the campus networks of 
> moderate sizes that 
> > are the target for RBridges.
> > Guillermo
> >  
> > 
> > Gray, Eric escribi?:
> >> Don,
> >>
> >> 	I think you've garbled the discussion, somewhat.
> >>
> >> 	Please see below...
> >>
> >> --
> >> Eric 
> >>
> >>   
> >>> -----Original Message-----
> >>> From: Don Fedyk [mailto:[email-masked]] 
> >>> Sent: Wednesday, December 13, 2006 1:19 PM
> >>> To: Gray, Eric
> >>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> >>> Sajassi (sajassi); Silvano Gai
> >>> Subject: RE: [rbridge] Use of 802.1ah Encaps
> >>>
> >>> Hi Eric 
> >>>
> >>>     
> >>>> -----Original Message-----
> >>>> From: Gray, Eric [mailto:[email-masked]] 
> >>>>
> >>>> Don,
> >>>>
> >>>> 	I don't follow your reasoning.
> >>>>       
> >>> That's OK I cant follow you sometimes either ;-)
> >>>
> >>>     
> >>>> 	I certainly am not saying that using "ANY standard header"
> >>>> is a bad idea.
> >>>>       
> >>> Then why not start from ah?  The bit that Silvano said was we 
> >>> could use ah and you said it is a bad idea.  
> >>>     
> >> I don't think I am quoting too much out of context, when I quote
> >> the following from Silvano's reply to Joe Touch:
> >>
> >> SILVANO > My comment is that IEEE 802.1ah has no space for both 
> >> SILVANO > the ultimate source/dest and the next hop source/dest.
> >>
> >> SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
> >> SILVANO > share a common metro backbone. It does a fine job in 
> >> SILVANO > that area. It does not support well an arbitrary 
> >> SILVANO > intermixing of Bridges and Rbridges.
> >>
> >> SILVANO > In contrast Trill does a fine job in supporting 
> >> SILVANO > arbitrary topologies and mixing of RBridges and 
> >> SILVANO > Bridges thanks to the availability of both the
> >> SILVANO > ultimate source/dest and the next hop source/dest.
> >>
> >> SILVANO > In TRILL the network between the "ingress" and 
> >> SILVANO > "egress" RBridge isn't a single Ethernet (like in 
> >> SILVANO > 802.1ah), but rather a sequence of RBridges that 
> >> SILVANO > may be connected by Ethernets.
> >>
> >> SILVANO > Things look similar, but are substantially different.
> >>
> >> Given that this is what (I believe, at least) Silvano said 
> >> about using 802.1ah, where do you get the impression that 
> >> Silvano has said that "we could use ah"?
> >>
> >>   
> >>> Please describe "BAD idea" then.
> >>>     
> >> In this, I think quite a few of us are now in agreement.
> >>
> >> It is rarely a good idea to use a header format just because
> >> most of the bits look similar to one proposal that has all
> >> of the information you require.
> >>
> >> Suppose you started to think that using 802.1ah - because it 
> >> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
> >> - was an example of one of the rare instances in which this 
> >> might be a good idea.  Wouldn't you suspect that the need to 
> >> consider potentially adding a TTL field to the header might 
> >> be an indication that you are probably wrong?
> >>
> >> So, to answer your question, a "BAD idea" is one that takes
> >> valuable resources to explore and offers no believable cause
> >> to suspect that it will work better than other ideas already
> >> on the table.
> >>
> >> In this case, we have reason to believe (MAC+SHIM)-in-MAC
> >> will work and no reason to believe that 802.1ah will work 
> >> better - even assuming we went down that rat-hole.
> >>  
> >>   
> >>>> 	As for "creating a new forwarding paradigm" - yes, we're
> >>>> doing a little bit of that.  Ideally, we'll be doing as little
> >>>> of that as we can get away with.  The "little bit" we have to
> >>>> do is to use some additional header information to:
> >>>>
> >>>> 	1) forward frames on the shortest path between RBridges,
> >>>> 	   and
> >>>> 	2) reduce or eliminate potential looping of frames during
> >>>> 	   a perturbation of the shortest path.
> >>>>       
> >>> You have so far chosen to do this in a mode that 
> optimizes for mixed
> >>> bridges at the cost of ignoring the effciencies you could 
> get between
> >>> directly connected Rbridges. 802.1ah opimizes forwarding 
> for connected
> >>> Provider Backbone Bridges and interworks with legacy at a common
> >>> denominator. 
> >>>     
> >> Right, and 802.1ah assumes either a green-field deployment, or a 
> >> firmware modifiable deployment of PBB-(enabled/compatible) bridges.
> >>
> >> This is not consistent with our goals.
> >>  
> >>   
> >>>> This may be somewhat of a simplification, but that's fair in 
> >>>> light of the general trend for casual observers to do the
> >>>> opposite.
> >>>>
> >>>> 	Currently, we define a SHIM to carry this information and 
> >>>> we expect to use one or more "standard headers" to encapsulate
> >>>> frames being forwarded between RBridges.
> >>>>
> >>>> 	Does this make things clearer?
> >>>>       
> >>> Eric I understand what is proposed but I still question 
> if a greater
> >>> synergy cannot be achieved between encapsulating headers. 
>  A shim is a
> >>> not a typical solution but encapsulations are.
> >>>     
> >> Greater synergy is always demonstrably possible if you're willing
> >> to wait long enough.
> >>
> >> That's - for example - why we only have one link-state routing 
> >> protocol, and why Ethernet was the one and only MAC-like format
> >> for L2 frames ever to have been used.
> >>
> >> What planet are we on?  :-)
> >>
> >>   
> >>> Regards,
> >>> Don   
> >>>
> >>>
> >>>     
> >>>> --
> >>>> Eric
> >>>>
> >>>>       
> >>>>> -----Original Message-----
> >>>>> From: Don Fedyk [mailto:[email-masked]] 
> >>>>> Sent: Wednesday, December 13, 2006 12:18 PM
> >>>>> To: Gray, Eric; Silvano Gai
> >>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> >>>>> Sajassi (sajassi)
> >>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps
> >>>>>
> >>>>> Hi Eric
> >>>>>
> >>>>> This argument says if you use ANY standard header then it 
> >>>>>         
> >>>> would be a bad
> >>>>       
> >>>>> idea.
> >>>>>
> >>>>> So you are creating a new forwarding paradigm and the down 
> >>>>>         
> >>>> side of that
> >>>>       
> >>>>> as Ali pointed out is now you have to create most of the 
> >>>>>         
> >>>> other things
> >>>>       
> >>>>> that go along with new forwarding paradigm.  
> >>>>>
> >>>>> Don  
> >>>>>
> >>>>>         
> >>>>>> -----Original Message-----
> >>>>>> From: Gray, Eric [mailto:[email-masked]] 
> >>>>>> Sent: Tuesday, December 12, 2006 4:29 PM
> >>>>>>
> >>>>>> Silvano,
> >>>>>>
> >>>>>> 	IFF we were going to use 802.1ah, it could allow us to  
> >>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the
> >>>>>> "customer" DA/SA for egress/ingress RBridges.  But that would 
> >>>>>> be using it in a way that is not consistent with the intended
> >>>>>> use of 802.1ah - simply because that usage would make use of 
> >>>>>> the fields in a way that matches the way that your proposed 
> >>>>>> "short-hand" SHIM header would use them.
> >>>>>>
> >>>>>> 	If you did that, there would be room for using the B-tag
> >>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags.
> >>>>>>
> >>>>>> 	I think this is a VERY BAD idea.
> >>>>>>
> >>>>>> --
> >>>>>> Eric
> >>>>>>           
> >>>>> <snip>
> >>>>>
> >>>>>         
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>   
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> 

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>
Date: Fri, 15 Dec 2006 11:54:56 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Breaking up of Spanning Trees - (Was Use of 802.1ah	 Encaps)
Status: RO
Content-Length: 5751

Don,

	We (the TRILL working group) are not completely decided
on this, and how we can make it work in the face of other things
we also have to make work.

	Yes, we want to break up the spanning trees, but we also
are being asked to address certain issues that arise as a result
of doing so.  In particular, there is a "wiring closet" problem
that we have been assured is one we MUST solve.

	The (currently?) leading proposal for how to deal with 
that is to have (some?) RBridges participate in spanning tree
protocol in such a way as to cause "wiring closet" bridges to
see (at least part of) the RBridge "CRED" as a single bridge 
(with that bridge set up to be the root bridge).  I am pretty 
sure (at this point) that this will be a configurable option 
which will not be "on" by default.

	I think the reasoning for this is that it would be okay 
to have a configuration requirement that would only require
configuration if it is necessary to solve this problem - hence 
it remains possible to have a plug-and-play solution.

	However, this particular problem points out a potential 
"general class" of problems relating to breaking up spanning
trees.  And we do not currently have a "correctness proof" -
or even a good try at one - that might lead us to believe that
we do not have further issues to address, except by turning 
this "breaking up" feature off.

	For example, one model for RBridge interactions - that
has been considered from very early on - is one where a "CRED"
appears to existing 802.<whatever> bridges as a single bridge.
This model does not suffer from the above "general class" of
problems, because it does not actually break up the spanning
trees.  All of the fractional LANs separated by RBridges will
see each other in spanning tree protocol if this model is used.

	As a direct consequence, it may turn out that we will be
required to support - at least as a configurable option - that
RBridges do not break up spanning trees.  I believe there is a
lot of work that needs to be done if this is the case...

--
Eric

(part of your earlier message included the following)	
> 
> But as Ali pointed out 802.1ah is backwards compatible with 
> everything.  On goals one goal of RBridge was to improve 
> spanning tree by breaking up a large spanning tree with 
> Rbridges providing interconnection of these smaller trees. 
> A certain amount of insertion of Rbridges on shortest paths 
> is required before this goal is realizable.  I agree large
> provider networks are not your goal. And perhaps you are 
> right that this justifies different technology but Ethernet 
> did not get to high scale [commoditization] by changing the 
> forwarding paradigm.
> >  
> > > 
> > > > 
> > > > This may be somewhat of a simplification, but that's fair in 
> > > > light of the general trend for casual observers to do the
> > > > opposite.
> > > > 
> > > > 	Currently, we define a SHIM to carry this 
> information and 
> > > > we expect to use one or more "standard headers" to encapsulate
> > > > frames being forwarded between RBridges.
> > > > 
> > > > 	Does this make things clearer?
> > > 
> > > Eric I understand what is proposed but I still question 
> if a greater
> > > synergy cannot be achieved between encapsulating headers.  
> > A shim is a
> > > not a typical solution but encapsulations are.
> > 
> > Greater synergy is always demonstrably possible if you're willing
> > to wait long enough.
> > 
> > That's - for example - why we only have one link-state routing 
> > protocol, and why Ethernet was the one and only MAC-like format
> > for L2 frames ever to have been used.
> > 
> > What planet are we on?  :-)
> As an engineer I have to ask the question. "Is this the best 
> we can do?"
> So even though history has proven that multiple implementations often
> result the question has to be asked never the less.
> 
> Regards,
> Don 
> 
> 
> > 
> > > 
> > > Regards,
> > > Don   
> > > 
> > > 
> > > > 
> > > > --
> > > > Eric
> > > > 
> > > > > -----Original Message-----
> > > > > From: Don Fedyk [mailto:[email-masked]] 
> > > > > Sent: Wednesday, December 13, 2006 12:18 PM
> > > > > To: Gray, Eric; Silvano Gai
> > > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > > > > Sajassi (sajassi)
> > > > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > > > 
> > > > > Hi Eric
> > > > > 
> > > > > This argument says if you use ANY standard header then it 
> > > > would be a bad
> > > > > idea.
> > > > > 
> > > > > So you are creating a new forwarding paradigm and the down 
> > > > side of that
> > > > > as Ali pointed out is now you have to create most of the 
> > > > other things
> > > > > that go along with new forwarding paradigm.  
> > > > > 
> > > > > Don  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Gray, Eric [mailto:[email-masked]] 
> > > > > > Sent: Tuesday, December 12, 2006 4:29 PM
> > > > > > 
> > > > > > Silvano,
> > > > > > 
> > > > > > 	IFF we were going to use 802.1ah, it could allow us to  
> > > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the
> > > > > > "customer" DA/SA for egress/ingress RBridges.  But 
> that would 
> > > > > > be using it in a way that is not consistent with 
> the intended
> > > > > > use of 802.1ah - simply because that usage would 
> make use of 
> > > > > > the fields in a way that matches the way that your proposed 
> > > > > > "short-hand" SHIM header would use them.
> > > > > > 
> > > > > > 	If you did that, there would be room for using the B-tag
> > > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags.
> > > > > > 
> > > > > > 	I think this is a VERY BAD idea.
> > > > > > 
> > > > > > --
> > > > > > Eric
> > > > > <snip>
> > > > > 
> > > > 
> > > 
> > 
> 

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>
Date: Fri, 15 Dec 2006 11:54:59 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Synergy - (Was Use of 802.1ah Encaps)
Status: RO
Content-Length: 768

Don,

	For good or bad, we don't live in a world ruled by
engineering goals.  It is arguable that - if we did - we
would _almost_ have perfected the wheel by now...

	:-)

--
Eric

(part of our earlier dialogue is included below
I said: 
> > Greater synergy is always demonstrably possible if you're willing
> > to wait long enough.
> > 
> > That's - for example - why we only have one link-state routing 
> > protocol, and why Ethernet was the one and only MAC-like format
> > for L2 frames ever to have been used.
> > 
> > What planet are we on?  :-)

You said:
> As an engineer I have to ask the question. "Is this the best we can do?"
> So even though history has proven that multiple implementations often
> result the question has to be asked never the less.
> 

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>
Date: Fri, 15 Dec 2006 11:54:29 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 9202

Don,

	I will reply to your points in separate threads: 

-	TTL Use
-	Breaking up Spanning Trees
-	Synergy

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Thursday, December 14, 2006 10:48 AM
> To: Gray, Eric
> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> Sajassi (sajassi); Silvano Gai
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Hi Eric 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > 
> > Don,
> > 
> > 	I think you've garbled the discussion, somewhat.
> > 
> > 	Please see below...
> I'll answer inline here specifically. Thanks for providing 
> more context.
> 
> > 
> > --
> > Eric 
> > 
> > > -----Original Message-----
> > > From: Don Fedyk [mailto:[email-masked]] 
> > > Sent: Wednesday, December 13, 2006 1:19 PM
> > > To: Gray, Eric
> > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > > Sajassi (sajassi); Silvano Gai
> > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > 
> > > Hi Eric 
> > > 
> > > > -----Original Message-----
> > > > From: Gray, Eric [mailto:[email-masked]] 
> > > > 
> > > > Don,
> > > > 
> > > > 	I don't follow your reasoning.
> > > That's OK I cant follow you sometimes either ;-)
> > > 
> > > > 
> > > > 	I certainly am not saying that using "ANY 
> standard header"
> > > > is a bad idea.
> > > Then why not start from ah?  The bit that Silvano said was we 
> > > could use ah and you said it is a bad idea.  
> > 
> > I don't think I am quoting too much out of context, when I quote
> > the following from Silvano's reply to Joe Touch:
> > 
> > SILVANO > My comment is that IEEE 802.1ah has no space for both 
> > SILVANO > the ultimate source/dest and the next hop source/dest.
> > 
> > SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
> > SILVANO > share a common metro backbone. It does a fine job in 
> > SILVANO > that area. It does not support well an arbitrary 
> > SILVANO > intermixing of Bridges and Rbridges.
> > 
> > SILVANO > In contrast Trill does a fine job in supporting 
> > SILVANO > arbitrary topologies and mixing of RBridges and 
> > SILVANO > Bridges thanks to the availability of both the
> > SILVANO > ultimate source/dest and the next hop source/dest.
> > 
> > SILVANO > In TRILL the network between the "ingress" and 
> > SILVANO > "egress" RBridge isn't a single Ethernet (like in 
> > SILVANO > 802.1ah), but rather a sequence of RBridges that 
> > SILVANO > may be connected by Ethernets.
> > 
> > SILVANO > Things look similar, but are substantially different.
> > 
> > Given that this is what (I believe, at least) Silvano said 
> > about using 802.1ah, where do you get the impression that 
> > Silvano has said that "we could use ah"?
> > 
> > > 
> > > Please describe "BAD idea" then.
> > 
> > In this, I think quite a few of us are now in agreement.
> > 
> > It is rarely a good idea to use a header format just because
> > most of the bits look similar to one proposal that has all
> > of the information you require.
> 
> I agree. Bits on the wire looking just like other bits on the wire
> having different context are not good.
> 
> > 
> > Suppose you started to think that using 802.1ah - because it 
> > is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
> > - was an example of one of the rare instances in which this 
> > might be a good idea.  Wouldn't you suspect that the need to 
> > consider potentially adding a TTL field to the header might 
> > be an indication that you are probably wrong?
> 
> Ahh this is what you mean. TTL is one method for a number of things,
> Loop mitigation, tracing, fault monitoring etc. It has pluses and
> minuses. Personally speaking as an individual I like TTL.  
> Although I am
> also aware of many systems and I also built systems that are 
> operational
> without TTL. TTL has shortcommings as well even in IP.  It is 
> not a bad
> tool for some applications.  I know this group values it, I'm not
> suggesting you drop that goal or requirement.  But a 
> requiremetn for TTL
> alone does not mandate a licence to change everything either IMHO. 
> 
> > 
> > So, to answer your question, a "BAD idea" is one that takes
> > valuable resources to explore and offers no believable cause
> > to suspect that it will work better than other ideas already
> > on the table.
> > 
> > In this case, we have reason to believe (MAC+SHIM)-in-MAC
> > will work and no reason to believe that 802.1ah will work 
> > better - even assuming we went down that rat-hole.
> >  
> > > 
> > > > 
> > > > 	As for "creating a new forwarding paradigm" - yes, we're
> > > > doing a little bit of that.  Ideally, we'll be doing as little
> > > > of that as we can get away with.  The "little bit" we have to
> > > > do is to use some additional header information to:
> > > > 
> > > > 	1) forward frames on the shortest path between RBridges,
> > > > 	   and
> > > > 	2) reduce or eliminate potential looping of 
> frames during
> > > > 	   a perturbation of the shortest path.
> > > 
> > > You have so far chosen to do this in a mode that 
> optimizes for mixed
> > > bridges at the cost of ignoring the effciencies you could 
> > get between
> > > directly connected Rbridges. 802.1ah opimizes forwarding 
> > for connected
> > > Provider Backbone Bridges and interworks with legacy at a common
> > > denominator. 
> > 
> > Right, and 802.1ah assumes either a green-field deployment, or a 
> > firmware modifiable deployment of PBB-(enabled/compatible) bridges.
> > 
> > This is not consistent with our goals.
> 
> But as Ali pointed out 802.1ah is backwards compatible with 
> everything.
> On goals one goal of RBridge was to improve spanning tree by 
> breaking up
> a large spanning tree with Rbridges providing interconnection of these
> smaller trees. A certain amount of insertion of Rbridges on shortest
> paths is required before this goal is realizable.  I agree large
> provider networks are not your goal. And perhaps you are 
> right that this
> justifies different technology but Ethernet did not get to high scale
> comodization by changing the forwarding paradigm.
> >  
> > > 
> > > > 
> > > > This may be somewhat of a simplification, but that's fair in 
> > > > light of the general trend for casual observers to do the
> > > > opposite.
> > > > 
> > > > 	Currently, we define a SHIM to carry this 
> information and 
> > > > we expect to use one or more "standard headers" to encapsulate
> > > > frames being forwarded between RBridges.
> > > > 
> > > > 	Does this make things clearer?
> > > 
> > > Eric I understand what is proposed but I still question 
> if a greater
> > > synergy cannot be achieved between encapsulating headers.  
> > A shim is a
> > > not a typical solution but encapsulations are.
> > 
> > Greater synergy is always demonstrably possible if you're willing
> > to wait long enough.
> > 
> > That's - for example - why we only have one link-state routing 
> > protocol, and why Ethernet was the one and only MAC-like format
> > for L2 frames ever to have been used.
> > 
> > What planet are we on?  :-)
> As an engineer I have to ask the question. "Is this the best 
> we can do?"
> So even though history has proven that multiple implementations often
> result the question has to be asked never the less.
> 
> Regards,
> Don 
> 
> 
> > 
> > > 
> > > Regards,
> > > Don   
> > > 
> > > 
> > > > 
> > > > --
> > > > Eric
> > > > 
> > > > > -----Original Message-----
> > > > > From: Don Fedyk [mailto:[email-masked]] 
> > > > > Sent: Wednesday, December 13, 2006 12:18 PM
> > > > > To: Gray, Eric; Silvano Gai
> > > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > > > > Sajassi (sajassi)
> > > > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > > > 
> > > > > Hi Eric
> > > > > 
> > > > > This argument says if you use ANY standard header then it 
> > > > would be a bad
> > > > > idea.
> > > > > 
> > > > > So you are creating a new forwarding paradigm and the down 
> > > > side of that
> > > > > as Ali pointed out is now you have to create most of the 
> > > > other things
> > > > > that go along with new forwarding paradigm.  
> > > > > 
> > > > > Don  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Gray, Eric [mailto:[email-masked]] 
> > > > > > Sent: Tuesday, December 12, 2006 4:29 PM
> > > > > > 
> > > > > > Silvano,
> > > > > > 
> > > > > > 	IFF we were going to use 802.1ah, it could allow us to  
> > > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the
> > > > > > "customer" DA/SA for egress/ingress RBridges.  But 
> that would 
> > > > > > be using it in a way that is not consistent with 
> the intended
> > > > > > use of 802.1ah - simply because that usage would 
> make use of 
> > > > > > the fields in a way that matches the way that your proposed 
> > > > > > "short-hand" SHIM header would use them.
> > > > > > 
> > > > > > 	If you did that, there would be room for using the B-tag
> > > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags.
> > > > > > 
> > > > > > 	I think this is a VERY BAD idea.
> > > > > > 
> > > > > > --
> > > > > > Eric
> > > > > <snip>
> > > > > 
> > > > 
> > > 
> > 
> 

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>
Date: Fri, 15 Dec 2006 11:54:45 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] TTL use - (was Use of 802.1ah Encaps)
Status: RO
Content-Length: 1632

Don,

	I believe the key reason why we've more or less locked on
to using TTL for loop mitigation of (at least) unicast frame
forwarding is that the formation of temporary loops is hard to
avoid using existing link state routing protocols.  We've agreed
- at least in principle - to adopt whatever comes out of the 
routing working group's efforts to avoid loop formation (micro-
loop formation in particular), but this does not appear to rid
us of that problem.

	Yes, other loop mitigation techniques have been discussed
previously but TTL is the one with which most of us have more
experience.

	There are also loop-prevention techniques such as may be
achieved using STP and/or one of various signaling approaches.
At present, we are not - on the whole - considering any of these
approaches for work by the TRILL working group.  Most exist now
but would require (potentially major) modification, or are in
progress elsewhere (for other - possibly incompatible - purposes).

--
Eric 

(part of your previous message is included below)
> 
> Ahh this is what you mean. TTL is one method for a number of things,
> Loop mitigation, tracing, fault monitoring etc. It has pluses and
> minuses. Personally speaking as an individual I like TTL.  Although 
> I am > also aware of many systems and I also built systems that are 
> operational without TTL. TTL has shortcommings as well even in IP.  
> It is not a bad tool for some applications.  I know this group values 
> it, I'm not suggesting you drop that goal or requirement.  But a 
> [requirement] for TTL alone does not mandate a licence to change 
> everything either IMHO. 
> 

Date: Fri, 15 Dec 2006 12:27:03 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 8581

My previous message perhaps was not too clear. Please bear with me and 
my english :-)
- 802.1ah assumes no legacy bridges in the middle.
- AFAK, 802.1ah does not assume routing between nodes. If so, it would 
likely require TTL field.
- TRILL does assume legacy bridges between RBridges
- TRILL is not a subset of 802.1ah, it is different thing
- 802.1ah is not a example of simplicity.
- It is too late to question TRILL basic assumptions and try to merge 
802.1ah with TRILL encapsulation.
- If the whole TRILL approach is questioned (I assume it is not the 
case), 802.1ah does not seem the way to go regarding simplicity in 
campus networks.
Guillermo

Guillermo Ib??ez escribi?:
> Just a side comment.
> I think the ongoing discussion is not about encapsulation but about the  
> fundamentals of RBridges approach versus 802.1ah's. So, while agreeing 
> on the great  sinergies of a common encapsulation, lack of TTL is an 
> essential point that reflects the essential difference in the deployment 
> fields assumed.
> If we assume a deployment field as for 802.1ah, encapsulations and 
> proposals much simpler than 802.1ah are possible (one is described in my 
> ABridges draft). If this is the case we should restart WG discussion 
> from the beguinning.
>  Encapsulation for RBridges is not simple, and 802.1ah isn't simple 
> either, specially considering the campus networks of moderate sizes that 
> are the target for RBridges.
> Guillermo
>  
> 
> Gray, Eric escribi?:
>> Don,
>>
>> 	I think you've garbled the discussion, somewhat.
>>
>> 	Please see below...
>>
>> --
>> Eric 
>>
>>   
>>> -----Original Message-----
>>> From: Don Fedyk [mailto:[email-masked]] 
>>> Sent: Wednesday, December 13, 2006 1:19 PM
>>> To: Gray, Eric
>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
>>> Sajassi (sajassi); Silvano Gai
>>> Subject: RE: [rbridge] Use of 802.1ah Encaps
>>>
>>> Hi Eric 
>>>
>>>     
>>>> -----Original Message-----
>>>> From: Gray, Eric [mailto:[email-masked]] 
>>>>
>>>> Don,
>>>>
>>>> 	I don't follow your reasoning.
>>>>       
>>> That's OK I cant follow you sometimes either ;-)
>>>
>>>     
>>>> 	I certainly am not saying that using "ANY standard header"
>>>> is a bad idea.
>>>>       
>>> Then why not start from ah?  The bit that Silvano said was we 
>>> could use ah and you said it is a bad idea.  
>>>     
>> I don't think I am quoting too much out of context, when I quote
>> the following from Silvano's reply to Joe Touch:
>>
>> SILVANO > My comment is that IEEE 802.1ah has no space for both 
>> SILVANO > the ultimate source/dest and the next hop source/dest.
>>
>> SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
>> SILVANO > share a common metro backbone. It does a fine job in 
>> SILVANO > that area. It does not support well an arbitrary 
>> SILVANO > intermixing of Bridges and Rbridges.
>>
>> SILVANO > In contrast Trill does a fine job in supporting 
>> SILVANO > arbitrary topologies and mixing of RBridges and 
>> SILVANO > Bridges thanks to the availability of both the
>> SILVANO > ultimate source/dest and the next hop source/dest.
>>
>> SILVANO > In TRILL the network between the "ingress" and 
>> SILVANO > "egress" RBridge isn't a single Ethernet (like in 
>> SILVANO > 802.1ah), but rather a sequence of RBridges that 
>> SILVANO > may be connected by Ethernets.
>>
>> SILVANO > Things look similar, but are substantially different.
>>
>> Given that this is what (I believe, at least) Silvano said 
>> about using 802.1ah, where do you get the impression that 
>> Silvano has said that "we could use ah"?
>>
>>   
>>> Please describe "BAD idea" then.
>>>     
>> In this, I think quite a few of us are now in agreement.
>>
>> It is rarely a good idea to use a header format just because
>> most of the bits look similar to one proposal that has all
>> of the information you require.
>>
>> Suppose you started to think that using 802.1ah - because it 
>> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
>> - was an example of one of the rare instances in which this 
>> might be a good idea.  Wouldn't you suspect that the need to 
>> consider potentially adding a TTL field to the header might 
>> be an indication that you are probably wrong?
>>
>> So, to answer your question, a "BAD idea" is one that takes
>> valuable resources to explore and offers no believable cause
>> to suspect that it will work better than other ideas already
>> on the table.
>>
>> In this case, we have reason to believe (MAC+SHIM)-in-MAC
>> will work and no reason to believe that 802.1ah will work 
>> better - even assuming we went down that rat-hole.
>>  
>>   
>>>> 	As for "creating a new forwarding paradigm" - yes, we're
>>>> doing a little bit of that.  Ideally, we'll be doing as little
>>>> of that as we can get away with.  The "little bit" we have to
>>>> do is to use some additional header information to:
>>>>
>>>> 	1) forward frames on the shortest path between RBridges,
>>>> 	   and
>>>> 	2) reduce or eliminate potential looping of frames during
>>>> 	   a perturbation of the shortest path.
>>>>       
>>> You have so far chosen to do this in a mode that optimizes for mixed
>>> bridges at the cost of ignoring the effciencies you could get between
>>> directly connected Rbridges. 802.1ah opimizes forwarding for connected
>>> Provider Backbone Bridges and interworks with legacy at a common
>>> denominator. 
>>>     
>> Right, and 802.1ah assumes either a green-field deployment, or a 
>> firmware modifiable deployment of PBB-(enabled/compatible) bridges.
>>
>> This is not consistent with our goals.
>>  
>>   
>>>> This may be somewhat of a simplification, but that's fair in 
>>>> light of the general trend for casual observers to do the
>>>> opposite.
>>>>
>>>> 	Currently, we define a SHIM to carry this information and 
>>>> we expect to use one or more "standard headers" to encapsulate
>>>> frames being forwarded between RBridges.
>>>>
>>>> 	Does this make things clearer?
>>>>       
>>> Eric I understand what is proposed but I still question if a greater
>>> synergy cannot be achieved between encapsulating headers.  A shim is a
>>> not a typical solution but encapsulations are.
>>>     
>> Greater synergy is always demonstrably possible if you're willing
>> to wait long enough.
>>
>> That's - for example - why we only have one link-state routing 
>> protocol, and why Ethernet was the one and only MAC-like format
>> for L2 frames ever to have been used.
>>
>> What planet are we on?  :-)
>>
>>   
>>> Regards,
>>> Don   
>>>
>>>
>>>     
>>>> --
>>>> Eric
>>>>
>>>>       
>>>>> -----Original Message-----
>>>>> From: Don Fedyk [mailto:[email-masked]] 
>>>>> Sent: Wednesday, December 13, 2006 12:18 PM
>>>>> To: Gray, Eric; Silvano Gai
>>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
>>>>> Sajassi (sajassi)
>>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps
>>>>>
>>>>> Hi Eric
>>>>>
>>>>> This argument says if you use ANY standard header then it 
>>>>>         
>>>> would be a bad
>>>>       
>>>>> idea.
>>>>>
>>>>> So you are creating a new forwarding paradigm and the down 
>>>>>         
>>>> side of that
>>>>       
>>>>> as Ali pointed out is now you have to create most of the 
>>>>>         
>>>> other things
>>>>       
>>>>> that go along with new forwarding paradigm.  
>>>>>
>>>>> Don  
>>>>>
>>>>>         
>>>>>> -----Original Message-----
>>>>>> From: Gray, Eric [mailto:[email-masked]] 
>>>>>> Sent: Tuesday, December 12, 2006 4:29 PM
>>>>>>
>>>>>> Silvano,
>>>>>>
>>>>>> 	IFF we were going to use 802.1ah, it could allow us to  
>>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the
>>>>>> "customer" DA/SA for egress/ingress RBridges.  But that would 
>>>>>> be using it in a way that is not consistent with the intended
>>>>>> use of 802.1ah - simply because that usage would make use of 
>>>>>> the fields in a way that matches the way that your proposed 
>>>>>> "short-hand" SHIM header would use them.
>>>>>>
>>>>>> 	If you did that, there would be room for using the B-tag
>>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags.
>>>>>>
>>>>>> 	I think this is a VERY BAD idea.
>>>>>>
>>>>>> --
>>>>>> Eric
>>>>>>           
>>>>> <snip>
>>>>>
>>>>>         
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>   
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Thu, 14 Dec 2006 10:47:53 -0500
From: "Don Fedyk" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 8300

Hi Eric 

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> 
> Don,
> 
> 	I think you've garbled the discussion, somewhat.
> 
> 	Please see below...
I'll answer inline here specifically. Thanks for providing more context.

> 
> --
> Eric 
> 
> > -----Original Message-----
> > From: Don Fedyk [mailto:[email-masked]] 
> > Sent: Wednesday, December 13, 2006 1:19 PM
> > To: Gray, Eric
> > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > Sajassi (sajassi); Silvano Gai
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > Hi Eric 
> > 
> > > -----Original Message-----
> > > From: Gray, Eric [mailto:[email-masked]] 
> > > 
> > > Don,
> > > 
> > > 	I don't follow your reasoning.
> > That's OK I cant follow you sometimes either ;-)
> > 
> > > 
> > > 	I certainly am not saying that using "ANY standard header"
> > > is a bad idea.
> > Then why not start from ah?  The bit that Silvano said was we 
> > could use ah and you said it is a bad idea.  
> 
> I don't think I am quoting too much out of context, when I quote
> the following from Silvano's reply to Joe Touch:
> 
> SILVANO > My comment is that IEEE 802.1ah has no space for both 
> SILVANO > the ultimate source/dest and the next hop source/dest.
> 
> SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
> SILVANO > share a common metro backbone. It does a fine job in 
> SILVANO > that area. It does not support well an arbitrary 
> SILVANO > intermixing of Bridges and Rbridges.
> 
> SILVANO > In contrast Trill does a fine job in supporting 
> SILVANO > arbitrary topologies and mixing of RBridges and 
> SILVANO > Bridges thanks to the availability of both the
> SILVANO > ultimate source/dest and the next hop source/dest.
> 
> SILVANO > In TRILL the network between the "ingress" and 
> SILVANO > "egress" RBridge isn't a single Ethernet (like in 
> SILVANO > 802.1ah), but rather a sequence of RBridges that 
> SILVANO > may be connected by Ethernets.
> 
> SILVANO > Things look similar, but are substantially different.
> 
> Given that this is what (I believe, at least) Silvano said 
> about using 802.1ah, where do you get the impression that 
> Silvano has said that "we could use ah"?
> 
> > 
> > Please describe "BAD idea" then.
> 
> In this, I think quite a few of us are now in agreement.
> 
> It is rarely a good idea to use a header format just because
> most of the bits look similar to one proposal that has all
> of the information you require.

I agree. Bits on the wire looking just like other bits on the wire
having different context are not good.

> 
> Suppose you started to think that using 802.1ah - because it 
> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
> - was an example of one of the rare instances in which this 
> might be a good idea.  Wouldn't you suspect that the need to 
> consider potentially adding a TTL field to the header might 
> be an indication that you are probably wrong?

Ahh this is what you mean. TTL is one method for a number of things,
Loop mitigation, tracing, fault monitoring etc. It has pluses and
minuses. Personally speaking as an individual I like TTL.  Although I am
also aware of many systems and I also built systems that are operational
without TTL. TTL has shortcommings as well even in IP.  It is not a bad
tool for some applications.  I know this group values it, I'm not
suggesting you drop that goal or requirement.  But a requiremetn for TTL
alone does not mandate a licence to change everything either IMHO. 

> 
> So, to answer your question, a "BAD idea" is one that takes
> valuable resources to explore and offers no believable cause
> to suspect that it will work better than other ideas already
> on the table.
> 
> In this case, we have reason to believe (MAC+SHIM)-in-MAC
> will work and no reason to believe that 802.1ah will work 
> better - even assuming we went down that rat-hole.
>  
> > 
> > > 
> > > 	As for "creating a new forwarding paradigm" - yes, we're
> > > doing a little bit of that.  Ideally, we'll be doing as little
> > > of that as we can get away with.  The "little bit" we have to
> > > do is to use some additional header information to:
> > > 
> > > 	1) forward frames on the shortest path between RBridges,
> > > 	   and
> > > 	2) reduce or eliminate potential looping of frames during
> > > 	   a perturbation of the shortest path.
> > 
> > You have so far chosen to do this in a mode that optimizes for mixed
> > bridges at the cost of ignoring the effciencies you could 
> get between
> > directly connected Rbridges. 802.1ah opimizes forwarding 
> for connected
> > Provider Backbone Bridges and interworks with legacy at a common
> > denominator. 
> 
> Right, and 802.1ah assumes either a green-field deployment, or a 
> firmware modifiable deployment of PBB-(enabled/compatible) bridges.
> 
> This is not consistent with our goals.

But as Ali pointed out 802.1ah is backwards compatible with everything.
On goals one goal of RBridge was to improve spanning tree by breaking up
a large spanning tree with Rbridges providing interconnection of these
smaller trees. A certain amount of insertion of Rbridges on shortest
paths is required before this goal is realizable.  I agree large
provider networks are not your goal. And perhaps you are right that this
justifies different technology but Ethernet did not get to high scale
comodization by changing the forwarding paradigm.
>  
> > 
> > > 
> > > This may be somewhat of a simplification, but that's fair in 
> > > light of the general trend for casual observers to do the
> > > opposite.
> > > 
> > > 	Currently, we define a SHIM to carry this information and 
> > > we expect to use one or more "standard headers" to encapsulate
> > > frames being forwarded between RBridges.
> > > 
> > > 	Does this make things clearer?
> > 
> > Eric I understand what is proposed but I still question if a greater
> > synergy cannot be achieved between encapsulating headers.  
> A shim is a
> > not a typical solution but encapsulations are.
> 
> Greater synergy is always demonstrably possible if you're willing
> to wait long enough.
> 
> That's - for example - why we only have one link-state routing 
> protocol, and why Ethernet was the one and only MAC-like format
> for L2 frames ever to have been used.
> 
> What planet are we on?  :-)
As an engineer I have to ask the question. "Is this the best we can do?"
So even though history has proven that multiple implementations often
result the question has to be asked never the less.

Regards,
Don 

> 
> > 
> > Regards,
> > Don   
> > 
> > 
> > > 
> > > --
> > > Eric
> > > 
> > > > -----Original Message-----
> > > > From: Don Fedyk [mailto:[email-masked]] 
> > > > Sent: Wednesday, December 13, 2006 12:18 PM
> > > > To: Gray, Eric; Silvano Gai
> > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > > > Sajassi (sajassi)
> > > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > > 
> > > > Hi Eric
> > > > 
> > > > This argument says if you use ANY standard header then it 
> > > would be a bad
> > > > idea.
> > > > 
> > > > So you are creating a new forwarding paradigm and the down 
> > > side of that
> > > > as Ali pointed out is now you have to create most of the 
> > > other things
> > > > that go along with new forwarding paradigm.  
> > > > 
> > > > Don  
> > > > 
> > > > > -----Original Message-----
> > > > > From: Gray, Eric [mailto:[email-masked]] 
> > > > > Sent: Tuesday, December 12, 2006 4:29 PM
> > > > > 
> > > > > Silvano,
> > > > > 
> > > > > 	IFF we were going to use 802.1ah, it could allow us to  
> > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the
> > > > > "customer" DA/SA for egress/ingress RBridges.  But that would 
> > > > > be using it in a way that is not consistent with the intended
> > > > > use of 802.1ah - simply because that usage would make use of 
> > > > > the fields in a way that matches the way that your proposed 
> > > > > "short-hand" SHIM header would use them.
> > > > > 
> > > > > 	If you did that, there would be room for using the B-tag
> > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags.
> > > > > 
> > > > > 	I think this is a VERY BAD idea.
> > > > > 
> > > > > --
> > > > > Eric
> > > > <snip>
> > > > 
> > > 
> > 
> 

Date: Thu, 14 Dec 2006 07:33:57 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Gray, Eric" <[email-masked]>, Don Fedyk <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 7515

Just a side comment.
I think the ongoing discussion is not about encapsulation but about the  
fundamentals of RBridges approach versus 802.1ah's. So, while agreeing 
on the great  sinergies of a common encapsulation, lack of TTL is an 
essential point that reflects the essential difference in the deployment 
fields assumed.
If we assume a deployment field as for 802.1ah, encapsulations and 
proposals much simpler than 802.1ah are possible (one is described in my 
ABridges draft). If this is the case we should restart WG discussion 
from the beguinning.
 Encapsulation for RBridges is not simple, and 802.1ah isn't simple 
either, specially considering the campus networks of moderate sizes that 
are the target for RBridges.
Guillermo

Gray, Eric escribi?:
> Don,
>
> 	I think you've garbled the discussion, somewhat.
>
> 	Please see below...
>
> --
> Eric 
>
>   
>> -----Original Message-----
>> From: Don Fedyk [mailto:[email-masked]] 
>> Sent: Wednesday, December 13, 2006 1:19 PM
>> To: Gray, Eric
>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
>> Sajassi (sajassi); Silvano Gai
>> Subject: RE: [rbridge] Use of 802.1ah Encaps
>>
>> Hi Eric 
>>
>>     
>>> -----Original Message-----
>>> From: Gray, Eric [mailto:[email-masked]] 
>>>
>>> Don,
>>>
>>> 	I don't follow your reasoning.
>>>       
>> That's OK I cant follow you sometimes either ;-)
>>
>>     
>>> 	I certainly am not saying that using "ANY standard header"
>>> is a bad idea.
>>>       
>> Then why not start from ah?  The bit that Silvano said was we 
>> could use ah and you said it is a bad idea.  
>>     
>
> I don't think I am quoting too much out of context, when I quote
> the following from Silvano's reply to Joe Touch:
>
> SILVANO > My comment is that IEEE 802.1ah has no space for both 
> SILVANO > the ultimate source/dest and the next hop source/dest.
>
> SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
> SILVANO > share a common metro backbone. It does a fine job in 
> SILVANO > that area. It does not support well an arbitrary 
> SILVANO > intermixing of Bridges and Rbridges.
>
> SILVANO > In contrast Trill does a fine job in supporting 
> SILVANO > arbitrary topologies and mixing of RBridges and 
> SILVANO > Bridges thanks to the availability of both the
> SILVANO > ultimate source/dest and the next hop source/dest.
>
> SILVANO > In TRILL the network between the "ingress" and 
> SILVANO > "egress" RBridge isn't a single Ethernet (like in 
> SILVANO > 802.1ah), but rather a sequence of RBridges that 
> SILVANO > may be connected by Ethernets.
>
> SILVANO > Things look similar, but are substantially different.
>
> Given that this is what (I believe, at least) Silvano said 
> about using 802.1ah, where do you get the impression that 
> Silvano has said that "we could use ah"?
>
>   
>> Please describe "BAD idea" then.
>>     
>
> In this, I think quite a few of us are now in agreement.
>
> It is rarely a good idea to use a header format just because
> most of the bits look similar to one proposal that has all
> of the information you require.
>
> Suppose you started to think that using 802.1ah - because it 
> is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
> - was an example of one of the rare instances in which this 
> might be a good idea.  Wouldn't you suspect that the need to 
> consider potentially adding a TTL field to the header might 
> be an indication that you are probably wrong?
>
> So, to answer your question, a "BAD idea" is one that takes
> valuable resources to explore and offers no believable cause
> to suspect that it will work better than other ideas already
> on the table.
>
> In this case, we have reason to believe (MAC+SHIM)-in-MAC
> will work and no reason to believe that 802.1ah will work 
> better - even assuming we went down that rat-hole.
>  
>   
>>> 	As for "creating a new forwarding paradigm" - yes, we're
>>> doing a little bit of that.  Ideally, we'll be doing as little
>>> of that as we can get away with.  The "little bit" we have to
>>> do is to use some additional header information to:
>>>
>>> 	1) forward frames on the shortest path between RBridges,
>>> 	   and
>>> 	2) reduce or eliminate potential looping of frames during
>>> 	   a perturbation of the shortest path.
>>>       
>> You have so far chosen to do this in a mode that optimizes for mixed
>> bridges at the cost of ignoring the effciencies you could get between
>> directly connected Rbridges. 802.1ah opimizes forwarding for connected
>> Provider Backbone Bridges and interworks with legacy at a common
>> denominator. 
>>     
>
> Right, and 802.1ah assumes either a green-field deployment, or a 
> firmware modifiable deployment of PBB-(enabled/compatible) bridges.
>
> This is not consistent with our goals.
>  
>   
>>> This may be somewhat of a simplification, but that's fair in 
>>> light of the general trend for casual observers to do the
>>> opposite.
>>>
>>> 	Currently, we define a SHIM to carry this information and 
>>> we expect to use one or more "standard headers" to encapsulate
>>> frames being forwarded between RBridges.
>>>
>>> 	Does this make things clearer?
>>>       
>> Eric I understand what is proposed but I still question if a greater
>> synergy cannot be achieved between encapsulating headers.  A shim is a
>> not a typical solution but encapsulations are.
>>     
>
> Greater synergy is always demonstrably possible if you're willing
> to wait long enough.
>
> That's - for example - why we only have one link-state routing 
> protocol, and why Ethernet was the one and only MAC-like format
> for L2 frames ever to have been used.
>
> What planet are we on?  :-)
>
>   
>> Regards,
>> Don   
>>
>>
>>     
>>> --
>>> Eric
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Don Fedyk [mailto:[email-masked]] 
>>>> Sent: Wednesday, December 13, 2006 12:18 PM
>>>> To: Gray, Eric; Silvano Gai
>>>> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
>>>> Sajassi (sajassi)
>>>> Subject: RE: [rbridge] Use of 802.1ah Encaps
>>>>
>>>> Hi Eric
>>>>
>>>> This argument says if you use ANY standard header then it 
>>>>         
>>> would be a bad
>>>       
>>>> idea.
>>>>
>>>> So you are creating a new forwarding paradigm and the down 
>>>>         
>>> side of that
>>>       
>>>> as Ali pointed out is now you have to create most of the 
>>>>         
>>> other things
>>>       
>>>> that go along with new forwarding paradigm.  
>>>>
>>>> Don  
>>>>
>>>>         
>>>>> -----Original Message-----
>>>>> From: Gray, Eric [mailto:[email-masked]] 
>>>>> Sent: Tuesday, December 12, 2006 4:29 PM
>>>>>
>>>>> Silvano,
>>>>>
>>>>> 	IFF we were going to use 802.1ah, it could allow us to  
>>>>> use the "back-bone" DA/SA for next-hop/previous-hop and the
>>>>> "customer" DA/SA for egress/ingress RBridges.  But that would 
>>>>> be using it in a way that is not consistent with the intended
>>>>> use of 802.1ah - simply because that usage would make use of 
>>>>> the fields in a way that matches the way that your proposed 
>>>>> "short-hand" SHIM header would use them.
>>>>>
>>>>> 	If you did that, there would be room for using the B-tag
>>>>> and I-tag as analogues of your I-VLAN and O-VLAN tags.
>>>>>
>>>>> 	I think this is a VERY BAD idea.
>>>>>
>>>>> --
>>>>> Eric
>>>>>           
>>>> <snip>
>>>>
>>>>         
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>
Date: Wed, 13 Dec 2006 19:00:39 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 6316

Don,

	I think you've garbled the discussion, somewhat.

	Please see below...

--
Eric 

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 1:19 PM
> To: Gray, Eric
> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> Sajassi (sajassi); Silvano Gai
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Hi Eric 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > 
> > Don,
> > 
> > 	I don't follow your reasoning.
> That's OK I cant follow you sometimes either ;-)
> 
> > 
> > 	I certainly am not saying that using "ANY standard header"
> > is a bad idea.
> Then why not start from ah?  The bit that Silvano said was we 
> could use ah and you said it is a bad idea.  

I don't think I am quoting too much out of context, when I quote
the following from Silvano's reply to Joe Touch:

SILVANO > My comment is that IEEE 802.1ah has no space for both 
SILVANO > the ultimate source/dest and the next hop source/dest.

SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
SILVANO > share a common metro backbone. It does a fine job in 
SILVANO > that area. It does not support well an arbitrary 
SILVANO > intermixing of Bridges and Rbridges.

SILVANO > In contrast Trill does a fine job in supporting 
SILVANO > arbitrary topologies and mixing of RBridges and 
SILVANO > Bridges thanks to the availability of both the
SILVANO > ultimate source/dest and the next hop source/dest.

SILVANO > In TRILL the network between the "ingress" and 
SILVANO > "egress" RBridge isn't a single Ethernet (like in 
SILVANO > 802.1ah), but rather a sequence of RBridges that 
SILVANO > may be connected by Ethernets.

SILVANO > Things look similar, but are substantially different.

Given that this is what (I believe, at least) Silvano said 
about using 802.1ah, where do you get the impression that 
Silvano has said that "we could use ah"?

> 
> Please describe "BAD idea" then.

In this, I think quite a few of us are now in agreement.

It is rarely a good idea to use a header format just because
most of the bits look similar to one proposal that has all
of the information you require.

Suppose you started to think that using 802.1ah - because it 
is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
- was an example of one of the rare instances in which this 
might be a good idea.  Wouldn't you suspect that the need to 
consider potentially adding a TTL field to the header might 
be an indication that you are probably wrong?

So, to answer your question, a "BAD idea" is one that takes
valuable resources to explore and offers no believable cause
to suspect that it will work better than other ideas already
on the table.

In this case, we have reason to believe (MAC+SHIM)-in-MAC
will work and no reason to believe that 802.1ah will work 
better - even assuming we went down that rat-hole.
 
> 
> > 
> > 	As for "creating a new forwarding paradigm" - yes, we're
> > doing a little bit of that.  Ideally, we'll be doing as little
> > of that as we can get away with.  The "little bit" we have to
> > do is to use some additional header information to:
> > 
> > 	1) forward frames on the shortest path between RBridges,
> > 	   and
> > 	2) reduce or eliminate potential looping of frames during
> > 	   a perturbation of the shortest path.
> 
> You have so far chosen to do this in a mode that optimizes for mixed
> bridges at the cost of ignoring the effciencies you could get between
> directly connected Rbridges. 802.1ah opimizes forwarding for connected
> Provider Backbone Bridges and interworks with legacy at a common
> denominator. 

Right, and 802.1ah assumes either a green-field deployment, or a 
firmware modifiable deployment of PBB-(enabled/compatible) bridges.

This is not consistent with our goals.
 
> 
> > 
> > This may be somewhat of a simplification, but that's fair in 
> > light of the general trend for casual observers to do the
> > opposite.
> > 
> > 	Currently, we define a SHIM to carry this information and 
> > we expect to use one or more "standard headers" to encapsulate
> > frames being forwarded between RBridges.
> > 
> > 	Does this make things clearer?
> 
> Eric I understand what is proposed but I still question if a greater
> synergy cannot be achieved between encapsulating headers.  A shim is a
> not a typical solution but encapsulations are.

Greater synergy is always demonstrably possible if you're willing
to wait long enough.

That's - for example - why we only have one link-state routing 
protocol, and why Ethernet was the one and only MAC-like format
for L2 frames ever to have been used.

What planet are we on?  :-)

> 
> Regards,
> Don   
> 
> 
> > 
> > --
> > Eric
> > 
> > > -----Original Message-----
> > > From: Don Fedyk [mailto:[email-masked]] 
> > > Sent: Wednesday, December 13, 2006 12:18 PM
> > > To: Gray, Eric; Silvano Gai
> > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > > Sajassi (sajassi)
> > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > 
> > > Hi Eric
> > > 
> > > This argument says if you use ANY standard header then it 
> > would be a bad
> > > idea.
> > > 
> > > So you are creating a new forwarding paradigm and the down 
> > side of that
> > > as Ali pointed out is now you have to create most of the 
> > other things
> > > that go along with new forwarding paradigm.  
> > > 
> > > Don  
> > > 
> > > > -----Original Message-----
> > > > From: Gray, Eric [mailto:[email-masked]] 
> > > > Sent: Tuesday, December 12, 2006 4:29 PM
> > > > 
> > > > Silvano,
> > > > 
> > > > 	IFF we were going to use 802.1ah, it could allow us to  
> > > > use the "back-bone" DA/SA for next-hop/previous-hop and the
> > > > "customer" DA/SA for egress/ingress RBridges.  But that would 
> > > > be using it in a way that is not consistent with the intended
> > > > use of 802.1ah - simply because that usage would make use of 
> > > > the fields in a way that matches the way that your proposed 
> > > > "short-hand" SHIM header would use them.
> > > > 
> > > > 	If you did that, there would be room for using the B-tag
> > > > and I-tag as analogues of your I-VLAN and O-VLAN tags.
> > > > 
> > > > 	I think this is a VERY BAD idea.
> > > > 
> > > > --
> > > > Eric
> > > <snip>
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 13 Dec 2006 13:19:23 -0500
From: "Don Fedyk" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3175

Hi Eric 

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> 
> Don,
> 
> 	I don't follow your reasoning.
That's OK I cant follow you sometimes either ;-)

> 
> 	I certainly am not saying that using "ANY standard header"
> is a bad idea.
Then why not start from ah?  The bit that Silvano said was we could use
ah and you said it is a bad idea.  

Please describe "BAD idea" then. 

> 
> 	As for "creating a new forwarding paradigm" - yes, we're
> doing a little bit of that.  Ideally, we'll be doing as little
> of that as we can get away with.  The "little bit" we have to
> do is to use some additional header information to:
> 
> 	1) forward frames on the shortest path between RBridges,
> 	   and
> 	2) reduce or eliminate potential looping of frames during
> 	   a perturbation of the shortest path.

You have so far chosen to do this in a mode that optimizes for mixed
bridges at the cost of ignoring the effciencies you could get between
directly connected Rbridges. 802.1ah opimizes forwarding for connected
Provider Backbone Bridges and interworks with legacy at a common
denominator.  

> 
> This may be somewhat of a simplification, but that's fair in 
> light of the general trend for casual observers to do the
> opposite.
> 
> 	Currently, we define a SHIM to carry this information and 
> we expect to use one or more "standard headers" to encapsulate
> frames being forwarded between RBridges.
> 
> 	Does this make things clearer?

Eric I understand what is proposed but I still question if a greater
synergy cannot be achieved between encapsulating headers.  A shim is a
not a typical solution but encapsulations are.

Regards,
Don   

> 
> --
> Eric
> 
> > -----Original Message-----
> > From: Don Fedyk [mailto:[email-masked]] 
> > Sent: Wednesday, December 13, 2006 12:18 PM
> > To: Gray, Eric; Silvano Gai
> > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > Sajassi (sajassi)
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > Hi Eric
> > 
> > This argument says if you use ANY standard header then it 
> would be a bad
> > idea.
> > 
> > So you are creating a new forwarding paradigm and the down 
> side of that
> > as Ali pointed out is now you have to create most of the 
> other things
> > that go along with new forwarding paradigm.  
> > 
> > Don  
> > 
> > > -----Original Message-----
> > > From: Gray, Eric [mailto:[email-masked]] 
> > > Sent: Tuesday, December 12, 2006 4:29 PM
> > > 
> > > Silvano,
> > > 
> > > 	IFF we were going to use 802.1ah, it could allow us to  
> > > use the "back-bone" DA/SA for next-hop/previous-hop and the
> > > "customer" DA/SA for egress/ingress RBridges.  But that would 
> > > be using it in a way that is not consistent with the intended
> > > use of 802.1ah - simply because that usage would make use of 
> > > the fields in a way that matches the way that your proposed 
> > > "short-hand" SHIM header would use them.
> > > 
> > > 	If you did that, there would be room for using the B-tag
> > > and I-tag as analogues of your I-VLAN and O-VLAN tags.
> > > 
> > > 	I think this is a VERY BAD idea.
> > > 
> > > --
> > > Eric
> > <snip>
> > 
> 

From: "Gustavo J. A. M. Carneiro" <[email-masked]>
To: Joe Touch <[email-masked]>
Organization: INESC Porto
Date: Wed, 13 Dec 2006 17:57:03 +0000
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] IP data plane (Was: Use of 802.1ah Encaps)
Status: RO
Content-Length: 1358

On Qua, 2006-12-13 at 09:14 -0800, Joe Touch wrote:
> 
> Gustavo J. A. M. Carneiro wrote:
> >   Hello,
> > 
> >   Sorry to intrude, I just wanted to play devil's advocate here.. ;-)
> > 
> > On Ter, 2006-12-12 at 16:51 -0500, Gray, Eric wrote:
> >> Joe,
> >>
> >> 	It's a huge drawback, and it requires configuration of
> >> at least IP addresses - possibly per-interface.  That is not
> >> going to work very well as a plug-and-play solution.
> > 
> >   An IP based data plane does not imply that you need configuration, not
> > even IP addresses on interfaces.  Think of IP adhoc protocols
> > (AODV/OLSR/etc.); they derive IP addresses from the L2 MAC address, or
> > simply generate a random IP.
> 
> That works only if there is NO other IP traffic on that plane. We don't
> know that rbridges will talk to each other over dedicated paths that
> don't involve non-rbridge to non-rbridge traffic.
> 
> In that case, the IP addresses sent on certain link addresses - notably
> multicast and broadcast - could interfere between rbridge use of those
> addresses and non-rbridge use of those addresses.

  Also not a problem: RBridges could use an IP data plane, but using a
different EtherType, different from the usual 0x0800.

-- 
Gustavo J. A. M. Carneiro
<[email-masked]> <[email-masked]>
The universe is always one step beyond logic.

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>
Date: Wed, 13 Dec 2006 12:29:10 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2232

Don,

	I don't follow your reasoning.

	I certainly am not saying that using "ANY standard header"
is a bad idea.

	As for "creating a new forwarding paradigm" - yes, we're
doing a little bit of that.  Ideally, we'll be doing as little
of that as we can get away with.  The "little bit" we have to
do is to use some additional header information to:

	1) forward frames on the shortest path between RBridges,
	   and
	2) reduce or eliminate potential looping of frames during
	   a perturbation of the shortest path.

This may be somewhat of a simplification, but that's fair in 
light of the general trend for casual observers to do the
opposite.

	Currently, we define a SHIM to carry this information and 
we expect to use one or more "standard headers" to encapsulate
frames being forwarded between RBridges.

	Does this make things clearer?

--
Eric

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Wednesday, December 13, 2006 12:18 PM
> To: Gray, Eric; Silvano Gai
> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> Sajassi (sajassi)
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Hi Eric
> 
> This argument says if you use ANY standard header then it would be a bad
> idea.
> 
> So you are creating a new forwarding paradigm and the down side of that
> as Ali pointed out is now you have to create most of the other things
> that go along with new forwarding paradigm.  
> 
> Don  
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > Sent: Tuesday, December 12, 2006 4:29 PM
> > 
> > Silvano,
> > 
> > 	IFF we were going to use 802.1ah, it could allow us to  
> > use the "back-bone" DA/SA for next-hop/previous-hop and the
> > "customer" DA/SA for egress/ingress RBridges.  But that would 
> > be using it in a way that is not consistent with the intended
> > use of 802.1ah - simply because that usage would make use of 
> > the fields in a way that matches the way that your proposed 
> > "short-hand" SHIM header would use them.
> > 
> > 	If you did that, there would be room for using the B-tag
> > and I-tag as analogues of your I-VLAN and O-VLAN tags.
> > 
> > 	I think this is a VERY BAD idea.
> > 
> > --
> > Eric
> <snip>
> 

Content-class: urn:content-classes:message
Date: Wed, 13 Dec 2006 12:18:08 -0500
From: "Don Fedyk" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1028

Hi Eric

This argument says if you use ANY standard header then it would be a bad
idea.

So you are creating a new forwarding paradigm and the down side of that
as Ali pointed out is now you have to create most of the other things
that go along with new forwarding paradigm.  

Don  

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Tuesday, December 12, 2006 4:29 PM
> 
> Silvano,
> 
> 	IFF we were going to use 802.1ah, it could allow us to  
> use the "back-bone" DA/SA for next-hop/previous-hop and the
> "customer" DA/SA for egress/ingress RBridges.  But that would 
> be using it in a way that is not consistent with the intended
> use of 802.1ah - simply because that usage would make use of 
> the fields in a way that matches the way that your proposed 
> "short-hand" SHIM header would use them.
> 
> 	If you did that, there would be room for using the B-tag
> and I-tag as analogues of your I-VLAN and O-VLAN tags.
> 
> 	I think this is a VERY BAD idea.
> 
> --
> Eric
<snip>

Date: Wed, 13 Dec 2006 09:14:53 -0800
From: Joe Touch <[email-masked]>
To: "Gustavo J. A. M. Carneiro" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] IP data plane (Was: Use of 802.1ah Encaps)
Status: RO
Content-Length: 1815

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig80454ED9355D9E5D8CED719C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Gustavo J. A. M. Carneiro wrote:
>   Hello,
>=20
>   Sorry to intrude, I just wanted to play devil's advocate here.. ;-)
>=20
> On Ter, 2006-12-12 at 16:51 -0500, Gray, Eric wrote:
>> Joe,
>>
>> 	It's a huge drawback, and it requires configuration of
>> at least IP addresses - possibly per-interface.  That is not
>> going to work very well as a plug-and-play solution.
>=20
>   An IP based data plane does not imply that you need configuration, no=
t
> even IP addresses on interfaces.  Think of IP adhoc protocols
> (AODV/OLSR/etc.); they derive IP addresses from the L2 MAC address, or
> simply generate a random IP.

That works only if there is NO other IP traffic on that plane. We don't
know that rbridges will talk to each other over dedicated paths that
don't involve non-rbridge to non-rbridge traffic.

In that case, the IP addresses sent on certain link addresses - notably
multicast and broadcast - could interfere between rbridge use of those
addresses and non-rbridge use of those addresses.

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

--------------enig80454ED9355D9E5D8CED719C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig80454ED9355D9E5D8CED719C--

From: "Gustavo J. A. M. Carneiro" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Organization: INESC Porto
Date: Wed, 13 Dec 2006 16:34:48 +0000
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] IP data plane (Was: Use of 802.1ah Encaps)
Status: RO
Content-Length: 1452

  Hello,

  Sorry to intrude, I just wanted to play devil's advocate here.. ;-)

On Ter, 2006-12-12 at 16:51 -0500, Gray, Eric wrote:
> Joe,
> 
> 	It's a huge drawback, and it requires configuration of
> at least IP addresses - possibly per-interface.  That is not
> going to work very well as a plug-and-play solution.

  An IP based data plane does not imply that you need configuration, not
even IP addresses on interfaces.  Think of IP adhoc protocols
(AODV/OLSR/etc.); they derive IP addresses from the L2 MAC address, or
simply generate a random IP.

> 	In addition, as you hint at, you're effectively now a
> part of the routing L3 network - as opposed to part of the 
> bridging L2 network.  It would make little sense - at that
> point - to try to differentiate RBridges from routers as it
> is already established that routers can be built and used 
> in real networks.

  There is still some advantage: normal routers need configuration,
RBridges don't.  But at the same time you can reuse existing IP
forwarding blocks of routers.

  But if you are really looking for arguments against IP data plane:
   1. Larger header size;
   2. Larger (32-bits) addresses (vs. 16-bits of rbridge nick names);
   3. Obfuscation, e.g. some fields are there but not used by RBridges
(like fragmentation control).

  Regards,

-- 
Gustavo J. A. M. Carneiro
<[email-masked]> <[email-masked]>
The universe is always one step beyond logic.

From: "Gray, Eric" <[email-masked]>
To: Joe Touch <[email-masked]>
Date: Tue, 12 Dec 2006 16:51:37 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1790

Joe,

	It's a huge drawback, and it requires configuration of
at least IP addresses - possibly per-interface.  That is not
going to work very well as a plug-and-play solution.

	In addition, as you hint at, you're effectively now a
part of the routing L3 network - as opposed to part of the 
bridging L2 network.  It would make little sense - at that
point - to try to differentiate RBridges from routers as it
is already established that routers can be built and used 
in real networks.

	If you're building a box that acts like a router, then
build a router.  Nothing much for us to do in that case.

--
Eric

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, December 12, 2006 12:10 PM
> To: Ali Sajassi (sajassi)
> Cc: Silvano Gai; [email-masked]; Don Fedyk; Gray, 
> Eric; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> 
> 
> Ali Sajassi (sajassi) wrote:
> >...
> >> Can you please describe the header you're considering an 
> >> alternative, e.g, where the current one is:
> >> 	[outer ether [6-byte shim] [inner ether [payload]]]
> > 
> > 	[outer ether][20-byte IP header][4 or 8 byte L2TPv3/GRE shim]
> > [inner Ether [payload]]
> > 
> > The draw back is the additional 20 bytes of IP header but 
> the advantage
> > is that you can use the IGP as is :-)
> 
> That's a fairly large drawback.
> 
> Also, how might this affect an IP protocol running on links over which
> rbridge nodes communicate? I.e., don't you have to de-conflict the IP
> addresses and possibly also the IGP to avoid interference 
> between the two?
> 
> Our system has a shim just inside the outer ether, i.e., using a
> different ethertype; that effectively forces non-rbridge systems to
> ignore the packets.
> 
> Joe
> 
> 

From: "Gray, Eric" <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>, [email-masked]
Date: Tue, 12 Dec 2006 16:37:59 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 8394

Ali,

	I agree with your argument below in every sense. But 
I fail to see why that argument leads to a recommendation 
to use 802.1ah encapsulation.

	We were initially expecting to use 802.3 Ethernet
encapsulation of a SHIM-encapsulated, tunneled Ethernet
frame.  That is a use of IEEE-conformant frame formats.

--
Eric

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Sunday, December 10, 2006 6:07 PM
> To: [email-masked]
> Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid 
> router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > Sent: Thursday, December 07, 2006 9:56 PM
> > To: Ali Sajassi (sajassi)
> > Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid 
> > router/bridge.; Joe Touch
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > 
> > Travelling again, so extremely limited access to email (as 
> > in, about 10 minutes here and there on a SLOW connection).  
> > Anyway, I'll answer some of these:
> 
> Also sorry for not being able to respond to your email 
> earlier due to my
> schedule/meetings (specially on Friday).
> 
> > 
> > a) why "next hop" and "previous hop" in addition to 
> > "ultimate" source and destination
> > 
> > At least one of the reasons is that if there are three 
> > RBridges on the same link, R1, R2, and R3, it is useful for 
> > R1 to choose which of R2 or R3 should receive the packet. It 
> > isn't obvious from the destination address because it could 
> > be that either R2 or R3 would be logical, and R1 is load 
> > splitting. Also, it helps focus traffic on the link, and 
> > ensure it doesn't get filtered, if the bridges on the link 
> > only need to learn R1, R2, and R3, especially since traffic 
> > from outside RBridges might arrive from different entry 
> > points onto the link.
> 
> O.K., I remember now the discussion that we had during the 
> IETF meeting
> on load balancing and next hop address. However, there are couple of
> ways for achieving the same result. I mentioned briefly during the
> meeting the use of VLAN for this purpose and someone else mentioned
> using part of 48-bit provider MAC address for this purpose.
> 
> > 
> > b) congestion management was explained to us, and it was what 
> > convinced us we needed "ultimate source RBridge" in order to 
> > know where to send the congestion notification. If you could 
> > explain the other things, we could see if there is a problem, 
> > but if they are similar to congestion notification, then 
> > having the ingress RBridge will accommodate them.
> > 
> 
> With respect to CFM, connectivity fault mgmt is done in a hierarchical
> way and it can be performed at the provider service instance level
> (e.g., on a per I-SID basis) or it can be performed for group 
> of I-SIDs
> on a per B-VLAN level. In both cases, provider MAC addresses are used
> which makes the provider OAM control for customer data-traffic very
> tight. You cannot get the same result by using OAM messages that use
> customer MAC addresses and if you try to do it will be very 
> cumbersome.
> 
> Basically what I am trying to point out is that by using non-IEEE
> conformance frame format, you assume the responsibility for all the
> features developed by IEEE; where as, if you use IEEE 
> conformant frame,
> then one can concentrate on the control plane issues which I 
> thought was
> the main objective of TRILL.
> 
> -Ali 
> 
> > Sorry for ignoring all the other messages for now, but I only 
> > had a chance to read and respond to one message.
> > 
> > Radia
> > 
> > ----- Original Message -----
> > From: "Ali Sajassi (sajassi)" <[email-masked]>
> > Date: Friday, December 8, 2006 10:53 am
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > 
> > > 
> > > Silvano,
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [[email-masked]]
> > > > Sent: Thursday, December 07, 2006 5:36 PM
> > > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> > > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > > 
> > > > 
> > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. 
> > > > There are advantages and disadvantages.
> > > > 
> > > > The disadvantages are:
> > > > 1) Lack of Next-Hop addresses. We discussed this at 
> length during 
> > > > the last meeting and we didn't reach consensus on a way 
> > to eliminate 
> > > > them.
> > > 
> > > Can you refresh my memory for why we need a next-hop 
> > address when the 
> > > header carries both source and destination PE addresses and 
> > when these 
> > > addresses are learned in control plane ?
> > > 
> > > > 2) Lack of a TTL field (it may be added, but it is not 
> > there today).
> > > 
> > > Can probably be accommodated.
> > > 
> > > > 3) Many unneeded fields and therefore larger frame overhead.
> > > > 
> > > 
> > > Such as ?
> > > 
> > > > The advantages are:
> > > > 1) Larger addressable market for TRILL
> > > > 
> > > > IMO if we stick with the WG charter the disadvantages clearly 
> > > > outweigh the advantages.
> > > > 
> > > > The WG can be re-chartered, but if we consider the 
> Enterprise and 
> > > > Data Center market, IEEE 802.1ah is an overkill.
> > > > 
> > > 
> > > If by overkill you mean a bit bigger header, then I agree 
> > but look at 
> > > all the other advantages that you get from using standard 
> > IEEE header 
> > > and shim including:
> > > 	- security Mgmt:  MACSec/KeySec 
> > > 	- Congestion Mgmt 
> > > 	- Connectivity Fault Mgmt
> > > 
> > > Has it been considered how these are going to work with 
> TRILL shim 
> > > header or are these outside of WG charter :-)
> > > 
> > > -Ali
> > > 
> > > 
> > > > -- Silvano
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: [email-masked] [[email-masked]]
> > > > On
> > > > > Behalf Of Don Fedyk
> > > > > Sent: Thursday, December 07, 2006 9:21 AM
> > > > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > > > 
> > > > > Hi Eric
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Gray, Eric [[email-masked]]
> > > > > >
> > > > > > Don,
> > > > > >
> > > > > > 	And yet, someone (Ali Sajassi) asserted (in his message
> > > > dated Wed
> > > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or
> > > additional
> > > > > > complications with using 802.1ah in enterprises for 
> plug-and-
> > > play
> > > > > > applicability.
> > > > > >
> > > > > > 	Perhaps Ali can answer my question then.
> > > > > >
> > > > > > 	But, to more directly address your earlier comments:
> > > > > >
> > > > > > 	The TRILL WG has NOT come up with an encapsulation that
> > > "looks
> > > > > > like" 802.1ah - unless someone squints really hard and tries
> > > to
> > > > > > pretend that two separate Ethernet encapsulations -
> > > > separated by a
> > > > > > SHIM header - are one single encapsulation.
> > > > > 
> > > > > To be fair Point to Point header that was discussed without
> > > > one of the
> > > > > shims was very close "functionally" (colloquial looks like) to
> > > > 802.1ah.
> > > > > My opinion is still we don't need several variations of
> > > > headers doing
> > > > > similar things.
> > > > > 
> > > > > This was the slide that looked a lot like what I posted.
> > > > > 
> > > > > 
> http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > > > > 
> > > > > Regards,
> > > > > Don
> > > > > >
> > > > > > 	That is not to say that the WG has done anything that
> > > > could be said
> > > > > > to disallow the use of 802.1ah encapsulation.
> > > > > > It is just not obviously consistent with all of the WG
> > > > goals to use
> > > > > > _only_ 802.1ah encapsulation.
> > > > > >
> > > > > > --
> > > > > > Eric
> > > > > >
> > > > > 
> > > > > _______________________________________________
> > > > > rbridge mailing list
> > > > > [email-masked]
> > > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > > 
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > 
> 

From: "Gray, Eric" <[email-masked]>
To: Silvano Gai <[email-masked]>
Date: Tue, 12 Dec 2006 16:29:19 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 5340

Silvano,

	IFF we were going to use 802.1ah, it could allow us to  
use the "back-bone" DA/SA for next-hop/previous-hop and the
"customer" DA/SA for egress/ingress RBridges.  But that would 
be using it in a way that is not consistent with the intended
use of 802.1ah - simply because that usage would make use of 
the fields in a way that matches the way that your proposed 
"short-hand" SHIM header would use them.

	If you did that, there would be room for using the B-tag
and I-tag as analogues of your I-VLAN and O-VLAN tags.

	I think this is a VERY BAD idea.

--
Eric

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Friday, December 08, 2006 10:07 AM
> To: Ali Sajassi (sajassi); Don Fedyk; Gray, Eric
> Cc: Developing a hybrid router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Ali,
> 
> Inline:
> 
> > -----Original Message-----
> > From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> > Sent: Thursday, December 07, 2006 9:23 PM
> > To: Silvano Gai; Don Fedyk; Gray, Eric
> > Cc: Developing a hybrid router/bridge.; Joe Touch
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > 
> > Silvano,
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [mailto:[email-masked]]
> > > Sent: Thursday, December 07, 2006 5:36 PM
> > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > >
> > >
> > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah.
> > > There are advantages and disadvantages.
> > >
> > > The disadvantages are:
> > > 1) Lack of Next-Hop addresses. We discussed this at length
> > > during the last meeting and we didn't reach consensus on a
> > > way to eliminate them.
> > 
> > Can you refresh my memory for why we need a next-hop 
> address when the
> > header carries both source and destination PE addresses and 
> when these
> > addresses are learned in control plane ?
> > 
> 
> Radia did in her reply
> 
> > > 2) Lack of a TTL field (it may be added, but it is not 
> there today).
> > 
> > Can probably be accommodated.
> > 
> > > 3) Many unneeded fields and therefore larger frame overhead.
> > >
> > 
> > Such as ?
> 
> The I-tag is not useful in TRILL and in contrast two addresses and the
> TTL are missing.
> 
> > 
> > > The advantages are:
> > > 1) Larger addressable market for TRILL
> > >
> > > IMO if we stick with the WG charter the disadvantages clearly
> > > outweigh the advantages.
> > >
> > > The WG can be re-chartered, but if we consider the Enterprise
> > > and Data Center market, IEEE 802.1ah is an overkill.
> > >
> > 
> > If by overkill you mean a bit bigger header, then I agree 
> but look at
> > all the other advantages that you get from using standard 
> IEEE header
> > and shim including:
> > 	- security Mgmt:  MACSec/KeySec
> > 	- Congestion Mgmt
> > 	- Connectivity Fault Mgmt
> > 
> > Has it been considered how these are going to work with TRILL shim
> > header or are these outside of WG charter :-)
> > 
> > -Ali
> > 
> > 
> > > -- Silvano
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> [mailto:[email-masked]]
> > > On
> > > > Behalf Of Don Fedyk
> > > > Sent: Thursday, December 07, 2006 9:21 AM
> > > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > >
> > > > Hi Eric
> > > >
> > > > > -----Original Message-----
> > > > > From: Gray, Eric [mailto:[email-masked]]
> > > > >
> > > > > Don,
> > > > >
> > > > > 	And yet, someone (Ali Sajassi) asserted (in his message
> > > dated Wed
> > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or
> additional
> > > > > complications with using 802.1ah in enterprises for
> plug-and-play
> > > > > applicability.
> > > > >
> > > > > 	Perhaps Ali can answer my question then.
> > > > >
> > > > > 	But, to more directly address your earlier comments:
> > > > >
> > > > > 	The TRILL WG has NOT come up with an encapsulation that
> "looks
> > > > > like" 802.1ah - unless someone squints really hard 
> and tries to
> > > > > pretend that two separate Ethernet encapsulations -
> > > separated by a
> > > > > SHIM header - are one single encapsulation.
> > > >
> > > > To be fair Point to Point header that was discussed without
> > > one of the
> > > > shims was very close "functionally" (colloquial looks like) to
> > > 802.1ah.
> > > > My opinion is still we don't need several variations of
> > > headers doing
> > > > similar things.
> > > >
> > > > This was the slide that looked a lot like what I posted.
> > > >
> > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > > >
> > > > Regards,
> > > > Don
> > > > >
> > > > > 	That is not to say that the WG has done anything that
> > > could be said
> > > > > to disallow the use of 802.1ah encapsulation.
> > > > > It is just not obviously consistent with all of the WG
> > > goals to use
> > > > > _only_ 802.1ah encapsulation.
> > > > >
> > > > > --
> > > > > Eric
> > > > >
> > > >
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [email-masked]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> 

From: "Gray, Eric" <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>, "Gray, Eric" <[email-masked]>, Don Fedyk <[email-masked]>
Date: Tue, 12 Dec 2006 16:17:51 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3062

Ali,

	Plug-and-play usually means configuration-free operation.

--
Eric 

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Friday, December 08, 2006 12:02 AM
> To: Gray, Eric; Don Fedyk
> Cc: Developing a hybrid router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Gray,
> 
> Please let me know if my previous email doesn't answer your 
> question and
> if it doesn't, then let me know which portion needs further
> clarification.
> 
> -Ali 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > Sent: Thursday, December 07, 2006 8:01 AM
> > To: Don Fedyk; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.; Joe Touch
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > Don,
> > 
> > 	And yet, someone (Ali Sajassi) asserted (in his message 
> > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues 
> > or additional complications with using 802.1ah in enterprises 
> > for plug-and-play applicability.
> > 
> > 	Perhaps Ali can answer my question then.
> > 
> > 	But, to more directly address your earlier comments:
> > 
> > 	The TRILL WG has NOT come up with an encapsulation that 
> > "looks like" 802.1ah - unless someone squints really hard and 
> > tries to pretend that two separate Ethernet encapsulations - 
> > separated by a SHIM header - are one single encapsulation.
> > 
> > 	That is not to say that the WG has done anything that 
> > could be said to disallow the use of 802.1ah encapsulation.
> > It is just not obviously consistent with all of the WG goals 
> > to use _only_ 802.1ah encapsulation.
> > 
> > --
> > Eric
> > 
> > > -----Original Message-----
> > > From: Don Fedyk [mailto:[email-masked]]
> > > Sent: Thursday, December 07, 2006 9:33 AM
> > > To: Gray, Eric; Joe Touch; Ali Sajassi (sajassi)
> > > Cc: Developing a hybrid router/bridge.
> > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > 
> > > Hi Eric
> > > 
> > > > -----Original Message-----
> > > > From: Gray, Eric [mailto:[email-masked]]
> > > > Sent: Thursday, December 07, 2006 8:38 AM Don,
> > > > 
> > > > 	Thanks for doing this.  As you can probably 
> attest, this is a 
> > > > non-trivial "digging" task to come up with this level of 
> > detail.  I 
> > > > am not sure why Joe asked for it, but now that you have 
> > provided it, 
> > > > perhaps you can explain how values would be derived for 
> the B-TAG 
> > > > TCI/VID and I-TAG TCI/SID fields if we'd like to deploy this 
> > > > technology in
> > > "plug-and-play" mode?
> > > 
> > > I have not given much thought to plug-and-play. My advice 
> would be 
> > > learn the current semantics of the fields and see what they 
> > offer.  I 
> > > don't see why these fields, which offer encapsulation, backwards 
> > > compatibility, Connectivity Fault Management (CFM) frames 
> > etc are any 
> > > worse than similar alternatives.
> > > 
> > > Don
> > > 
> > > > 
> > > > --
> > > > Eric
> > > > 
> > > ><snipped hopelessly garbled>
> > > 
> > 
> 

From: "Gray, Eric" <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 12 Dec 2006 16:16:47 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3877

Ali,

	No argument.  But this is what you do in a break-out or
interim meeting - not what you do in a working group meeting 
where the intention is to summarize results.  There are things
that were pointed out that we should consider.  There are also
other projects that are in the works.  There are incentives to
induce us toward a common solution.  And there is a time and a
place to go into the details, consider alternatives, etc. 

	The minute you have 10-20 people standing at a microphone
waiting for their turn to comment on the latest gyration (with
a change taking place as each person steps up to take his/her 
turn), you're designing in committee.  I think it's wrong (in
many ways) to treat anything suggested during that portion of 
the discussion as anything other than brain-storming.

	It seems obvious at this point that people have had some
time to think about the suggestions and eliminate many of them.
I have seen only one change that appears consistently to have
been agreed on over previous iterations of considering the use
of a SHIM header and that has been to include both the ingress
and egress RBridge "nick-names" in the SHIM.

	Other than for reasons of interoperability - which tends
to require us to agree on a minimal set of common encapsulations
that MUST be supported by all RBridges - it is actually only a
diversion for us to spend time in discussion of how we might
modify IEEE-defined encapsulations to support TRILL directly.

	It may be interesting and inspiring to talk about these
things, but does it help us to get the job done?

--
Eric

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 11:59 PM
> To: Gray, Eric; Joe Touch
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
>  
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > Sent: Thursday, December 07, 2006 5:48 AM
> > To: Joe Touch; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > Joe/Ali,
> > 
> > 	It is not as simple as this.
> > 
> > 	The IETF has already established a precedent for 
> > Ethernet encapsulation of SHIM-encapsulated Ethernet.  It's 
> > only trying to see this as a single encapsulation, that 
> > causes people to conclude we are inventing a new form of 
> > Ethernet encapsulation.
> > 
> > 	Other than inappropriate "designing committee" 
> > discussion at the last IETF meeting, we have not been 
> > attempting to design any new Ethernet encapsulation.  And I 
> > believe we should safely conclude, at this point, that the 
> > discussion that took place on this topic at the TRILL meeting 
> > last month can be closed and considered to have been 
> > completely unproductive.
> 
> 
> I think it is always good to have discussions among ourselves 
> to see how
> we can leverage each other expertise and technology and 
> whether what you
> are doing can be leveraged in other applications. The basic premise in
> here is that there is a good level of overlap among different 
> areas that
> are being worked on by different WGs, and we will do each 
> other as well
> as industry a great service if we can come up with a common solution
> jointly.
> 
> -Ali
> 
> > 
> > 	Big surprise...
> > 
> > --
> > Eric
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Joe Touch
> > > Sent: Wednesday, December 06, 2006 10:23 PM
> > > To: Ali Sajassi (sajassi)
> > > Cc: Developing a hybrid router/bridge.
> > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > 
> 

From: "Gray, Eric" <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 12 Dec 2006 15:59:11 -0500
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 7152

Ali,

	I am confused.  What does it mean to say "at the UNI
you decide ... [and] you also decide at the UNI ..." if it
does not mean that the network operator determines these
things a priori and configures the equipment accordingly.

	If there is a requirement for configuration - possibly
on an interface-by-interface basis - how is that plug and
play?

--
Eric

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 11:48 PM
> To: Gray, Eric; Don Fedyk; Joe Touch
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> 
> 
> Gray,
> 
> With respect to plug-and-play operation, it is similar to 802.1Q or
> 802.1ad operation; where, at the UNI you decide which interfaces belong
> to which VLANs in case of 802.1Q or which <interface, VLAN> pair belong
> to S-tag in case of 802.1ad (e.g., point-to-cloud config model). In case
> of 802.1ah, you also decide at the UNI which interfaces or which
> <interface, vlan> pair belong to which <B-tag, I-SID> pair. Again the
> model in 802.1ah is point-to-cloud model just like 802.1Q and 802.1ad
> and that's what makes it plug-and-play.
> 
> -Ali  
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > Sent: Thursday, December 07, 2006 5:38 AM
> > To: Don Fedyk; Joe Touch; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > Don,
> > 
> > 	Thanks for doing this.  As you can probably attest, 
> > this is a non-trivial "digging" task to come up with this 
> > level of detail.  I am not sure why Joe asked for it, but now 
> > that you have provided it, perhaps you can explain how values 
> > would be derived for the B-TAG TCI/VID and I-TAG TCI/SID 
> > fields if we'd like to deploy this technology in 
> "plug-and-play" mode?
> > 
> > --
> > Eric
> > 
> > > -----Original Message-----
> > > From: Don Fedyk [mailto:[email-masked]]
> > > Sent: Thursday, December 07, 2006 8:29 AM
> > > To: Joe Touch; Ali Sajassi (sajassi)
> > > Cc: Gray, Eric; Developing a hybrid router/bridge.
> > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > 
> > > Hi
> > > 
> > > This is the Provider Backbone Header Format reproduced from 
> > one of the 
> > > 802.1ah documents.  When I said this is similar to the 
> Trill header 
> > > this is the version I mentioned.  I converted to 
> > textographics by hand 
> > > so I hope I got it right. I put field designators in [] 
> inside the 
> > > picture for fear they would get wrapped. The encapsulated 
> > frame starts 
> > > after the I-TAG I-SID.
> > > 
> > >     
> > >     |      1        |       2       |       3       |       4 
> > >       |  
> > >     
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  -2 |                               |                       
> >         |
> > >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                       
> >         +
> > >   2 |                Backbone Destination Address         
> > [B-DA]    |
> > >     
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >   6 |                Backbone Source Address              
> > [B-SA]    |
> > >     +                               
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  10 |                               |   .1ad Ethertype    
> > [B-TAG]   |
> > >     
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >  14 |  .1ad B-TAG TCI/VID           |   .1ah Ethertype    [ 
> >   ]     |
> > >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ 
> > I ]-+-+-+
> > >  18 |               .1ah I-TAG TCI/SID                    [ 
> > - ]     |
> > >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ 
> > T ]-+-+-+
> > >  22 |                Customer Destination Address         [ 
> > A ]     |
> > >     +                               +-+-+-+-+-+-+-+-+-+-+-[ 
> > G ]-+-+-+
> > >  26 |                               |                     [ 
> >   ]     |
> > >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     [ 
> >   ]     +
> > >  30 |                Customer Source Address              [ 
> >   ]     |
> > >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ 
> >   ]-+-+-+
> > >  34 |  Encap Ethertype              |                     [   ]
> > >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > > 
> > >                                 .1ah I-TAG TCI
> > >     
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >     | P/DE  |R1 |R2 |                     I-SID             
> >         |
> > >     
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > 
> > >     P/DE 3 Bits Priority 1 bit Drop Eligible
> > >     R1 Res1
> > >     R2 Res2
> > > 
> > > a) priority - This 3 bit field carries the customer 
> > priority (I-PCP) 
> > > associated with this frame. The provider network operates on the 
> > > priority associated with the B-TAG.
> > > 
> > > b) drop_eligible - This 1 bit field carries the customer drop 
> > > eligibility
> > > (I-DEI) associated with this frame. The provider network 
> > operates on 
> > > the drop eligibility associated with the B-TAG.
> > > 
> > > c) res1 - This 2 bit field is used for any future format 
> > variations. 
> > > The
> > > res2
> > > field is zero on transmit and is ignored on receipt. 
> > > 
> > > d) res2 - This 2 bit field is used for any future format 
> > variations. 
> > > The
> > > res1
> > > field is zero on transmit and if set on reception the frame is 
> > > discarded.
> > > 
> > > e) I-SID - This 24 bit field carries the service instance 
> > identifier 
> > > associated with this frame.
> > > 
> > > f) encapsulated C-DA - This field carries the 48 bit 
> > Destination MAC 
> > > Address for an encapsulated Ethernet frame.
> > > 
> > > g) encapsulated C-SA - This field carries the 48 bit Source MAC 
> > > Address for an encapsulated Ethernet frame.
> > > 
> > > Regards,
> > > Don
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Joe Touch [mailto:[email-masked]]
> > > > Sent: Wednesday, December 06, 2006 9:53 PM
> > > > To: Ali Sajassi (sajassi)
> > > > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid 
> > > > router/bridge.
> > > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > > 
> > > > I'd really rather someone just posted the header / 
> fields, rather 
> > > > than a large document in which that information is buried, if 
> > > > possible ;-)
> > > > 
> > > > Joe
> > > > 
> > > > Ali Sajassi (sajassi) wrote:
> > > > > 
> > > > >> Can you - or anyone with easy access to the specs -
> > > please post an
> > > > >> explicit description of 802.1ah header and fields?
> > > > > 
> > > > > I will ask Tony (802.1 chair) to make avail to TRILL WG a
> > > > copy of .1ah.
> > > > > 
> > > > > -Ali
> > > > > 
> > > > > 
> > > > >> Thanks,
> > > > >>
> > > > >> Joe
> > > > >>
> > > > >>
> > > > 
> > > > --
> > > > ----------------------------------------
> > > > Joe Touch
> > > > Sr. Network Engineer, USAF TSAT Space Segment
> > > > 
> > > > 
> > > 
> > 
> 

Date: Tue, 12 Dec 2006 09:10:15 -0800
From: Joe Touch <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1532

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA31B8A635A2428A28DF6B246
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ali Sajassi (sajassi) wrote:
>...
>> Can you please describe the header you're considering an=20
>> alternative, e.g, where the current one is:
>> 	[outer ether [6-byte shim] [inner ether [payload]]]
>=20
> 	[outer ether][20-byte IP header][4 or 8 byte L2TPv3/GRE shim]
> [inner Ether [payload]]
>=20
> The draw back is the additional 20 bytes of IP header but the advantage=

> is that you can use the IGP as is :-)

That's a fairly large drawback.

Also, how might this affect an IP protocol running on links over which
rbridge nodes communicate? I.e., don't you have to de-conflict the IP
addresses and possibly also the IGP to avoid interference between the two=
?

Our system has a shim just inside the outer ether, i.e., using a
different ethertype; that effectively forces non-rbridge systems to
ignore the packets.

Joe

--------------enigA31B8A635A2428A28DF6B246
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigA31B8A635A2428A28DF6B246--

Content-class: urn:content-classes:message
Date: Mon, 11 Dec 2006 07:19:04 -0800
From: "Silvano Gai" <[email-masked]>
To: "Ali Sajassi \(sajassi\)" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 4525

Ali, 

Inline:

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> Sent: Sunday, December 10, 2006 3:48 PM
> To: Silvano Gai; Joe Touch
> Cc: [email-masked]; Don Fedyk; Gray, Eric; Developing a hybrid
> router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> 
> Silvano,
> 
> 
> >
> > My comment is that IEEE 802.1ah has no space for both the
> > ultimate source/dest and the next hop source/dest.
> >
> 
> Yes, it doesn't but if next hop source/dest is needed, it can be
derived
> through other means as discussed briefly during last IETF meeting.
> 
> > IEEE 802.1ah is designed for multiple enterprises to share a
> > common metro backbone. It does a fine job in that area. It
> > does not support well an arbitrary intermixing of Bridges and
> > Rbridges.
> 
> IEEE 802.1ah is designed to work with a mix of 802.1Q, 802.1ad, and
> 802.1ah bridges.
> 
> 
> >
> > In contrast Trill does a fine job in supporting arbitrary
> > topologies and mixing of RBridges and Bridges thanks to the
> > availability of both the ultimate source/dest and the next
> > hop source/dest.
> >
> > In TRILL the network between the "ingress" and "egress"
> > RBridge isn't a single Ethernet (like in 802.1ah), but rather
> > a sequence of RBridges that may be connected by Ethernets.
> 
> 802.1ah doesn't assume that the network between ingress and egress
edge
> bridges is a single Ethernet. It assume a bridged-LAN network (e.g.,
> 802.1Q network).

You are absolutely right, but TRILL does more, it assumes a sequence of
RBridges interconnected by bridged-LAN network.

-- Silvano

> 
> -Ali
> 
> >
> > Things look similar, but are substantially different.
> >
> > -- Silvano
> >
> >
> > >
> > > As per below, if R1 (current rbridge) wants to pick from among
> > multiple
> > > next-hops R2 and R3, it does so with the outermost ethernet
> > header. If
> > > they're logical (R2/R3 both on the same NIC), then just assign
> > separate
> > > ethernet addresses to the same interface.
> > >
> > > What's left?
> > >
> > > Joe
> > >
> > >
> > > >> -----Original Message-----
> > > >> From: Joe Touch [mailto:[email-masked]]
> > > >> Sent: Thursday, December 07, 2006 11:00 PM
> > > >> To: [email-masked]
> > > >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
> > > > Developing
> > > >> a hybrid router/bridge.
> > > >> Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > >>
> > > >>
> > > >>
> > > >> [email-masked] wrote:
> > > >>> Travelling again, so extremely limited access to email (as in,
> > about
> > > > 10
> > > >> minutes here and there
> > > >>> on a SLOW connection).  Anyway, I'll answer some of these:
> > > >>>
> > > >>> a) why "next hop" and "previous hop" in addition to "ultimate"
> > > > source
> > > >> and destination
> > > >>> At least one of the reasons is that if there are three
> > RBridges on
> > > > the
> > > >> same link, R1, R2, and R3,
> > > >>> it is useful for R1 to choose which of R2 or R3 should
> > receive the
> > > >> packet. It isn't obvious from
> > > >>> the destination address because it could be that either R2 or
R3
> > > > would
> > > >> be logical, and R1 is
> > > >>> load splitting. Also, it helps focus traffic on the link, and
> > ensure
> > > > it
> > > >> doesn't get filtered, if
> > > >>> the bridges on the link only need to learn R1, R2, and R3,
> > > > especially
> > > >> since traffic from outside
> > > >>> RBridges might arrive from different entry points onto the
link.
> > > >> The ultimate destination (and source, for that matter) should
be
> > > >> sufficiently indicated by the inner ethernet packet. The outer
> > header
> > > > is
> > > >> already hop-by-hop inside the rbridge anyway. What additional
> > > >> information is required?
> > > >>
> > > >> The next/previous hop information sounds like a source
> > route with
> > > >> record-route option. While that's useful for debugging,
> > it doesn't
> > > > seem
> > > >> necessary.
> > > >>
> > > >>> b) congestion management was explained to us, and it was what
> > > > convinced
> > > >> us we needed "ultimate
> > > >>> source RBridge" in order to know where to send the congestion
> > > >> notification. If you could explain the
> > > >>> other things, we could see if there is a problem, but
> > if they are
> > > >> similar to congestion notification, then
> > > >>> having the ingress RBridge will accommodate them.
> > > >> Why doesn't the source ethernet address indicate this already?
> > > >>
> > > >> Joe
> > > >
> >

Content-class: urn:content-classes:message
Date: Mon, 11 Dec 2006 01:18:03 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2898

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Sunday, December 10, 2006 10:56 PM
> To: Ali Sajassi (sajassi)
> Cc: Silvano Gai; [email-masked]; Don Fedyk; Gray, 
> Eric; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> 
> 
> Ali Sajassi (sajassi) wrote:
> >  
> > 
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Friday, December 08, 2006 7:29 AM
> >> To: Silvano Gai
> >> Cc: [email-masked]; Ali Sajassi (sajassi); Don Fedyk; Gray, 
> >> Eric; Developing a hybrid router/bridge.
> >> Subject: Re: [rbridge] Use of 802.1ah Encaps
> >>
> >>
> >>
> >> Silvano Gai wrote:
> >>> Joe,
> >>>
> >>> TRILL will never scale if you mandate to keep the
> >> forwarding table for
> >>> the inner addresses on all RBridges, especially in a IEEE 802.1ah 
> >>> environment!!!
> >> Sorry; let me backup:
> >>
> >> Here's where we were at the last IETF:
> >>
> >> - the shim indicates the source (ingress) and dest (egress)
> >>   (originally this was just dest for unicast, source for mcast
> >>   but we agreed in San Diego to include both)
> >> 	i.e., agreed with the point above; those are the
> >> 	addresses on which packets are forwarded
> >>
> >>   the ultimate source is indicated in the shim already
> >>
> >> - the outer header already indicates the previous/next-hop rbridge
> >>
> >> What's the reason for needing any further information?
> >>
> >> As per below, if R1 (current rbridge) wants to pick from among 
> >> multiple next-hops R2 and R3, it does so with the 
> outermost Ethernet 
> >> header. If they're logical (R2/R3 both on the same NIC), then just 
> >> assign separate ethernet addresses to the same interface.
> >>
> >> What's left?
> > 
> > If the outer Ethernet addresses represent the link Ether 
> addresses for 
> > the current/next-hop rbriges and the shim header represent the 
> > source/dest rbridge addresses, then why not just do IP encap using 
> > L2TPv3/GRE and be done with !!
> 
> Can you please describe the header you're considering an 
> alternative, e.g, where the current one is:
> 	[outer ether [6-byte shim] [inner ether [payload]]]
> 

	[outer ether][20-byte IP header][4 or 8 byte L2TPv3/GRE shim]
[inner Ether [payload]]

The draw back is the additional 20 bytes of IP header but the advantage
is that you can use the IGP as is :-)

> The above adds 20 bytes (14 outer ether + 6 byte shim), and 
> allows TTL management inside the rbridge without affecting 
> the payload TTL (required for correct operation).
> 
> I'm not exactly sure what you mean you L2TPv3/GRE, but I'm 
> wondering if that comes out to 42 bytes of header, and 
> whether it provides an L2 solution.

It is an L2 solution. I did a draft on it long time ago in context of
L2VPN:

http://ietfreport.isoc.org/idref/draft-sajassi-mvpls/

-Ali

> Joe

Date: Sun, 10 Dec 2006 22:55:32 -0800
From: Joe Touch <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2843

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig170CAF71959D1A15411B6140
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ali Sajassi (sajassi) wrote:
> =20
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]=20
>> Sent: Friday, December 08, 2006 7:29 AM
>> To: Silvano Gai
>> Cc: [email-masked]; Ali Sajassi (sajassi); Don Fedyk;=20
>> Gray, Eric; Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Use of 802.1ah Encaps
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> TRILL will never scale if you mandate to keep the=20
>> forwarding table for=20
>>> the inner addresses on all RBridges, especially in a IEEE 802.1ah=20
>>> environment!!!
>> Sorry; let me backup:
>>
>> Here's where we were at the last IETF:
>>
>> - the shim indicates the source (ingress) and dest (egress)
>>   (originally this was just dest for unicast, source for mcast
>>   but we agreed in San Diego to include both)
>> 	i.e., agreed with the point above; those are the
>> 	addresses on which packets are forwarded
>>
>>   the ultimate source is indicated in the shim already
>>
>> - the outer header already indicates the previous/next-hop rbridge
>>
>> What's the reason for needing any further information?
>>
>> As per below, if R1 (current rbridge) wants to pick from=20
>> among multiple next-hops R2 and R3, it does so with the=20
>> outermost Ethernet header. If they're logical (R2/R3 both on=20
>> the same NIC), then just assign separate ethernet addresses=20
>> to the same interface.
>>
>> What's left?
>=20
> If the outer Ethernet addresses represent the link Ether addresses for
> the current/next-hop rbriges and the shim header represent the
> source/dest rbridge addresses, then why not just do IP encap using
> L2TPv3/GRE and be done with !!

Can you please describe the header you're considering an alternative,
e.g, where the current one is:
	[outer ether [6-byte shim] [inner ether [payload]]]

The above adds 20 bytes (14 outer ether + 6 byte shim), and allows TTL
management inside the rbridge without affecting the payload TTL
(required for correct operation).

I'm not exactly sure what you mean you L2TPv3/GRE, but I'm wondering if
that comes out to 42 bytes of header, and whether it provides an L2
solution.

Joe

--------------enig170CAF71959D1A15411B6140
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig170CAF71959D1A15411B6140--

Content-class: urn:content-classes:message
Date: Sun, 10 Dec 2006 15:48:19 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3866

Silvano,

> 
> My comment is that IEEE 802.1ah has no space for both the 
> ultimate source/dest and the next hop source/dest.
> 

Yes, it doesn't but if next hop source/dest is needed, it can be derived
through other means as discussed briefly during last IETF meeting. 

> IEEE 802.1ah is designed for multiple enterprises to share a 
> common metro backbone. It does a fine job in that area. It 
> does not support well an arbitrary intermixing of Bridges and 
> Rbridges.

IEEE 802.1ah is designed to work with a mix of 802.1Q, 802.1ad, and
802.1ah bridges.

> 
> In contrast Trill does a fine job in supporting arbitrary 
> topologies and mixing of RBridges and Bridges thanks to the 
> availability of both the ultimate source/dest and the next 
> hop source/dest.
> 
> In TRILL the network between the "ingress" and "egress" 
> RBridge isn't a single Ethernet (like in 802.1ah), but rather 
> a sequence of RBridges that may be connected by Ethernets.

802.1ah doesn't assume that the network between ingress and egress edge
bridges is a single Ethernet. It assume a bridged-LAN network (e.g.,
802.1Q network).

-Ali

> 
> Things look similar, but are substantially different.
> 
> -- Silvano
> 
> 
> > 
> > As per below, if R1 (current rbridge) wants to pick from among
> multiple
> > next-hops R2 and R3, it does so with the outermost ethernet 
> header. If 
> > they're logical (R2/R3 both on the same NIC), then just assign
> separate
> > ethernet addresses to the same interface.
> > 
> > What's left?
> > 
> > Joe
> > 
> > 
> > >> -----Original Message-----
> > >> From: Joe Touch [mailto:[email-masked]]
> > >> Sent: Thursday, December 07, 2006 11:00 PM
> > >> To: [email-masked]
> > >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
> > > Developing
> > >> a hybrid router/bridge.
> > >> Subject: Re: [rbridge] Use of 802.1ah Encaps
> > >>
> > >>
> > >>
> > >> [email-masked] wrote:
> > >>> Travelling again, so extremely limited access to email (as in,
> about
> > > 10
> > >> minutes here and there
> > >>> on a SLOW connection).  Anyway, I'll answer some of these:
> > >>>
> > >>> a) why "next hop" and "previous hop" in addition to "ultimate"
> > > source
> > >> and destination
> > >>> At least one of the reasons is that if there are three 
> RBridges on
> > > the
> > >> same link, R1, R2, and R3,
> > >>> it is useful for R1 to choose which of R2 or R3 should 
> receive the
> > >> packet. It isn't obvious from
> > >>> the destination address because it could be that either R2 or R3
> > > would
> > >> be logical, and R1 is
> > >>> load splitting. Also, it helps focus traffic on the link, and
> ensure
> > > it
> > >> doesn't get filtered, if
> > >>> the bridges on the link only need to learn R1, R2, and R3,
> > > especially
> > >> since traffic from outside
> > >>> RBridges might arrive from different entry points onto the link.
> > >> The ultimate destination (and source, for that matter) should be 
> > >> sufficiently indicated by the inner ethernet packet. The outer
> header
> > > is
> > >> already hop-by-hop inside the rbridge anyway. What additional 
> > >> information is required?
> > >>
> > >> The next/previous hop information sounds like a source 
> route with 
> > >> record-route option. While that's useful for debugging, 
> it doesn't
> > > seem
> > >> necessary.
> > >>
> > >>> b) congestion management was explained to us, and it was what
> > > convinced
> > >> us we needed "ultimate
> > >>> source RBridge" in order to know where to send the congestion
> > >> notification. If you could explain the
> > >>> other things, we could see if there is a problem, but 
> if they are
> > >> similar to congestion notification, then
> > >>> having the ingress RBridge will accommodate them.
> > >> Why doesn't the source ethernet address indicate this already?
> > >>
> > >> Joe
> > >
> 

Content-class: urn:content-classes:message
Date: Sun, 10 Dec 2006 15:34:14 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Silvano Gai" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3792

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Friday, December 08, 2006 7:29 AM
> To: Silvano Gai
> Cc: [email-masked]; Ali Sajassi (sajassi); Don Fedyk; 
> Gray, Eric; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> > 
> > TRILL will never scale if you mandate to keep the 
> forwarding table for 
> > the inner addresses on all RBridges, especially in a IEEE 802.1ah 
> > environment!!!
> 
> Sorry; let me backup:
> 
> Here's where we were at the last IETF:
> 
> - the shim indicates the source (ingress) and dest (egress)
>   (originally this was just dest for unicast, source for mcast
>   but we agreed in San Diego to include both)
> 	i.e., agreed with the point above; those are the
> 	addresses on which packets are forwarded
> 
>   the ultimate source is indicated in the shim already
> 
> - the outer header already indicates the previous/next-hop rbridge
> 
> What's the reason for needing any further information?
> 
> As per below, if R1 (current rbridge) wants to pick from 
> among multiple next-hops R2 and R3, it does so with the 
> outermost Ethernet header. If they're logical (R2/R3 both on 
> the same NIC), then just assign separate ethernet addresses 
> to the same interface.
> 
> What's left?

If the outer Ethernet addresses represent the link Ether addresses for
the current/next-hop rbriges and the shim header represent the
source/dest rbridge addresses, then why not just do IP encap using
L2TPv3/GRE and be done with !!

-Ali

> 
> Joe
> 
> 
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Thursday, December 07, 2006 11:00 PM
> >> To: [email-masked]
> >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
> > Developing
> >> a hybrid router/bridge.
> >> Subject: Re: [rbridge] Use of 802.1ah Encaps
> >>
> >>
> >>
> >> [email-masked] wrote:
> >>> Travelling again, so extremely limited access to email 
> (as in, about
> > 10
> >> minutes here and there
> >>> on a SLOW connection).  Anyway, I'll answer some of these:
> >>>
> >>> a) why "next hop" and "previous hop" in addition to "ultimate"
> > source
> >> and destination
> >>> At least one of the reasons is that if there are three RBridges on
> > the
> >> same link, R1, R2, and R3,
> >>> it is useful for R1 to choose which of R2 or R3 should receive the
> >> packet. It isn't obvious from
> >>> the destination address because it could be that either R2 or R3
> > would
> >> be logical, and R1 is
> >>> load splitting. Also, it helps focus traffic on the link, 
> and ensure
> > it
> >> doesn't get filtered, if
> >>> the bridges on the link only need to learn R1, R2, and R3,
> > especially
> >> since traffic from outside
> >>> RBridges might arrive from different entry points onto the link.
> >> The ultimate destination (and source, for that matter) should be 
> >> sufficiently indicated by the inner ethernet packet. The 
> outer header
> > is
> >> already hop-by-hop inside the rbridge anyway. What additional 
> >> information is required?
> >>
> >> The next/previous hop information sounds like a source route with 
> >> record-route option. While that's useful for debugging, it doesn't
> > seem
> >> necessary.
> >>
> >>> b) congestion management was explained to us, and it was what
> > convinced
> >> us we needed "ultimate
> >>> source RBridge" in order to know where to send the congestion
> >> notification. If you could explain the
> >>> other things, we could see if there is a problem, but if they are
> >> similar to congestion notification, then
> >>> having the ingress RBridge will accommodate them.
> >> Why doesn't the source ethernet address indicate this already?
> >>
> >> Joe
> > 
> 
> 

Content-class: urn:content-classes:message
Date: Sun, 10 Dec 2006 15:24:48 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3545

Hi Silvano,

> > 
> > > 3) Many unneeded fields and therefore larger frame overhead.
> > >
> > 
> > Such as ?
> 
> The I-tag is not useful in TRILL and in contrast two 
> addresses and the TTL are missing.

I-tag my not be useful in data-center applications but it is useful in
large Enterprise applications.  I acknowledge that TTL is missing but if
needed we (at IEEE) can try to accommodate it. And by two addresses, if
you mean next hop addresses, then those can be inferred by B-MAC
addresses (and possibly B-VLAN if needed) in .1ah encap.

-Ali 

> 
> > 
> > > The advantages are:
> > > 1) Larger addressable market for TRILL
> > >
> > > IMO if we stick with the WG charter the disadvantages clearly 
> > > outweigh the advantages.
> > >
> > > The WG can be re-chartered, but if we consider the Enterprise and 
> > > Data Center market, IEEE 802.1ah is an overkill.
> > >
> > 
> > If by overkill you mean a bit bigger header, then I agree 
> but look at 
> > all the other advantages that you get from using standard 
> IEEE header 
> > and shim including:
> > 	- security Mgmt:  MACSec/KeySec
> > 	- Congestion Mgmt
> > 	- Connectivity Fault Mgmt
> > 
> > Has it been considered how these are going to work with TRILL shim 
> > header or are these outside of WG charter :-)
> > 
> > -Ali
> > 
> > 
> > > -- Silvano
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> [mailto:[email-masked]]
> > > On
> > > > Behalf Of Don Fedyk
> > > > Sent: Thursday, December 07, 2006 9:21 AM
> > > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > >
> > > > Hi Eric
> > > >
> > > > > -----Original Message-----
> > > > > From: Gray, Eric [mailto:[email-masked]]
> > > > >
> > > > > Don,
> > > > >
> > > > > 	And yet, someone (Ali Sajassi) asserted (in his message
> > > dated Wed
> > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or
> additional
> > > > > complications with using 802.1ah in enterprises for
> plug-and-play
> > > > > applicability.
> > > > >
> > > > > 	Perhaps Ali can answer my question then.
> > > > >
> > > > > 	But, to more directly address your earlier comments:
> > > > >
> > > > > 	The TRILL WG has NOT come up with an encapsulation that
> "looks
> > > > > like" 802.1ah - unless someone squints really hard 
> and tries to 
> > > > > pretend that two separate Ethernet encapsulations -
> > > separated by a
> > > > > SHIM header - are one single encapsulation.
> > > >
> > > > To be fair Point to Point header that was discussed without
> > > one of the
> > > > shims was very close "functionally" (colloquial looks like) to
> > > 802.1ah.
> > > > My opinion is still we don't need several variations of
> > > headers doing
> > > > similar things.
> > > >
> > > > This was the slide that looked a lot like what I posted.
> > > >
> > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > > >
> > > > Regards,
> > > > Don
> > > > >
> > > > > 	That is not to say that the WG has done anything that
> > > could be said
> > > > > to disallow the use of 802.1ah encapsulation.
> > > > > It is just not obviously consistent with all of the WG
> > > goals to use
> > > > > _only_ 802.1ah encapsulation.
> > > > >
> > > > > --
> > > > > Eric
> > > > >
> > > >
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [email-masked]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > >
> 

Content-class: urn:content-classes:message
Date: Sun, 10 Dec 2006 15:06:58 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 7315

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 9:56 PM
> To: Ali Sajassi (sajassi)
> Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid 
> router/bridge.; Joe Touch
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> Travelling again, so extremely limited access to email (as 
> in, about 10 minutes here and there on a SLOW connection).  
> Anyway, I'll answer some of these:

Also sorry for not being able to respond to your email earlier due to my
schedule/meetings (specially on Friday).

> 
> a) why "next hop" and "previous hop" in addition to 
> "ultimate" source and destination
> 
> At least one of the reasons is that if there are three 
> RBridges on the same link, R1, R2, and R3, it is useful for 
> R1 to choose which of R2 or R3 should receive the packet. It 
> isn't obvious from the destination address because it could 
> be that either R2 or R3 would be logical, and R1 is load 
> splitting. Also, it helps focus traffic on the link, and 
> ensure it doesn't get filtered, if the bridges on the link 
> only need to learn R1, R2, and R3, especially since traffic 
> from outside RBridges might arrive from different entry 
> points onto the link.

O.K., I remember now the discussion that we had during the IETF meeting
on load balancing and next hop address. However, there are couple of
ways for achieving the same result. I mentioned briefly during the
meeting the use of VLAN for this purpose and someone else mentioned
using part of 48-bit provider MAC address for this purpose.

> 
> b) congestion management was explained to us, and it was what 
> convinced us we needed "ultimate source RBridge" in order to 
> know where to send the congestion notification. If you could 
> explain the other things, we could see if there is a problem, 
> but if they are similar to congestion notification, then 
> having the ingress RBridge will accommodate them.
> 

With respect to CFM, connectivity fault mgmt is done in a hierarchical
way and it can be performed at the provider service instance level
(e.g., on a per I-SID basis) or it can be performed for group of I-SIDs
on a per B-VLAN level. In both cases, provider MAC addresses are used
which makes the provider OAM control for customer data-traffic very
tight. You cannot get the same result by using OAM messages that use
customer MAC addresses and if you try to do it will be very cumbersome.

Basically what I am trying to point out is that by using non-IEEE
conformance frame format, you assume the responsibility for all the
features developed by IEEE; where as, if you use IEEE conformant frame,
then one can concentrate on the control plane issues which I thought was
the main objective of TRILL.

-Ali 

> Sorry for ignoring all the other messages for now, but I only 
> had a chance to read and respond to one message.
> 
> Radia
> 
> ----- Original Message -----
> From: "Ali Sajassi (sajassi)" <[email-masked]>
> Date: Friday, December 8, 2006 10:53 am
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> > 
> > Silvano,
> > 
> > > -----Original Message-----
> > > From: Silvano Gai [[email-masked]]
> > > Sent: Thursday, December 07, 2006 5:36 PM
> > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > 
> > > 
> > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. 
> > > There are advantages and disadvantages.
> > > 
> > > The disadvantages are:
> > > 1) Lack of Next-Hop addresses. We discussed this at length during 
> > > the last meeting and we didn't reach consensus on a way 
> to eliminate 
> > > them.
> > 
> > Can you refresh my memory for why we need a next-hop 
> address when the 
> > header carries both source and destination PE addresses and 
> when these 
> > addresses are learned in control plane ?
> > 
> > > 2) Lack of a TTL field (it may be added, but it is not 
> there today).
> > 
> > Can probably be accommodated.
> > 
> > > 3) Many unneeded fields and therefore larger frame overhead.
> > > 
> > 
> > Such as ?
> > 
> > > The advantages are:
> > > 1) Larger addressable market for TRILL
> > > 
> > > IMO if we stick with the WG charter the disadvantages clearly 
> > > outweigh the advantages.
> > > 
> > > The WG can be re-chartered, but if we consider the Enterprise and 
> > > Data Center market, IEEE 802.1ah is an overkill.
> > > 
> > 
> > If by overkill you mean a bit bigger header, then I agree 
> but look at 
> > all the other advantages that you get from using standard 
> IEEE header 
> > and shim including:
> > 	- security Mgmt:  MACSec/KeySec 
> > 	- Congestion Mgmt 
> > 	- Connectivity Fault Mgmt
> > 
> > Has it been considered how these are going to work with TRILL shim 
> > header or are these outside of WG charter :-)
> > 
> > -Ali
> > 
> > 
> > > -- Silvano
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [[email-masked]]
> > > On
> > > > Behalf Of Don Fedyk
> > > > Sent: Thursday, December 07, 2006 9:21 AM
> > > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > > 
> > > > Hi Eric
> > > > 
> > > > > -----Original Message-----
> > > > > From: Gray, Eric [[email-masked]]
> > > > >
> > > > > Don,
> > > > >
> > > > > 	And yet, someone (Ali Sajassi) asserted (in his message
> > > dated Wed
> > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or
> > additional
> > > > > complications with using 802.1ah in enterprises for plug-and-
> > play
> > > > > applicability.
> > > > >
> > > > > 	Perhaps Ali can answer my question then.
> > > > >
> > > > > 	But, to more directly address your earlier comments:
> > > > >
> > > > > 	The TRILL WG has NOT come up with an encapsulation that
> > "looks
> > > > > like" 802.1ah - unless someone squints really hard and tries
> > to
> > > > > pretend that two separate Ethernet encapsulations -
> > > separated by a
> > > > > SHIM header - are one single encapsulation.
> > > > 
> > > > To be fair Point to Point header that was discussed without
> > > one of the
> > > > shims was very close "functionally" (colloquial looks like) to
> > > 802.1ah.
> > > > My opinion is still we don't need several variations of
> > > headers doing
> > > > similar things.
> > > > 
> > > > This was the slide that looked a lot like what I posted.
> > > > 
> > > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > > > 
> > > > Regards,
> > > > Don
> > > > >
> > > > > 	That is not to say that the WG has done anything that
> > > could be said
> > > > > to disallow the use of 802.1ah encapsulation.
> > > > > It is just not obviously consistent with all of the WG
> > > goals to use
> > > > > _only_ 802.1ah encapsulation.
> > > > >
> > > > > --
> > > > > Eric
> > > > >
> > > > 
> > > > _______________________________________________
> > > > rbridge mailing list
> > > > [email-masked]
> > > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 

Date: Sat, 09 Dec 2006 00:25:21 +0500
From: [email-masked]
To: Joe Touch <[email-masked]>
Priority: normal
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2710

This is a multi-part message in MIME format.

--Boundary_(ID_0zLyy4776RHzIzxp530jZA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

There's 3 sets of addresses:

a) original frame: endnode source and destination MACs.
b) shim: ingress and egress RBridges
c) outer: next hop, previous hop.

Forwarding is to egress RBridge in order to make RBridges inside not have
to know about all the endnodes, especially in VLANs they are not connected to.
So forwarding by Rbridges between the ingress and egress is solely by
"egress RBridge", not by the source/destination in the inner frame

Outer header (nxt hop/previous hop) is for shared media....if there's a cloud in
the middle with multiple nodes, including multiple RBridges, the "next hop"
lets any bridges on that cloud know where to send it, and won't have them
fallaciously filtering.

Radia

--Boundary_(ID_0zLyy4776RHzIzxp530jZA)
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

[email-masked] wrote:
> Travelling again, so extremely limited access to email (as in, about 10 minutes here and there
> on a SLOW connection).  Anyway, I'll answer some of these:
> 
> a) why "next hop" and "previous hop" in addition to "ultimate" source and destination
> 
> At least one of the reasons is that if there are three RBridges on the same link, R1, R2, and R3,
> it is useful for R1 to choose which of R2 or R3 should receive the packet. It isn't obvious from
> the destination address because it could be that either R2 or R3 would be logical, and R1 is
> load splitting. Also, it helps focus traffic on the link, and ensure it doesn't get filtered, if
> the bridges on the link only need to learn R1, R2, and R3, especially since traffic from outside
> RBridges might arrive from different entry points onto the link.

The ultimate destination (and source, for that matter) should be
sufficiently indicated by the inner ethernet packet. The outer header is
already hop-by-hop inside the rbridge anyway. What additional
information is required?

The next/previous hop information sounds like a source route with
record-route option. While that's useful for debugging, it doesn't seem
necessary.

> b) congestion management was explained to us, and it was what convinced us we needed "ultimate
> source RBridge" in order to know where to send the congestion notification. If you could explain the
> other things, we could see if there is a problem, but if they are similar to congestion notification, then
> having the ingress RBridge will accommodate them.

Why doesn't the source ethernet address indicate this already?

Joe

--Boundary_(ID_0zLyy4776RHzIzxp530jZA)--

Date: Fri, 08 Dec 2006 08:08:44 -0800
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 5238

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2A16AA94D9321C2B8CEEA987
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> Inline:
>=20
>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Friday, December 08, 2006 7:29 AM
>> To: Silvano Gai
>> Cc: [email-masked]; Ali Sajassi (sajassi); Don Fedyk; Gray,
> Eric;
>> Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Use of 802.1ah Encaps
>>
>>
>>
>> Silvano Gai wrote:
>>> Joe,
>>>
>>> TRILL will never scale if you mandate to keep the forwarding table
> for
>>> the inner addresses on all RBridges, especially in a IEEE 802.1ah
>>> environment!!!
>> Sorry; let me backup:
>>
>> Here's where we were at the last IETF:
>>
>> - the shim indicates the source (ingress) and dest (egress)
>>   (originally this was just dest for unicast, source for mcast
>>   but we agreed in San Diego to include both)
>> 	i.e., agreed with the point above; those are the
>> 	addresses on which packets are forwarded
>>
>>   the ultimate source is indicated in the shim already
>>
>> - the outer header already indicates the previous/next-hop rbridge
>>
>> What's the reason for needing any further information?
>=20
> We don't.
>=20
> My comment is that IEEE 802.1ah has no space for both the ultimate
> source/dest and the next hop source/dest.
>=20
> IEEE 802.1ah is designed for multiple enterprises to share a common
> metro backbone. It does a fine job in that area. It does not support
> well an arbitrary intermixing of Bridges and Rbridges.
>=20
> In contrast Trill does a fine job in supporting arbitrary topologies an=
d
> mixing of RBridges and Bridges thanks to the availability of both the
> ultimate source/dest and the next hop source/dest.
>=20
> In TRILL the network between the "ingress" and "egress" RBridge isn't a=

> single Ethernet (like in 802.1ah), but rather a sequence of RBridges
> that may be connected by Ethernets.
>=20
> Things look similar, but are substantially different.

Agreed!

Joe

> -- Silvano
>=20
>=20
>> As per below, if R1 (current rbridge) wants to pick from among
> multiple
>> next-hops R2 and R3, it does so with the outermost ethernet header. If=

>> they're logical (R2/R3 both on the same NIC), then just assign
> separate
>> ethernet addresses to the same interface.
>>
>> What's left?
>>
>> Joe
>>
>>
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:[email-masked]]
>>>> Sent: Thursday, December 07, 2006 11:00 PM
>>>> To: [email-masked]
>>>> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
>>> Developing
>>>> a hybrid router/bridge.
>>>> Subject: Re: [rbridge] Use of 802.1ah Encaps
>>>>
>>>>
>>>>
>>>> [email-masked] wrote:
>>>>> Travelling again, so extremely limited access to email (as in,
> about
>>> 10
>>>> minutes here and there
>>>>> on a SLOW connection).  Anyway, I'll answer some of these:
>>>>>
>>>>> a) why "next hop" and "previous hop" in addition to "ultimate"
>>> source
>>>> and destination
>>>>> At least one of the reasons is that if there are three RBridges on
>>> the
>>>> same link, R1, R2, and R3,
>>>>> it is useful for R1 to choose which of R2 or R3 should receive the
>>>> packet. It isn't obvious from
>>>>> the destination address because it could be that either R2 or R3
>>> would
>>>> be logical, and R1 is
>>>>> load splitting. Also, it helps focus traffic on the link, and
> ensure
>>> it
>>>> doesn't get filtered, if
>>>>> the bridges on the link only need to learn R1, R2, and R3,
>>> especially
>>>> since traffic from outside
>>>>> RBridges might arrive from different entry points onto the link.
>>>> The ultimate destination (and source, for that matter) should be
>>>> sufficiently indicated by the inner ethernet packet. The outer
> header
>>> is
>>>> already hop-by-hop inside the rbridge anyway. What additional
>>>> information is required?
>>>>
>>>> The next/previous hop information sounds like a source route with
>>>> record-route option. While that's useful for debugging, it doesn't
>>> seem
>>>> necessary.
>>>>
>>>>> b) congestion management was explained to us, and it was what
>>> convinced
>>>> us we needed "ultimate
>>>>> source RBridge" in order to know where to send the congestion
>>>> notification. If you could explain the
>>>>> other things, we could see if there is a problem, but if they are
>>>> similar to congestion notification, then
>>>>> having the ingress RBridge will accommodate them.
>>>> Why doesn't the source ethernet address indicate this already?
>>>>
>>>> Joe
>=20

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

--------------enig2A16AA94D9321C2B8CEEA987
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig2A16AA94D9321C2B8CEEA987--

Content-class: urn:content-classes:message
Date: Fri, 8 Dec 2006 07:39:28 -0800
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 4288

Joe,

Inline:

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, December 08, 2006 7:29 AM
> To: Silvano Gai
> Cc: [email-masked]; Ali Sajassi (sajassi); Don Fedyk; Gray,
Eric;
> Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > TRILL will never scale if you mandate to keep the forwarding table
for
> > the inner addresses on all RBridges, especially in a IEEE 802.1ah
> > environment!!!
> 
> Sorry; let me backup:
> 
> Here's where we were at the last IETF:
> 
> - the shim indicates the source (ingress) and dest (egress)
>   (originally this was just dest for unicast, source for mcast
>   but we agreed in San Diego to include both)
> 	i.e., agreed with the point above; those are the
> 	addresses on which packets are forwarded
> 
>   the ultimate source is indicated in the shim already
> 
> - the outer header already indicates the previous/next-hop rbridge
> 
> What's the reason for needing any further information?

We don't.

My comment is that IEEE 802.1ah has no space for both the ultimate
source/dest and the next hop source/dest.

IEEE 802.1ah is designed for multiple enterprises to share a common
metro backbone. It does a fine job in that area. It does not support
well an arbitrary intermixing of Bridges and Rbridges.

In contrast Trill does a fine job in supporting arbitrary topologies and
mixing of RBridges and Bridges thanks to the availability of both the
ultimate source/dest and the next hop source/dest.

In TRILL the network between the "ingress" and "egress" RBridge isn't a
single Ethernet (like in 802.1ah), but rather a sequence of RBridges
that may be connected by Ethernets.

Things look similar, but are substantially different.

-- Silvano

> 
> As per below, if R1 (current rbridge) wants to pick from among
multiple
> next-hops R2 and R3, it does so with the outermost ethernet header. If
> they're logical (R2/R3 both on the same NIC), then just assign
separate
> ethernet addresses to the same interface.
> 
> What's left?
> 
> Joe
> 
> 
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Thursday, December 07, 2006 11:00 PM
> >> To: [email-masked]
> >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
> > Developing
> >> a hybrid router/bridge.
> >> Subject: Re: [rbridge] Use of 802.1ah Encaps
> >>
> >>
> >>
> >> [email-masked] wrote:
> >>> Travelling again, so extremely limited access to email (as in,
about
> > 10
> >> minutes here and there
> >>> on a SLOW connection).  Anyway, I'll answer some of these:
> >>>
> >>> a) why "next hop" and "previous hop" in addition to "ultimate"
> > source
> >> and destination
> >>> At least one of the reasons is that if there are three RBridges on
> > the
> >> same link, R1, R2, and R3,
> >>> it is useful for R1 to choose which of R2 or R3 should receive the
> >> packet. It isn't obvious from
> >>> the destination address because it could be that either R2 or R3
> > would
> >> be logical, and R1 is
> >>> load splitting. Also, it helps focus traffic on the link, and
ensure
> > it
> >> doesn't get filtered, if
> >>> the bridges on the link only need to learn R1, R2, and R3,
> > especially
> >> since traffic from outside
> >>> RBridges might arrive from different entry points onto the link.
> >> The ultimate destination (and source, for that matter) should be
> >> sufficiently indicated by the inner ethernet packet. The outer
header
> > is
> >> already hop-by-hop inside the rbridge anyway. What additional
> >> information is required?
> >>
> >> The next/previous hop information sounds like a source route with
> >> record-route option. While that's useful for debugging, it doesn't
> > seem
> >> necessary.
> >>
> >>> b) congestion management was explained to us, and it was what
> > convinced
> >> us we needed "ultimate
> >>> source RBridge" in order to know where to send the congestion
> >> notification. If you could explain the
> >>> other things, we could see if there is a problem, but if they are
> >> similar to congestion notification, then
> >>> having the ingress RBridge will accommodate them.
> >> Why doesn't the source ethernet address indicate this already?
> >>
> >> Joe
> >

Date: Fri, 08 Dec 2006 07:28:47 -0800
From: Joe Touch <[email-masked]>
To: Silvano Gai <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, [email-masked]
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3745

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE21E66C864F8F7F57C12B9BB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Silvano Gai wrote:
> Joe,
>=20
> TRILL will never scale if you mandate to keep the forwarding table for
> the inner addresses on all RBridges, especially in a IEEE 802.1ah
> environment!!!

Sorry; let me backup:

Here's where we were at the last IETF:

- the shim indicates the source (ingress) and dest (egress)
  (originally this was just dest for unicast, source for mcast
  but we agreed in San Diego to include both)
	i.e., agreed with the point above; those are the
	addresses on which packets are forwarded

  the ultimate source is indicated in the shim already

- the outer header already indicates the previous/next-hop rbridge

What's the reason for needing any further information?

As per below, if R1 (current rbridge) wants to pick from among multiple
next-hops R2 and R3, it does so with the outermost ethernet header. If
they're logical (R2/R3 both on the same NIC), then just assign separate
ethernet addresses to the same interface.

What's left?

Joe

>> -----Original Message-----
>> From: Joe Touch [mailto:[email-masked]]
>> Sent: Thursday, December 07, 2006 11:00 PM
>> To: [email-masked]
>> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
> Developing
>> a hybrid router/bridge.
>> Subject: Re: [rbridge] Use of 802.1ah Encaps
>>
>>
>>
>> [email-masked] wrote:
>>> Travelling again, so extremely limited access to email (as in, about
> 10
>> minutes here and there
>>> on a SLOW connection).  Anyway, I'll answer some of these:
>>>
>>> a) why "next hop" and "previous hop" in addition to "ultimate"
> source
>> and destination
>>> At least one of the reasons is that if there are three RBridges on
> the
>> same link, R1, R2, and R3,
>>> it is useful for R1 to choose which of R2 or R3 should receive the
>> packet. It isn't obvious from
>>> the destination address because it could be that either R2 or R3
> would
>> be logical, and R1 is
>>> load splitting. Also, it helps focus traffic on the link, and ensure
> it
>> doesn't get filtered, if
>>> the bridges on the link only need to learn R1, R2, and R3,
> especially
>> since traffic from outside
>>> RBridges might arrive from different entry points onto the link.
>> The ultimate destination (and source, for that matter) should be
>> sufficiently indicated by the inner ethernet packet. The outer header
> is
>> already hop-by-hop inside the rbridge anyway. What additional
>> information is required?
>>
>> The next/previous hop information sounds like a source route with
>> record-route option. While that's useful for debugging, it doesn't
> seem
>> necessary.
>>
>>> b) congestion management was explained to us, and it was what
> convinced
>> us we needed "ultimate
>>> source RBridge" in order to know where to send the congestion
>> notification. If you could explain the
>>> other things, we could see if there is a problem, but if they are
>> similar to congestion notification, then
>>> having the ingress RBridge will accommodate them.
>> Why doesn't the source ethernet address indicate this already?
>>
>> Joe
>=20

--------------enigE21E66C864F8F7F57C12B9BB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigE21E66C864F8F7F57C12B9BB--

Content-class: urn:content-classes:message
Date: Fri, 8 Dec 2006 06:59:17 -0800
From: "Silvano Gai" <[email-masked]>
To: "Joe Touch" <[email-masked]>, <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2313

Joe,

TRILL will never scale if you mandate to keep the forwarding table for
the inner addresses on all RBridges, especially in a IEEE 802.1ah
environment!!!

It is only the ingress Rbridge that looks at the inner address and put
the egress RBridge address in the frame.

-- Silvano

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, December 07, 2006 11:00 PM
> To: [email-masked]
> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
Developing
> a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> 
> 
> [email-masked] wrote:
> > Travelling again, so extremely limited access to email (as in, about
10
> minutes here and there
> > on a SLOW connection).  Anyway, I'll answer some of these:
> >
> > a) why "next hop" and "previous hop" in addition to "ultimate"
source
> and destination
> >
> > At least one of the reasons is that if there are three RBridges on
the
> same link, R1, R2, and R3,
> > it is useful for R1 to choose which of R2 or R3 should receive the
> packet. It isn't obvious from
> > the destination address because it could be that either R2 or R3
would
> be logical, and R1 is
> > load splitting. Also, it helps focus traffic on the link, and ensure
it
> doesn't get filtered, if
> > the bridges on the link only need to learn R1, R2, and R3,
especially
> since traffic from outside
> > RBridges might arrive from different entry points onto the link.
> 
> The ultimate destination (and source, for that matter) should be
> sufficiently indicated by the inner ethernet packet. The outer header
is
> already hop-by-hop inside the rbridge anyway. What additional
> information is required?
> 
> The next/previous hop information sounds like a source route with
> record-route option. While that's useful for debugging, it doesn't
seem
> necessary.
> 
> > b) congestion management was explained to us, and it was what
convinced
> us we needed "ultimate
> > source RBridge" in order to know where to send the congestion
> notification. If you could explain the
> > other things, we could see if there is a problem, but if they are
> similar to congestion notification, then
> > having the ingress RBridge will accommodate them.
> 
> Why doesn't the source ethernet address indicate this already?
> 
> Joe

Content-class: urn:content-classes:message
Date: Fri, 8 Dec 2006 07:07:25 -0800
From: "Silvano Gai" <[email-masked]>
To: "Ali Sajassi \(sajassi\)" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 4181

Ali,

Inline:

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> Sent: Thursday, December 07, 2006 9:23 PM
> To: Silvano Gai; Don Fedyk; Gray, Eric
> Cc: Developing a hybrid router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> 
> Silvano,
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:[email-masked]]
> > Sent: Thursday, December 07, 2006 5:36 PM
> > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.; Joe Touch
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> >
> >
> > IMO it is technically possible for TRILL to adopt IEEE 802.1ah.
> > There are advantages and disadvantages.
> >
> > The disadvantages are:
> > 1) Lack of Next-Hop addresses. We discussed this at length
> > during the last meeting and we didn't reach consensus on a
> > way to eliminate them.
> 
> Can you refresh my memory for why we need a next-hop address when the
> header carries both source and destination PE addresses and when these
> addresses are learned in control plane ?
> 

Radia did in her reply

> > 2) Lack of a TTL field (it may be added, but it is not there today).
> 
> Can probably be accommodated.
> 
> > 3) Many unneeded fields and therefore larger frame overhead.
> >
> 
> Such as ?

The I-tag is not useful in TRILL and in contrast two addresses and the
TTL are missing.

> 
> > The advantages are:
> > 1) Larger addressable market for TRILL
> >
> > IMO if we stick with the WG charter the disadvantages clearly
> > outweigh the advantages.
> >
> > The WG can be re-chartered, but if we consider the Enterprise
> > and Data Center market, IEEE 802.1ah is an overkill.
> >
> 
> If by overkill you mean a bit bigger header, then I agree but look at
> all the other advantages that you get from using standard IEEE header
> and shim including:
> 	- security Mgmt:  MACSec/KeySec
> 	- Congestion Mgmt
> 	- Connectivity Fault Mgmt
> 
> Has it been considered how these are going to work with TRILL shim
> header or are these outside of WG charter :-)
> 
> -Ali
> 
> 
> > -- Silvano
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
[mailto:[email-masked]]
> > On
> > > Behalf Of Don Fedyk
> > > Sent: Thursday, December 07, 2006 9:21 AM
> > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > >
> > > Hi Eric
> > >
> > > > -----Original Message-----
> > > > From: Gray, Eric [mailto:[email-masked]]
> > > >
> > > > Don,
> > > >
> > > > 	And yet, someone (Ali Sajassi) asserted (in his message
> > dated Wed
> > > > 12/6/2006 at 2:16 PM EST) that there were no issues or
additional
> > > > complications with using 802.1ah in enterprises for
plug-and-play
> > > > applicability.
> > > >
> > > > 	Perhaps Ali can answer my question then.
> > > >
> > > > 	But, to more directly address your earlier comments:
> > > >
> > > > 	The TRILL WG has NOT come up with an encapsulation that
"looks
> > > > like" 802.1ah - unless someone squints really hard and tries to
> > > > pretend that two separate Ethernet encapsulations -
> > separated by a
> > > > SHIM header - are one single encapsulation.
> > >
> > > To be fair Point to Point header that was discussed without
> > one of the
> > > shims was very close "functionally" (colloquial looks like) to
> > 802.1ah.
> > > My opinion is still we don't need several variations of
> > headers doing
> > > similar things.
> > >
> > > This was the slide that looked a lot like what I posted.
> > >
> > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > >
> > > Regards,
> > > Don
> > > >
> > > > 	That is not to say that the WG has done anything that
> > could be said
> > > > to disallow the use of 802.1ah encapsulation.
> > > > It is just not obviously consistent with all of the WG
> > goals to use
> > > > _only_ 802.1ah encapsulation.
> > > >
> > > > --
> > > > Eric
> > > >
> > >
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> >

Date: Thu, 07 Dec 2006 22:59:39 -0800
From: Joe Touch <[email-masked]>
To: [email-masked]
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2375

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig32C6819D505654DAB50DBB40
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

[email-masked] wrote:
> Travelling again, so extremely limited access to email (as in, about 10=
 minutes here and there
> on a SLOW connection).  Anyway, I'll answer some of these:
>=20
> a) why "next hop" and "previous hop" in addition to "ultimate" source a=
nd destination
>=20
> At least one of the reasons is that if there are three RBridges on the =
same link, R1, R2, and R3,
> it is useful for R1 to choose which of R2 or R3 should receive the pack=
et. It isn't obvious from
> the destination address because it could be that either R2 or R3 would =
be logical, and R1 is
> load splitting. Also, it helps focus traffic on the link, and ensure it=
 doesn't get filtered, if
> the bridges on the link only need to learn R1, R2, and R3, especially s=
ince traffic from outside
> RBridges might arrive from different entry points onto the link.

The ultimate destination (and source, for that matter) should be
sufficiently indicated by the inner ethernet packet. The outer header is
already hop-by-hop inside the rbridge anyway. What additional
information is required?

The next/previous hop information sounds like a source route with
record-route option. While that's useful for debugging, it doesn't seem
necessary.

> b) congestion management was explained to us, and it was what convinced=
 us we needed "ultimate
> source RBridge" in order to know where to send the congestion notificat=
ion. If you could explain the
> other things, we could see if there is a problem, but if they are simil=
ar to congestion notification, then
> having the ingress RBridge will accommodate them.

Why doesn't the source ethernet address indicate this already?

Joe

--------------enig32C6819D505654DAB50DBB40
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig32C6819D505654DAB50DBB40--

Date: Fri, 08 Dec 2006 10:56:01 +0500
From: [email-masked]
To: "Ali Sajassi (sajassi)" <[email-masked]>
Priority: normal
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 5392

Travelling again, so extremely limited access to email (as in, about 10 minutes here and there
on a SLOW connection).  Anyway, I'll answer some of these:

a) why "next hop" and "previous hop" in addition to "ultimate" source and destination

At least one of the reasons is that if there are three RBridges on the same link, R1, R2, and R3,
it is useful for R1 to choose which of R2 or R3 should receive the packet. It isn't obvious from
the destination address because it could be that either R2 or R3 would be logical, and R1 is
load splitting. Also, it helps focus traffic on the link, and ensure it doesn't get filtered, if
the bridges on the link only need to learn R1, R2, and R3, especially since traffic from outside
RBridges might arrive from different entry points onto the link.

b) congestion management was explained to us, and it was what convinced us we needed "ultimate
source RBridge" in order to know where to send the congestion notification. If you could explain the
other things, we could see if there is a problem, but if they are similar to congestion notification, then
having the ingress RBridge will accommodate them.

Sorry for ignoring all the other messages for now, but I only had a chance to read and respond to
one message.

Radia

----- Original Message -----
From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Friday, December 8, 2006 10:53 am
Subject: Re: [rbridge] Use of 802.1ah Encaps

> 
> Silvano, 
> 
> > -----Original Message-----
> > From: Silvano Gai [[email-masked]] 
> > Sent: Thursday, December 07, 2006 5:36 PM
> > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.; Joe Touch
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > 
> > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. 
> > There are advantages and disadvantages.
> > 
> > The disadvantages are:
> > 1) Lack of Next-Hop addresses. We discussed this at length 
> > during the last meeting and we didn't reach consensus on a 
> > way to eliminate them.
> 
> Can you refresh my memory for why we need a next-hop address when the
> header carries both source and destination PE addresses and when these
> addresses are learned in control plane ?
> 
> > 2) Lack of a TTL field (it may be added, but it is not there today).
> 
> Can probably be accommodated.
> 
> > 3) Many unneeded fields and therefore larger frame overhead.
> > 
> 
> Such as ?
> 
> > The advantages are:
> > 1) Larger addressable market for TRILL
> > 
> > IMO if we stick with the WG charter the disadvantages clearly 
> > outweigh the advantages.
> > 
> > The WG can be re-chartered, but if we consider the Enterprise 
> > and Data Center market, IEEE 802.1ah is an overkill.
> > 
> 
> If by overkill you mean a bit bigger header, then I agree but look at
> all the other advantages that you get from using standard IEEE header
> and shim including:
> 	- security Mgmt:  MACSec/KeySec 
> 	- Congestion Mgmt 
> 	- Connectivity Fault Mgmt
> 
> Has it been considered how these are going to work with TRILL shim
> header or are these outside of WG charter :-)
> 
> -Ali
> 
> 
> > -- Silvano
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [[email-masked]]
> > On
> > > Behalf Of Don Fedyk
> > > Sent: Thursday, December 07, 2006 9:21 AM
> > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > 
> > > Hi Eric
> > > 
> > > > -----Original Message-----
> > > > From: Gray, Eric [[email-masked]]
> > > >
> > > > Don,
> > > >
> > > > 	And yet, someone (Ali Sajassi) asserted (in his message 
> > dated Wed 
> > > > 12/6/2006 at 2:16 PM EST) that there were no issues or 
> additional 
> > > > complications with using 802.1ah in enterprises for plug-and-
> play 
> > > > applicability.
> > > >
> > > > 	Perhaps Ali can answer my question then.
> > > >
> > > > 	But, to more directly address your earlier comments:
> > > >
> > > > 	The TRILL WG has NOT come up with an encapsulation that 
> "looks 
> > > > like" 802.1ah - unless someone squints really hard and tries 
> to 
> > > > pretend that two separate Ethernet encapsulations - 
> > separated by a 
> > > > SHIM header - are one single encapsulation.
> > > 
> > > To be fair Point to Point header that was discussed without 
> > one of the 
> > > shims was very close "functionally" (colloquial looks like) to
> > 802.1ah.
> > > My opinion is still we don't need several variations of 
> > headers doing 
> > > similar things.
> > > 
> > > This was the slide that looked a lot like what I posted.
> > > 
> > > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > > 
> > > Regards,
> > > Don
> > > >
> > > > 	That is not to say that the WG has done anything that 
> > could be said 
> > > > to disallow the use of 802.1ah encapsulation.
> > > > It is just not obviously consistent with all of the WG 
> > goals to use 
> > > > _only_ 802.1ah encapsulation.
> > > >
> > > > --
> > > > Eric
> > > >
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 21:23:26 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Silvano Gai" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Gray, Eric" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3578

Silvano, 

> -----Original Message-----
> From: Silvano Gai [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 5:36 PM
> To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> 
> IMO it is technically possible for TRILL to adopt IEEE 802.1ah. 
> There are advantages and disadvantages.
> 
> The disadvantages are:
> 1) Lack of Next-Hop addresses. We discussed this at length 
> during the last meeting and we didn't reach consensus on a 
> way to eliminate them.

Can you refresh my memory for why we need a next-hop address when the
header carries both source and destination PE addresses and when these
addresses are learned in control plane ?

> 2) Lack of a TTL field (it may be added, but it is not there today).

Can probably be accommodated.

> 3) Many unneeded fields and therefore larger frame overhead.
> 

Such as ?

> The advantages are:
> 1) Larger addressable market for TRILL
> 
> IMO if we stick with the WG charter the disadvantages clearly 
> outweigh the advantages.
> 
> The WG can be re-chartered, but if we consider the Enterprise 
> and Data Center market, IEEE 802.1ah is an overkill.
> 

If by overkill you mean a bit bigger header, then I agree but look at
all the other advantages that you get from using standard IEEE header
and shim including:
	- security Mgmt:  MACSec/KeySec 
	- Congestion Mgmt 
	- Connectivity Fault Mgmt

Has it been considered how these are going to work with TRILL shim
header or are these outside of WG charter :-)

-Ali

> -- Silvano
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On
> > Behalf Of Don Fedyk
> > Sent: Thursday, December 07, 2006 9:21 AM
> > To: Gray, Eric; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.; Joe Touch
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > 
> > Hi Eric
> > 
> > > -----Original Message-----
> > > From: Gray, Eric [mailto:[email-masked]]
> > >
> > > Don,
> > >
> > > 	And yet, someone (Ali Sajassi) asserted (in his message 
> dated Wed 
> > > 12/6/2006 at 2:16 PM EST) that there were no issues or additional 
> > > complications with using 802.1ah in enterprises for plug-and-play 
> > > applicability.
> > >
> > > 	Perhaps Ali can answer my question then.
> > >
> > > 	But, to more directly address your earlier comments:
> > >
> > > 	The TRILL WG has NOT come up with an encapsulation that "looks 
> > > like" 802.1ah - unless someone squints really hard and tries to 
> > > pretend that two separate Ethernet encapsulations - 
> separated by a 
> > > SHIM header - are one single encapsulation.
> > 
> > To be fair Point to Point header that was discussed without 
> one of the 
> > shims was very close "functionally" (colloquial looks like) to
> 802.1ah.
> > My opinion is still we don't need several variations of 
> headers doing 
> > similar things.
> > 
> > This was the slide that looked a lot like what I posted.
> > 
> > http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > 
> > Regards,
> > Don
> > >
> > > 	That is not to say that the WG has done anything that 
> could be said 
> > > to disallow the use of 802.1ah encapsulation.
> > > It is just not obviously consistent with all of the WG 
> goals to use 
> > > _only_ 802.1ah encapsulation.
> > >
> > > --
> > > Eric
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 21:02:21 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2554

Gray,

Please let me know if my previous email doesn't answer your question and
if it doesn't, then let me know which portion needs further
clarification.

-Ali 

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 8:01 AM
> To: Don Fedyk; Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Don,
> 
> 	And yet, someone (Ali Sajassi) asserted (in his message 
> dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues 
> or additional complications with using 802.1ah in enterprises 
> for plug-and-play applicability.
> 
> 	Perhaps Ali can answer my question then.
> 
> 	But, to more directly address your earlier comments:
> 
> 	The TRILL WG has NOT come up with an encapsulation that 
> "looks like" 802.1ah - unless someone squints really hard and 
> tries to pretend that two separate Ethernet encapsulations - 
> separated by a SHIM header - are one single encapsulation.
> 
> 	That is not to say that the WG has done anything that 
> could be said to disallow the use of 802.1ah encapsulation.
> It is just not obviously consistent with all of the WG goals 
> to use _only_ 802.1ah encapsulation.
> 
> --
> Eric
> 
> > -----Original Message-----
> > From: Don Fedyk [mailto:[email-masked]]
> > Sent: Thursday, December 07, 2006 9:33 AM
> > To: Gray, Eric; Joe Touch; Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > Hi Eric
> > 
> > > -----Original Message-----
> > > From: Gray, Eric [mailto:[email-masked]]
> > > Sent: Thursday, December 07, 2006 8:38 AM Don,
> > > 
> > > 	Thanks for doing this.  As you can probably attest, this is a 
> > > non-trivial "digging" task to come up with this level of 
> detail.  I 
> > > am not sure why Joe asked for it, but now that you have 
> provided it, 
> > > perhaps you can explain how values would be derived for the B-TAG 
> > > TCI/VID and I-TAG TCI/SID fields if we'd like to deploy this 
> > > technology in
> > "plug-and-play" mode?
> > 
> > I have not given much thought to plug-and-play. My advice would be 
> > learn the current semantics of the fields and see what they 
> offer.  I 
> > don't see why these fields, which offer encapsulation, backwards 
> > compatibility, Connectivity Fault Management (CFM) frames 
> etc are any 
> > worse than similar alternatives.
> > 
> > Don
> > 
> > > 
> > > --
> > > Eric
> > > 
> > ><snipped hopelessly garbled>
> > 
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 20:59:25 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1910

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 5:48 AM
> To: Joe Touch; Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Joe/Ali,
> 
> 	It is not as simple as this.
> 
> 	The IETF has already established a precedent for 
> Ethernet encapsulation of SHIM-encapsulated Ethernet.  It's 
> only trying to see this as a single encapsulation, that 
> causes people to conclude we are inventing a new form of 
> Ethernet encapsulation.
> 
> 	Other than inappropriate "designing committee" 
> discussion at the last IETF meeting, we have not been 
> attempting to design any new Ethernet encapsulation.  And I 
> believe we should safely conclude, at this point, that the 
> discussion that took place on this topic at the TRILL meeting 
> last month can be closed and considered to have been 
> completely unproductive.

I think it is always good to have discussions among ourselves to see how
we can leverage each other expertise and technology and whether what you
are doing can be leveraged in other applications. The basic premise in
here is that there is a good level of overlap among different areas that
are being worked on by different WGs, and we will do each other as well
as industry a great service if we can come up with a common solution
jointly.

-Ali

> 
> 	Big surprise...
> 
> --
> Eric
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Joe Touch
> > Sent: Wednesday, December 06, 2006 10:23 PM
> > To: Ali Sajassi (sajassi)
> > Cc: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 20:47:33 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Don Fedyk" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 6133

Gray,

With respect to plug-and-play operation, it is similar to 802.1Q or
802.1ad operation; where, at the UNI you decide which interfaces belong
to which VLANs in case of 802.1Q or which <interface, VLAN> pair belong
to S-tag in case of 802.1ad (e.g., point-to-cloud config model). In case
of 802.1ah, you also decide at the UNI which interfaces or which
<interface, vlan> pair belong to which <B-tag, I-SID> pair. Again the
model in 802.1ah is point-to-cloud model just like 802.1Q and 802.1ad
and that's what makes it plug-and-play.

-Ali  

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 5:38 AM
> To: Don Fedyk; Joe Touch; Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Don,
> 
> 	Thanks for doing this.  As you can probably attest, 
> this is a non-trivial "digging" task to come up with this 
> level of detail.  I am not sure why Joe asked for it, but now 
> that you have provided it, perhaps you can explain how values 
> would be derived for the B-TAG TCI/VID and I-TAG TCI/SID 
> fields if we'd like to deploy this technology in "plug-and-play" mode?
> 
> --
> Eric
> 
> > -----Original Message-----
> > From: Don Fedyk [mailto:[email-masked]]
> > Sent: Thursday, December 07, 2006 8:29 AM
> > To: Joe Touch; Ali Sajassi (sajassi)
> > Cc: Gray, Eric; Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > 
> > Hi
> > 
> > This is the Provider Backbone Header Format reproduced from 
> one of the 
> > 802.1ah documents.  When I said this is similar to the Trill header 
> > this is the version I mentioned.  I converted to 
> textographics by hand 
> > so I hope I got it right. I put field designators in [] inside the 
> > picture for fear they would get wrapped. The encapsulated 
> frame starts 
> > after the I-TAG I-SID.
> > 
> >     
> >     |      1        |       2       |       3       |       4 
> >       |  
> >     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  -2 |                               |                       
>         |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                       
>         +
> >   2 |                Backbone Destination Address         
> [B-DA]    |
> >     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >   6 |                Backbone Source Address              
> [B-SA]    |
> >     +                               
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  10 |                               |   .1ad Ethertype    
> [B-TAG]   |
> >     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  14 |  .1ad B-TAG TCI/VID           |   .1ah Ethertype    [ 
>   ]     |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ 
> I ]-+-+-+
> >  18 |               .1ah I-TAG TCI/SID                    [ 
> - ]     |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ 
> T ]-+-+-+
> >  22 |                Customer Destination Address         [ 
> A ]     |
> >     +                               +-+-+-+-+-+-+-+-+-+-+-[ 
> G ]-+-+-+
> >  26 |                               |                     [ 
>   ]     |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     [ 
>   ]     +
> >  30 |                Customer Source Address              [ 
>   ]     |
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ 
>   ]-+-+-+
> >  34 |  Encap Ethertype              |                     [   ]
> >     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> >                                 .1ah I-TAG TCI
> >     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     | P/DE  |R1 |R2 |                     I-SID             
>         |
> >     
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >     P/DE 3 Bits Priority 1 bit Drop Eligible
> >     R1 Res1
> >     R2 Res2
> > 
> > a) priority - This 3 bit field carries the customer 
> priority (I-PCP) 
> > associated with this frame. The provider network operates on the 
> > priority associated with the B-TAG.
> > 
> > b) drop_eligible - This 1 bit field carries the customer drop 
> > eligibility
> > (I-DEI) associated with this frame. The provider network 
> operates on 
> > the drop eligibility associated with the B-TAG.
> > 
> > c) res1 - This 2 bit field is used for any future format 
> variations. 
> > The
> > res2
> > field is zero on transmit and is ignored on receipt. 
> > 
> > d) res2 - This 2 bit field is used for any future format 
> variations. 
> > The
> > res1
> > field is zero on transmit and if set on reception the frame is 
> > discarded.
> > 
> > e) I-SID - This 24 bit field carries the service instance 
> identifier 
> > associated with this frame.
> > 
> > f) encapsulated C-DA - This field carries the 48 bit 
> Destination MAC 
> > Address for an encapsulated Ethernet frame.
> > 
> > g) encapsulated C-SA - This field carries the 48 bit Source MAC 
> > Address for an encapsulated Ethernet frame.
> > 
> > Regards,
> > Don
> > 
> > 
> > > -----Original Message-----
> > > From: Joe Touch [mailto:[email-masked]]
> > > Sent: Wednesday, December 06, 2006 9:53 PM
> > > To: Ali Sajassi (sajassi)
> > > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid 
> > > router/bridge.
> > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > 
> > > I'd really rather someone just posted the header / fields, rather 
> > > than a large document in which that information is buried, if 
> > > possible ;-)
> > > 
> > > Joe
> > > 
> > > Ali Sajassi (sajassi) wrote:
> > > > 
> > > >> Can you - or anyone with easy access to the specs -
> > please post an
> > > >> explicit description of 802.1ah header and fields?
> > > > 
> > > > I will ask Tony (802.1 chair) to make avail to TRILL WG a
> > > copy of .1ah.
> > > > 
> > > > -Ali
> > > > 
> > > > 
> > > >> Thanks,
> > > >>
> > > >> Joe
> > > >>
> > > >>
> > > 
> > > --
> > > ----------------------------------------
> > > Joe Touch
> > > Sr. Network Engineer, USAF TSAT Space Segment
> > > 
> > > 
> > 
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 20:39:17 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "Joe Touch" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 231433

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71A82.D650E4DF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached is the extraction from the 802.1ah spec. regarding header
format.

-Ali
=20

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]]=20
> Sent: Thursday, December 07, 2006 5:29 AM
> To: Joe Touch; Ali Sajassi (sajassi)
> Cc: Gray, Eric; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
>=20
> Hi=20
>=20
> This is the Provider Backbone Header Format reproduced from=20
> one of the 802.1ah documents.  When I said this is similar to=20
> the Trill header this is the version I mentioned.  I=20
> converted to textographics by hand so I hope I got it right.=20
> I put field designators in [] inside the picture for fear=20
> they would get wrapped. The encapsulated frame starts after=20
> the I-TAG I-SID.
>=20
>    =20
>     |      1        |       2       |       3       |       4=20
>       | =20
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  -2 |                               |                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
>   2 |                Backbone Destination Address         [B-DA]    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   6 |                Backbone Source Address              [B-SA]    |
>     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  10 |                               |   .1ad Ethertype    [B-TAG]   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  14 |  .1ad B-TAG TCI/VID           |   .1ah Ethertype    [   ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+
>  18 |               .1ah I-TAG TCI/SID                    [ - ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+
>  22 |                Customer Destination Address         [ A ]     |
>     +                               +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+
>  26 |                               |                     [   ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     [   ]     +
>  30 |                Customer Source Address              [   ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[   ]-+-+-+
>  34 |  Encap Ethertype              |                     [   ]
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>=20
>                                 .1ah I-TAG TCI
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | P/DE  |R1 |R2 |                     I-SID                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>     P/DE 3 Bits Priority 1 bit Drop Eligible
>     R1 Res1
>     R2 Res2
>=20
> a) priority - This 3 bit field carries the customer priority=20
> (I-PCP) associated with this frame. The provider network=20
> operates on the priority associated with the B-TAG. =20
>=20
> b) drop_eligible - This 1 bit field carries the customer drop=20
> eligibility
> (I-DEI) associated with this frame. The provider network=20
> operates on the drop eligibility associated with the B-TAG. =20
>=20
> c) res1 - This 2 bit field is used for any future format=20
> variations. The
> res2
> field is zero on transmit and is ignored on receipt.=20
>=20
> d) res2 - This 2 bit field is used for any future format=20
> variations. The
> res1
> field is zero on transmit and if set on reception the frame=20
> is discarded. =20
>=20
> e) I-SID - This 24 bit field carries the service instance=20
> identifier associated with this frame. =20
>=20
> f) encapsulated C-DA - This field carries the 48 bit=20
> Destination MAC Address for an encapsulated Ethernet frame. =20
>=20
> g) encapsulated C-SA - This field carries the 48 bit Source=20
> MAC Address for an encapsulated Ethernet frame. =20
>=20
> Regards,
> Don
>=20
>=20
> > -----Original Message-----
> > From: Joe Touch [mailto:[email-masked]]
> > Sent: Wednesday, December 06, 2006 9:53 PM
> > To: Ali Sajassi (sajassi)
> > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid=20
> > router/bridge.
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> >=20
> > I'd really rather someone just posted the header / fields,=20
> rather than=20
> > a large document in which that information is buried, if=20
> possible ;-)
> >=20
> > Joe
> >=20
> > Ali Sajassi (sajassi) wrote:
> > >=20
> > >> Can you - or anyone with easy access to the specs -=20
> please post an=20
> > >> explicit description of 802.1ah header and fields?
> > >=20
> > > I will ask Tony (802.1 chair) to make avail to TRILL WG a
> > copy of .1ah.
> > >=20
> > > -Ali
> > >=20
> > >=20
> > >> Thanks,
> > >>
> > >> Joe
> > >>
> > >>
> >=20
> > --
> > ----------------------------------------
> > Joe Touch
> > Sr. Network Engineer, USAF TSAT Space Segment
> >=20
> >=20
>=20

------_=_NextPart_001_01C71A82.D650E4DF
Content-Type: application/msword;
	name="802-1ah-header.doc"
Content-Transfer-Encoding: base64
Content-Description: 802-1ah-header.doc
Content-Disposition: attachment;
	filename="802-1ah-header.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAQQEAAAAAAAAA
EAAAQwEAAAEAAAD+////AAAAADoBAAA7AQAAQgEAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////AQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAAAP7/////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAA

------_=_NextPart_001_01C71A82.D650E4DF--

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 17:35:54 -0800
From: "Silvano Gai" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "Gray, Eric" <[email-masked]>, "Ali Sajassi \(sajassi\)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2503

IMO it is technically possible for TRILL to adopt IEEE 802.1ah. 
There are advantages and disadvantages.

The disadvantages are:
1) Lack of Next-Hop addresses. We discussed this at length during the
last meeting and we didn't reach consensus on a way to eliminate them.
2) Lack of a TTL field (it may be added, but it is not there today).
3) Many unneeded fields and therefore larger frame overhead.

The advantages are:
1) Larger addressable market for TRILL

IMO if we stick with the WG charter the disadvantages clearly outweigh
the advantages.

The WG can be re-chartered, but if we consider the Enterprise and Data
Center market, IEEE 802.1ah is an overkill.

-- Silvano

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Don Fedyk
> Sent: Thursday, December 07, 2006 9:21 AM
> To: Gray, Eric; Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.; Joe Touch
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> Hi Eric
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]]
> >
> > Don,
> >
> > 	And yet, someone (Ali Sajassi) asserted (in his message
> > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues
> > or additional complications with using 802.1ah in enterprises
> > for plug-and-play applicability.
> >
> > 	Perhaps Ali can answer my question then.
> >
> > 	But, to more directly address your earlier comments:
> >
> > 	The TRILL WG has NOT come up with an encapsulation that
> > "looks like" 802.1ah - unless someone squints really hard and
> > tries to pretend that two separate Ethernet encapsulations -
> > separated by a SHIM header - are one single encapsulation.
> 
> To be fair Point to Point header that was discussed without one of the
> shims was very close "functionally" (colloquial looks like) to
802.1ah.
> My opinion is still we don't need several variations of headers doing
> similar things.
> 
> This was the slide that looked a lot like what I posted.
> 
> http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> 
> Regards,
> Don
> >
> > 	That is not to say that the WG has done anything that
> > could be said to disallow the use of 802.1ah encapsulation.
> > It is just not obviously consistent with all of the WG goals
> > to use _only_ 802.1ah encapsulation.
> >
> > --
> > Eric
> >
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 7 Dec 2006 13:34:06 -0500 
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2515

Don,

	I think we're not disagreeing with each other.

	Where people make proposals that look like an existing
encapsulation, the complexity associated with defining a new
encapsulation that is marginally different has to be weighed
very carefully against what we expect to gain in doing so.

	I think it is clear to me that the complexity is not
justified.  Moreover, I don't see anyone continuing to make
the case that we should do this - so it may be the case that
many people are of a similar opinion.

	The issue of whether or not it makes sense to use the
specific encapsulation proposed - or an existing similar
encapsulation - in the RBridge problem domain is a horse of
a different color.  I am not sure that we've achieved any
level of agreement on this issue, consequently this entire
discussion could be considered simply as a distraction.

--
Eric

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 12:21 PM
> To: Gray, Eric; Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Hi Eric 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > 
> > Don,
> > 
> > 	And yet, someone (Ali Sajassi) asserted (in his message 
> > dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues 
> > or additional complications with using 802.1ah in enterprises 
> > for plug-and-play applicability.
> > 
> > 	Perhaps Ali can answer my question then.
> > 
> > 	But, to more directly address your earlier comments:
> > 
> > 	The TRILL WG has NOT come up with an encapsulation that 
> > "looks like" 802.1ah - unless someone squints really hard and 
> > tries to pretend that two separate Ethernet encapsulations - 
> > separated by a SHIM header - are one single encapsulation.
> 
> To be fair Point to Point header that was discussed without one of the
> shims was very close "functionally" (colloquial looks like) 
> to 802.1ah.
> My opinion is still we don't need several variations of headers doing
> similar things. 
> 
> This was the slide that looked a lot like what I posted.  
> 
> http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> 
> Regards,
> Don 
> > 
> > 	That is not to say that the WG has done anything that 
> > could be said to disallow the use of 802.1ah encapsulation.
> > It is just not obviously consistent with all of the WG goals 
> > to use _only_ 802.1ah encapsulation.
> > 
> > --
> > Eric
> > 
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 12:20:52 -0500
From: "Don Fedyk" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Ali Sajassi \(sajassi\)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1303

Hi Eric 

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> 
> Don,
> 
> 	And yet, someone (Ali Sajassi) asserted (in his message 
> dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues 
> or additional complications with using 802.1ah in enterprises 
> for plug-and-play applicability.
> 
> 	Perhaps Ali can answer my question then.
> 
> 	But, to more directly address your earlier comments:
> 
> 	The TRILL WG has NOT come up with an encapsulation that 
> "looks like" 802.1ah - unless someone squints really hard and 
> tries to pretend that two separate Ethernet encapsulations - 
> separated by a SHIM header - are one single encapsulation.

To be fair Point to Point header that was discussed without one of the
shims was very close "functionally" (colloquial looks like) to 802.1ah.
My opinion is still we don't need several variations of headers doing
similar things. 

This was the slide that looked a lot like what I posted.  

http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm

Regards,
Don 
> 
> 	That is not to say that the WG has done anything that 
> could be said to disallow the use of 802.1ah encapsulation.
> It is just not obviously consistent with all of the WG goals 
> to use _only_ 802.1ah encapsulation.
> 
> --
> Eric
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 11:24:47 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Use of 802.11s Encaps
Status: RO
Content-Length: 308

As long as people are looking at encapsulations, how about the
encapsulation currently in the 802.11s draft? It has lots of nifty
fields including six addresses and a TTL!  Although the Draft is
restricted, see
ftp://ftp.802wirelessworld.com/11/06/11-06-1464-02-000s-6-address-scheme
-tgs-mesh.doc.

Donald

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 7 Dec 2006 11:00:36 -0500 
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1997

Don,

	And yet, someone (Ali Sajassi) asserted (in his message
dated Wed 12/6/2006 at 2:16 PM EST) that there were no issues  
or additional complications with using 802.1ah in enterprises
for plug-and-play applicability.

	Perhaps Ali can answer my question then.

	But, to more directly address your earlier comments:

	The TRILL WG has NOT come up with an encapsulation that 
"looks like" 802.1ah - unless someone squints really hard and 
tries to pretend that two separate Ethernet encapsulations - 
separated by a SHIM header - are one single encapsulation.

	That is not to say that the WG has done anything that 
could be said to disallow the use of 802.1ah encapsulation.
It is just not obviously consistent with all of the WG goals
to use _only_ 802.1ah encapsulation.

--
Eric

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 9:33 AM
> To: Gray, Eric; Joe Touch; Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Hi Eric
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:[email-masked]] 
> > Sent: Thursday, December 07, 2006 8:38 AM
> > Don,
> > 
> > 	Thanks for doing this.  As you can probably attest, 
> > this is a non-trivial "digging" task to come up with this 
> > level of detail.  I am not sure why Joe asked for it, but now 
> > that you have provided it, perhaps you can explain how values 
> > would be derived for the B-TAG TCI/VID and I-TAG TCI/SID 
> > fields if we'd like to deploy this technology in 
> "plug-and-play" mode?
> 
> I have not given much thought to plug-and-play. My advice 
> would be learn
> the current semantics of the fields and see what they offer.  I don't
> see why these fields, which offer encapsulation, backwards
> compatibility, Connectivity Fault Management (CFM) frames etc are any
> worse than similar alternatives.
> 
> Don
> 
> > 
> > --
> > Eric
> > 
> ><snipped hopelessly garbled> 
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 09:32:53 -0500
From: "Don Fedyk" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Joe Touch" <[email-masked]>, "Ali Sajassi \(sajassi\)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 885

Hi Eric

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 8:38 AM
> Don,
> 
> 	Thanks for doing this.  As you can probably attest, 
> this is a non-trivial "digging" task to come up with this 
> level of detail.  I am not sure why Joe asked for it, but now 
> that you have provided it, perhaps you can explain how values 
> would be derived for the B-TAG TCI/VID and I-TAG TCI/SID 
> fields if we'd like to deploy this technology in "plug-and-play" mode?

I have not given much thought to plug-and-play. My advice would be learn
the current semantics of the fields and see what they offer.  I don't
see why these fields, which offer encapsulation, backwards
compatibility, Connectivity Fault Management (CFM) frames etc are any
worse than similar alternatives.

Don

> 
> --
> Eric
> 
><snipped hopelessly garbled> 

Date: Thu, 07 Dec 2006 15:22:31 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: Stewart Bryant <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 521

Yes but, could you be a bit more precise ? (there are so many "VLANs" in 
the headers :-) ). Do you mean a different protocol type than .1ah (81a8)?
Guillermo
Stewart Bryant escribi?:
> Guillermo Ib??ez wrote:
>
>> There is no TTL field on the 802.1ah, afaik, so the .1ah would 
>> require modification.
>
> ... or perhaps extension through the header extension mechanism
> used to introduce VLANs. i.e. new protocol type that introduces
> the TTL header which carries the TTL and the next protocol type.
>
> - Stewart
>

From: "Gray, Eric" <[email-masked]>
To: Joe Touch <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 7 Dec 2006 08:48:15 -0500 
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1119

Joe/Ali,

	It is not as simple as this.

	The IETF has already established a precedent for Ethernet
encapsulation of SHIM-encapsulated Ethernet.  It's only trying
to see this as a single encapsulation, that causes people to
conclude we are inventing a new form of Ethernet encapsulation.

	Other than inappropriate "designing committee" discussion
at the last IETF meeting, we have not been attempting to design
any new Ethernet encapsulation.  And I believe we should safely
conclude, at this point, that the discussion that took place on
this topic at the TRILL meeting last month can be closed and
considered to have been completely unproductive.

	Big surprise...

--
Eric

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Wednesday, December 06, 2006 10:23 PM
> To: Ali Sajassi (sajassi)
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

From: "Gray, Eric" <[email-masked]>
To: Don Fedyk <[email-masked]>, Joe Touch <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 7 Dec 2006 08:38:08 -0500 
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 4977

Don,

	Thanks for doing this.  As you can probably attest, this
is a non-trivial "digging" task to come up with this level of
detail.  I am not sure why Joe asked for it, but now that you
have provided it, perhaps you can explain how values would be
derived for the B-TAG TCI/VID and I-TAG TCI/SID fields if we'd
like to deploy this technology in "plug-and-play" mode?

--
Eric

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 8:29 AM
> To: Joe Touch; Ali Sajassi (sajassi)
> Cc: Gray, Eric; Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Hi 
> 
> This is the Provider Backbone Header Format reproduced from one of the
> 802.1ah documents.  When I said this is similar to the Trill 
> header this
> is the version I mentioned.  I converted to textographics by hand so I
> hope I got it right. I put field designators in [] inside the picture
> for fear they would get wrapped. The encapsulated frame 
> starts after the
> I-TAG I-SID.
> 
>     
>     |      1        |       2       |       3       |       4 
>       |  
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  -2 |                               |                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
>   2 |                Backbone Destination Address         [B-DA]    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   6 |                Backbone Source Address              [B-SA]    |
>     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  10 |                               |   .1ad Ethertype    [B-TAG]   |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  14 |  .1ad B-TAG TCI/VID           |   .1ah Ethertype    [   ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+
>  18 |               .1ah I-TAG TCI/SID                    [ - ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+
>  22 |                Customer Destination Address         [ A ]     |
>     +                               +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+
>  26 |                               |                     [   ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     [   ]     +
>  30 |                Customer Source Address              [   ]     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[   ]-+-+-+
>  34 |  Encap Ethertype              |                     [   ]
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>                                 .1ah I-TAG TCI
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | P/DE  |R1 |R2 |                     I-SID                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     P/DE 3 Bits Priority 1 bit Drop Eligible
>     R1 Res1
>     R2 Res2
> 
> a) priority - This 3 bit field carries the customer priority (I-PCP)
> associated
> with this frame. The provider network operates on the priority
> associated with
> the B-TAG.  
> 
> b) drop_eligible - This 1 bit field carries the customer drop
> eligibility
> (I-DEI) associated with this frame. The provider network 
> operates on the
> drop
> eligibility associated with the B-TAG.  
> 
> c) res1 - This 2 bit field is used for any future format 
> variations. The
> res2
> field is zero on transmit and is ignored on receipt. 
> 
> d) res2 - This 2 bit field is used for any future format 
> variations. The
> res1
> field is zero on transmit and if set on reception the frame is
> discarded.  
> 
> e) I-SID - This 24 bit field carries the service instance identifier
> associated
> with this frame.  
> 
> f) encapsulated C-DA - This field carries the 48 bit Destination MAC
> Address
> for an encapsulated Ethernet frame.  
> 
> g) encapsulated C-SA - This field carries the 48 bit Source 
> MAC Address
> for an
> encapsulated Ethernet frame.  
> 
> Regards,
> Don
> 
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[email-masked]] 
> > Sent: Wednesday, December 06, 2006 9:53 PM
> > To: Ali Sajassi (sajassi)
> > Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid 
> > router/bridge.
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > 
> > I'd really rather someone just posted the header / fields, 
> > rather than a large document in which that information is 
> > buried, if possible ;-)
> > 
> > Joe
> > 
> > Ali Sajassi (sajassi) wrote:
> > > 
> > >> Can you - or anyone with easy access to the specs - 
> please post an 
> > >> explicit description of 802.1ah header and fields?
> > > 
> > > I will ask Tony (802.1 chair) to make avail to TRILL WG a 
> > copy of .1ah.
> > > 
> > > -Ali
> > > 
> > > 
> > >> Thanks,
> > >>
> > >> Joe
> > >>
> > >>
> > 
> > --
> > ----------------------------------------
> > Joe Touch
> > Sr. Network Engineer, USAF TSAT Space Segment
> > 
> > 
> 

Content-class: urn:content-classes:message
Date: Thu, 7 Dec 2006 08:28:30 -0500
From: "Don Fedyk" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Ali Sajassi \(sajassi\)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 4076

Hi 

This is the Provider Backbone Header Format reproduced from one of the
802.1ah documents.  When I said this is similar to the Trill header this
is the version I mentioned.  I converted to textographics by hand so I
hope I got it right. I put field designators in [] inside the picture
for fear they would get wrapped. The encapsulated frame starts after the
I-TAG I-SID.

    |      1        |       2       |       3       |       4       |  
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 -2 |                               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  2 |                Backbone Destination Address         [B-DA]    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  6 |                Backbone Source Address              [B-SA]    |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 10 |                               |   .1ad Ethertype    [B-TAG]   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 14 |  .1ad B-TAG TCI/VID           |   .1ah Ethertype    [   ]     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ I ]-+-+-+
 18 |               .1ah I-TAG TCI/SID                    [ - ]     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[ T ]-+-+-+
 22 |                Customer Destination Address         [ A ]     |
    +                               +-+-+-+-+-+-+-+-+-+-+-[ G ]-+-+-+
 26 |                               |                     [   ]     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     [   ]     +
 30 |                Customer Source Address              [   ]     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-[   ]-+-+-+
 34 |  Encap Ethertype              |                     [   ]
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                .1ah I-TAG TCI
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | P/DE  |R1 |R2 |                     I-SID                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    P/DE 3 Bits Priority 1 bit Drop Eligible
    R1 Res1
    R2 Res2

a) priority - This 3 bit field carries the customer priority (I-PCP)
associated
with this frame. The provider network operates on the priority
associated with
the B-TAG.  

b) drop_eligible - This 1 bit field carries the customer drop
eligibility
(I-DEI) associated with this frame. The provider network operates on the
drop
eligibility associated with the B-TAG.  

c) res1 - This 2 bit field is used for any future format variations. The
res2
field is zero on transmit and is ignored on receipt. 

d) res2 - This 2 bit field is used for any future format variations. The
res1
field is zero on transmit and if set on reception the frame is
discarded.  

e) I-SID - This 24 bit field carries the service instance identifier
associated
with this frame.  

f) encapsulated C-DA - This field carries the 48 bit Destination MAC
Address
for an encapsulated Ethernet frame.  

g) encapsulated C-SA - This field carries the 48 bit Source MAC Address
for an
encapsulated Ethernet frame.  

Regards,
Don

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 9:53 PM
> To: Ali Sajassi (sajassi)
> Cc: Fedyk, Don (BL60:1A00); Gray, Eric; Developing a hybrid 
> router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> I'd really rather someone just posted the header / fields, 
> rather than a large document in which that information is 
> buried, if possible ;-)
> 
> Joe
> 
> Ali Sajassi (sajassi) wrote:
> > 
> >> Can you - or anyone with easy access to the specs - please post an 
> >> explicit description of 802.1ah header and fields?
> > 
> > I will ask Tony (802.1 chair) to make avail to TRILL WG a 
> copy of .1ah.
> > 
> > -Ali
> > 
> > 
> >> Thanks,
> >>
> >> Joe
> >>
> >>
> 
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
> 
> 

Date: Thu, 07 Dec 2006 14:16:08 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 200903

This is a multi-part message in MIME format.
--------------010507050502060406060802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Attached is a  figure on the 802.1ad and .1ah headers, extracted from 
the Comms. Magazine. You can find also more details on the fields 
specific of .1ah header, extracted from 802.1ah draft 3.0
Note that I-SID Instance Service ID, has three octets, possibly to 
overcome the limitation that a single VLAN field (12 bit: 4096)  (2 byte 
type+ 2 byte VLAN tag)) would suppose.
Guillermo

Joe Touch escribi?:
> Ali Sajassi (sajassi) wrote:
> ...
>   
>>>> Hmmm Trill spent 1.5 years coming up with a header that looks 
>>>> remarkably like 802.1ah. A fact many of us have pointed out 
>>>>         
>>> before.  
>>>       
>>>> If you are using an IEEE 802.1 Ethernet data plane your baseline 
>>>> choices are 802.1Q or 802.1ah.
>>>>         
>>> Is there a TTL in the 802.1ah header?
>>>       
>> Currently it is not. But if this is an issue, we can try to accommodate
>> it.
>>     
>
> So maybe that 1.5 years wasn't wasted after all? :-)
>
> Joe
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

--------------010507050502060406060802
Content-Type: application/pdf;
 name="8021ah_header.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="8021ah_header.pdf"

--------------010507050502060406060802
Content-Type: application/pdf;
 name="8021ah.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="8021ah.pdf"

--------------010507050502060406060802--

Date: Wed, 06 Dec 2006 19:23:21 -0800
From: Joe Touch <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1184

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4E8B82C6F235020C0C63480F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Ali Sajassi (sajassi) wrote:
=2E..
>>> Hmmm Trill spent 1.5 years coming up with a header that looks=20
>>> remarkably like 802.1ah. A fact many of us have pointed out=20
>> before. =20
>>> If you are using an IEEE 802.1 Ethernet data plane your baseline=20
>>> choices are 802.1Q or 802.1ah.
>> Is there a TTL in the 802.1ah header?
>=20
> Currently it is not. But if this is an issue, we can try to accommodate=

> it.

So maybe that 1.5 years wasn't wasted after all? :-)

Joe

--------------enig4E8B82C6F235020C0C63480F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig4E8B82C6F235020C0C63480F--

Date: Wed, 06 Dec 2006 18:52:33 -0800
From: Joe Touch <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1244

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0662071E35908E95EF411E3D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'd really rather someone just posted the header / fields, rather than a
large document in which that information is buried, if possible ;-)

Joe

Ali Sajassi (sajassi) wrote:
>=20
>> Can you - or anyone with easy access to the specs - please=20
>> post an explicit description of 802.1ah header and fields?
>=20
> I will ask Tony (802.1 chair) to make avail to TRILL WG a copy of .1ah.=

>=20
> -Ali
>=20
>=20
>> Thanks,
>> Joe

--=20
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

--------------enig0662071E35908E95EF411E3D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0662071E35908E95EF411E3D--

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 15:24:07 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2542

Hi Don,

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Don Fedyk
Sent: Wednesday, December 06, 2006 11:15 AM
To: Gray, Eric; Ali Sajassi (sajassi)
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Use of 802.1ah Encaps

Hi Eric 

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> 
> Ali/Don,
> 
> 	The use of 802.1ah encapsulation does not intuitively suggest
itself 
> in the TRILL problem domain for at least two
> reasons:
> 
> 1)	Provider Back-bone Bridging intuitively seems out of
> 	place in solutions aimed at enterprise networks - and
> 	this would seem to be even more true for solutions 
> 	aimed at "plug-and-play" applicability.

Hmmm Trill spent 1.5 years coming up with a header that looks remarkably
like 802.1ah. A fact many of us have pointed out before.  If you are
using an IEEE 802.1 Ethernet data plane your baseline choices are 802.1Q
or 802.1ah. 

@@@ That might be the baseline in IEEE 802.1 but I don't think it is in
IETF TRILL. I think the TRILL Charter states that our baseline is
draft-perlman-rbridge-03.txt, still available at
http://www.postel.org/rbridge/draft-perlman-rbridge-03.txt, although
that draft is not very specific about the encapsulation format.

@@@ Of course we can and have evolved from that baseline. (For example,
I assess the WG as leaning very strongly to the inclusion of two rbridge
designators.) And if there is an existing encapsulation format that
meets our needs, there is no particular reason to invent one. That is
why we were planning for a while on using an MPLS format. But 802.1ah
does not look much like the Rbridge shim (or Rbridge shim plus following
MAC addresses) to me. Perhaps I am just missing something but have the
"many" people you say have "pointed out" that we should just use the
802.1ah header actually proposed a specific allocation of its fields?
(for current ideas on Rbridge shim fields look at presentations in San
Diego such as
http://www3.ietf.org/proceedings/06nov/slides/trill-2/sld2.htm or
http://www3.ietf.org/proceedings/06nov/slides/trill-3/sld8.htm)

@@@ I would point out that, when we were discussing the MPLS
encapsulation, some who had originally advocated it as a way of re-using
hardware and the like later came to the conclusion that if it had to
have a different Ethertype and/or fields that are differently
interpreted, there was actually very little saving.

@@@ Thanks,
@@@ Donald

...

> > > Regards,
> > > Don

Date: Wed, 06 Dec 2006 19:35:02 +0000
From: Stewart Bryant <[email-masked]>
To: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 321

Guillermo Ib??ez wrote:

> There is no TTL field on the 802.1ah, afaik, so the .1ah would require 
> modification.

... or perhaps extension through the header extension mechanism
used to introduce VLANs. i.e. new protocol type that introduces
the TTL header which carries the TTL and the next protocol type.

- Stewart

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 14:34:49 -0500
From: "Don Fedyk" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 870

Hi Erik

See I addition below: 

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 1:03 PM
> 
> Don Fedyk wrote:
> > Hi Erik
> > 
> > In the minutes: 
> > 802.1ah header synergy?  On this point myself, and I recall Ali 
> > Sajassi and Donald Oconnor all stood up and said that 
> 802.1ah is going 
> > to be a standard encapsulation header. My point was Trill 
> should see 
> > what it could deliver on this encapsulation before 
> inventing similar 
> > but different headers.
> 
> I've added this:
> 
> "802.1ah header synergy?
> Comments from Don Fedyk, Ali Sajassi and Donald Oconnor that 
> 802.1ah is going to be a standard encapsulation header."
> 
> which is what I think you said that you said.

Correct and the fact that we think it should be looked at by Trill. 

Don

>     Erik

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 11:32:07 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 1621

> 
> There is no TTL field on the 802.1ah, afaik, so the .1ah 
> would require modification.

As mentioned in my previous email, if this is an issue, we can try to accommodate it. Is there anything else ?

-Ali

> Guillermo
> 
> Ali Sajassi (sajassi) escribi?:
> >  
> > 
> > 
> > Yes, if there is any reason as to why .1ah encap cannot be 
> used, then 
> > I would like to hear it.
> > 
> > -Ali
> > 
> > 
> > 
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Don Fedyk
> >> Sent: Tuesday, December 05, 2006 10:17 AM
> >> To: Developing a hybrid router/bridge.
> >> Subject: Re: [rbridge] Draft minutes posted
> >>
> >> Hi Erik
> >>
> >> In the minutes: 
> >> 802.1ah header synergy?  On this point myself, and I recall Ali 
> >> Sajassi and Donald Oconnor all stood up and said that 802.1ah is 
> >> going to be a standard encapsulation header. My point was Trill 
> >> should see what it could deliver on this encapsulation before 
> >> inventing similar but different headers.
> >>
> >> Regards,
> >> Don
> >>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> >>>
> >>> Any corrections?
> >>>
> >>>     Erik
> >>>
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 11:28:07 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 1189

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 10:02 AM
> To: Don Fedyk
> Cc: Gray, Eric; Ali Sajassi (sajassi); Developing a hybrid 
> router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> Don Fedyk wrote:
> > Hi Eric
> > 
> >> -----Original Message-----
> >> From: Gray, Eric [mailto:[email-masked]]
> >>
> >> Ali/Don,
> >>
> >> 	The use of 802.1ah encapsulation does not intuitively 
> suggest itself 
> >> in the TRILL problem domain for at least two
> >> reasons:
> >>
> >> 1)	Provider Back-bone Bridging intuitively seems out of
> >> 	place in solutions aimed at enterprise networks - and
> >> 	this would seem to be even more true for solutions 
> >> 	aimed at "plug-and-play" applicability.
> > Hmmm Trill spent 1.5 years coming up with a header that looks 
> > remarkably like 802.1ah. A fact many of us have pointed out 
> before.  
> > If you are using an IEEE 802.1 Ethernet data plane your baseline 
> > choices are 802.1Q or 802.1ah.
> 
> Is there a TTL in the 802.1ah header?

Currently it is not. But if this is an issue, we can try to accommodate
it.

-Ali

>     Erik

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 11:25:54 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Joe Touch" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 238

> 
> Can you - or anyone with easy access to the specs - please 
> post an explicit description of 802.1ah header and fields?

I will ask Tony (802.1 chair) to make avail to TRILL WG a copy of .1ah.

-Ali

> Thanks,
> Joe

Date: Wed, 06 Dec 2006 20:16:25 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 1385

There is no TTL field on the 802.1ah, afaik, so the .1ah would require 
modification.
Guillermo

Ali Sajassi (sajassi) escribi?:
>  
> 
> 
> Yes, if there is any reason as to why .1ah encap cannot be used, then I
> would like to hear it.
> 
> -Ali 
> 
> 
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Don Fedyk
>> Sent: Tuesday, December 05, 2006 10:17 AM
>> To: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Draft minutes posted
>>
>> Hi Erik
>>
>> In the minutes: 
>> 802.1ah header synergy?  On this point myself, and I recall 
>> Ali Sajassi and Donald Oconnor all stood up and said that 
>> 802.1ah is going to be a standard encapsulation header. My 
>> point was Trill should see what it could deliver on this 
>> encapsulation before inventing similar but different headers.
>>
>> Regards,
>> Don  
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
>>>
>>> Any corrections?
>>>
>>>     Erik
>>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 11:15:51 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3981

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 5:45 AM
> To: Ali Sajassi (sajassi); Don Fedyk
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Ali/Don,
> 
> 	The use of 802.1ah encapsulation does not intuitively 
> suggest itself in the TRILL problem domain for at least two
> reasons:
> 
> 1)	Provider Back-bone Bridging intuitively seems out of
> 	place in solutions aimed at enterprise networks - and
> 	this would seem to be even more true for solutions 
> 	aimed at "plug-and-play" applicability.

802.1ah can equally be used in enterprise network with the same
plug-and-play ease of use. If you think otherwise, please elaborate what
part of 802.1ah is not suitable for such applications. 

> 
> 2)	Use of 802.1ah encapsulation assumes "bridging" of the
> 	tunneled frame transparently from edge-to-edge - and
> 	this would seem to go counter to the idea of using a
> 	link-state routing protocol for shortest path routing
> 	of MAC frames.
> 

802.1ah primarily specifies the data-plane functionality. The use of
link-state control-plane is independent from data-plane specification
and one can easily use a link-state routing protocol with 802.1ah encap.
As the mater of fact 802.aq is a step in this direction and this would
be an area of mutual interest between the two working groups. 

> 	That said, the minute that we start suggesting that an 
> enterprise is large enough to require using service provider
> (like) solutions (in particular, requiring a substantial 
> back-bone capacity, and assuming static configuration as a 
> means to ensure deterministic network behavior) - OR that we 
> might in fact use some form of spanning tree forwarding - it 
> then becomes clear that we should consider using 802.1ah.  It 
> is certainly the case that we should not be defining another 
> Ethernet encapsulation explicitly to solve the same problem.

As mentioned before, the use of 802.1ah does not mandate the use of
spanning tree - link-state protocol can be used as well with the same
plug-and-play objectives. I think the convergence in here is a good
thing and the industry can benefit as whole.

-Ali  

> 
> --
> Eric
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Ali 
> Sajassi (sajassi)
> > Sent: Wednesday, December 06, 2006 2:39 AM
> > To: Don Fedyk; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Draft minutes posted
> > 
> >  
> > 
> > 
> > Yes, if there is any reason as to why .1ah encap cannot be 
> > used, then I
> > would like to hear it.
> > 
> > -Ali 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Don Fedyk
> > > Sent: Tuesday, December 05, 2006 10:17 AM
> > > To: Developing a hybrid router/bridge.
> > > Subject: Re: [rbridge] Draft minutes posted
> > > 
> > > Hi Erik
> > > 
> > > In the minutes: 
> > > 802.1ah header synergy?  On this point myself, and I recall 
> > > Ali Sajassi and Donald Oconnor all stood up and said that 
> > > 802.1ah is going to be a standard encapsulation header. My 
> > > point was Trill should see what it could deliver on this 
> > > encapsulation before inventing similar but different headers.
> > > 
> > > Regards,
> > > Don  
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> > > > 
> > > > Any corrections?
> > > > 
> > > >     Erik
> > > > 
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > [email-masked]
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 

Date: Wed, 06 Dec 2006 10:02:47 -0800
From: Erik Nordmark <[email-masked]>
To: Don Fedyk <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 574

Don Fedyk wrote:
> Hi Erik
> 
> In the minutes: 
> 802.1ah header synergy?  On this point myself, and I recall Ali Sajassi
> and Donald Oconnor all stood up and said that 802.1ah is going to be a
> standard encapsulation header. My point was Trill should see what it
> could deliver on this encapsulation before inventing similar but
> different headers.

I've added this:

"802.1ah header synergy?
Comments from Don Fedyk, Ali Sajassi and Donald Oconnor that 802.1ah is
going to be a standard encapsulation header."

which is what I think you said that you said.

    Erik

Date: Wed, 06 Dec 2006 10:01:53 -0800
From: Erik Nordmark <[email-masked]>
To: Don Fedyk <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 770

Don Fedyk wrote:
> Hi Eric 
> 
>> -----Original Message-----
>> From: Gray, Eric [mailto:[email-masked]] 
>>
>> Ali/Don,
>>
>> 	The use of 802.1ah encapsulation does not intuitively 
>> suggest itself in the TRILL problem domain for at least two
>> reasons:
>>
>> 1)	Provider Back-bone Bridging intuitively seems out of
>> 	place in solutions aimed at enterprise networks - and
>> 	this would seem to be even more true for solutions 
>> 	aimed at "plug-and-play" applicability.
> Hmmm Trill spent 1.5 years coming up with a header that looks remarkably
> like 802.1ah. A fact many of us have pointed out before.  If you are
> using an IEEE 802.1 Ethernet data plane your baseline choices are 802.1Q
> or 802.1ah. 

Is there a TTL in the 802.1ah header?

    Erik

Date: Wed, 06 Dec 2006 17:49:50 +0000
From: Stewart Bryant <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 907

Gray, Eric wrote:

> Ali/Don,
> 
> 	The use of 802.1ah encapsulation does not intuitively
> suggest itself in the TRILL problem domain for at least two
> reasons:
> 
> 1)	Provider Back-bone Bridging intuitively seems out of
> 	place in solutions aimed at enterprise networks - and
> 	this would seem to be even more true for solutions 
> 	aimed at "plug-and-play" applicability.

... but what has that to do with the encapsulation mechanism?

> 
> 2)	Use of 802.1ah encapsulation assumes "bridging" of the
> 	tunneled frame transparently from edge-to-edge - and
> 	this would seem to go counter to the idea of using a
> 	link-state routing protocol for shortest path routing
> 	of MAC frames.

Why so? There are many existance proofs that the choice of
encap and the choice of topology protocol are othogonal.
The only requirement is that the encap carries the necessary
per packet information.

- Stewart

Date: Wed, 06 Dec 2006 09:25:25 -0800
From: Joe Touch <[email-masked]>
To: Don Fedyk <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 953

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5076F6CDAD914F067DF8D487
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Don Fedyk wrote:
=2E..
> Hmmm Trill spent 1.5 years coming up with a header that looks remarkabl=
y
> like 802.1ah.

Can you - or anyone with easy access to the specs - please post an
explicit description of 802.1ah header and fields?

Thanks,

Joe

--------------enig5076F6CDAD914F067DF8D487
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5076F6CDAD914F067DF8D487--

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 11:51:03 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Gray, Eric" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 1614

Sure, That would be the ideal thing, with messages having this subject
only about the accuracy of the minutes is recording what generally
happened at the meeting and technical subjects in other threads with
different subject lines. But it is usually hard to get people to
constrain themselves that way.

Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gray, Eric
Sent: Tuesday, December 05, 2006 4:19 PM
To: Erik Nordmark
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Draft minutes posted

Erik,

	Can I suggest that we should use a different thread
- perhaps later (in a few days) - to address issues with the what was
said during the meeting, that we might have disagreed with but did not
have time to discuss?

	Meanwhile, we should use this thread only to talk about
clarifying or correcting what was reportedly said during the meeting.

	Does that make sense?

--
Eric 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Tuesday, December 05, 2006 12:59 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Draft minutes posted
> 
> 
> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> 
> Any corrections?
> 
>     Erik
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

Content-class: urn:content-classes:message
Date: Wed, 6 Dec 2006 11:14:39 -0500
From: "Don Fedyk" <[email-masked]>
To: "Gray, Eric" <[email-masked]>, "Ali Sajassi \(sajassi\)" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 3197

Hi Eric 

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]] 
> 
> Ali/Don,
> 
> 	The use of 802.1ah encapsulation does not intuitively 
> suggest itself in the TRILL problem domain for at least two
> reasons:
> 
> 1)	Provider Back-bone Bridging intuitively seems out of
> 	place in solutions aimed at enterprise networks - and
> 	this would seem to be even more true for solutions 
> 	aimed at "plug-and-play" applicability.
Hmmm Trill spent 1.5 years coming up with a header that looks remarkably
like 802.1ah. A fact many of us have pointed out before.  If you are
using an IEEE 802.1 Ethernet data plane your baseline choices are 802.1Q
or 802.1ah. 

> 
> 2)	Use of 802.1ah encapsulation assumes "bridging" of the
> 	tunneled frame transparently from edge-to-edge - and
> 	this would seem to go counter to the idea of using a
> 	link-state routing protocol for shortest path routing
> 	of MAC frames.
Encapsulation and the use of link state are orthogonal concepts so I
disagree. 

> 
> 	That said, the minute that we start suggesting that an 
> enterprise is large enough to require using service provider
> (like) solutions (in particular, requiring a substantial 
> back-bone capacity, and assuming static configuration as a 
> means to ensure deterministic network behavior) - OR that we 
> might in fact use some form of spanning tree forwarding - it 
> then becomes clear that we should consider using 802.1ah.  It 
> is certainly the case that we should not be defining another 
> Ethernet encapsulation explicitly to solve the same problem.

What we should be worried about is solutions for commoditized
encapsulated header. Ethernet has benefited in the past by having a wide
applicability: enterprise to carrier for chips and software that were
produced.  

Regards,
Don 

> 
> --
> Eric
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Ali 
> Sajassi (sajassi)
> > Sent: Wednesday, December 06, 2006 2:39 AM
> > To: Don Fedyk; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Draft minutes posted
> > 
> >  
> > 
> > 
> > Yes, if there is any reason as to why .1ah encap cannot be 
> > used, then I
> > would like to hear it.
> > 
> > -Ali 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Don Fedyk
> > > Sent: Tuesday, December 05, 2006 10:17 AM
> > > To: Developing a hybrid router/bridge.
> > > Subject: Re: [rbridge] Draft minutes posted
> > > 
> > > Hi Erik
> > > 
> > > In the minutes: 
> > > 802.1ah header synergy?  On this point myself, and I recall 
> > > Ali Sajassi and Donald Oconnor all stood up and said that 
> > > 802.1ah is going to be a standard encapsulation header. My 
> > > point was Trill should see what it could deliver on this 
> > > encapsulation before inventing similar but different headers.
> > > 
> > > Regards,
> > > Don  
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> > > > 
> > > > Any corrections?
> > > > 
> > > >     Erik

From: "Gray, Eric" <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>, Don Fedyk <[email-masked]>
Date: Wed, 6 Dec 2006 08:44:58 -0500 
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Use of 802.1ah Encaps
Status: RO
Content-Length: 2727

Ali/Don,

	The use of 802.1ah encapsulation does not intuitively
suggest itself in the TRILL problem domain for at least two
reasons:

1)	Provider Back-bone Bridging intuitively seems out of
	place in solutions aimed at enterprise networks - and
	this would seem to be even more true for solutions 
	aimed at "plug-and-play" applicability.

2)	Use of 802.1ah encapsulation assumes "bridging" of the
	tunneled frame transparently from edge-to-edge - and
	this would seem to go counter to the idea of using a
	link-state routing protocol for shortest path routing
	of MAC frames.

	That said, the minute that we start suggesting that an 
enterprise is large enough to require using service provider 
(like) solutions (in particular, requiring a substantial
back-bone capacity, and assuming static configuration as a 
means to ensure deterministic network behavior) - OR that we
might in fact use some form of spanning tree forwarding - it
then becomes clear that we should consider using 802.1ah.  It
is certainly the case that we should not be defining another
Ethernet encapsulation explicitly to solve the same problem.

--
Eric

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
> Sent: Wednesday, December 06, 2006 2:39 AM
> To: Don Fedyk; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Draft minutes posted
> 
>  
> 
> 
> Yes, if there is any reason as to why .1ah encap cannot be 
> used, then I
> would like to hear it.
> 
> -Ali 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Don Fedyk
> > Sent: Tuesday, December 05, 2006 10:17 AM
> > To: Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Draft minutes posted
> > 
> > Hi Erik
> > 
> > In the minutes: 
> > 802.1ah header synergy?  On this point myself, and I recall 
> > Ali Sajassi and Donald Oconnor all stood up and said that 
> > 802.1ah is going to be a standard encapsulation header. My 
> > point was Trill should see what it could deliver on this 
> > encapsulation before inventing similar but different headers.
> > 
> > Regards,
> > Don  
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> > > 
> > > Any corrections?
> > > 
> > >     Erik
> > > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Tue, 5 Dec 2006 23:39:00 -0800
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 1071

Yes, if there is any reason as to why .1ah encap cannot be used, then I
would like to hear it.

-Ali 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Don Fedyk
> Sent: Tuesday, December 05, 2006 10:17 AM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Draft minutes posted
> 
> Hi Erik
> 
> In the minutes: 
> 802.1ah header synergy?  On this point myself, and I recall 
> Ali Sajassi and Donald Oconnor all stood up and said that 
> 802.1ah is going to be a standard encapsulation header. My 
> point was Trill should see what it could deliver on this 
> encapsulation before inventing similar but different headers.
> 
> Regards,
> Don  
> 
> > -----Original Message-----
> > From: [email-masked]
> > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> > 
> > Any corrections?
> > 
> >     Erik
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

From: "Gray, Eric" <[email-masked]>
To: Erik Nordmark <[email-masked]>
Date: Tue, 5 Dec 2006 16:18:32 -0500 
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 901

Erik,

	Can I suggest that we should use a different thread
- perhaps later (in a few days) - to address issues with 
the what was said during the meeting, that we might have
disagreed with but did not have time to discuss?

	Meanwhile, we should use this thread only to talk
about clarifying or correcting what was reportedly said
during the meeting.

	Does that make sense?

--
Eric 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Tuesday, December 05, 2006 12:59 PM
> To: Developing a hybrid router/bridge.
> Subject: [rbridge] Draft minutes posted
> 
> 
> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> 
> Any corrections?
> 
>     Erik
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Tue, 5 Dec 2006 15:17:28 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Extensions
Status: RO
Content-Length: 5542

Hi,

See comments below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 29, 2006 11:27 PM
To: Eastlake III Donald-LDE008
Cc: [email-masked]
Subject: Re: [rbridge] Extensions

Clearly making the ability to add fields in the future in a compatible
way gives flexibility. Having TLV encoding in IS-IS has proven to be
really valuable.

On the other hand, questions  that should be asked are:

a) why not? As in, what is the cost of doing this future flexibility?
b) what kinds of features might we imagine
c) is there any other way of adding features in the future in a
compatible way?

I'll make a stab at some of these
a) Why not?
Perhaps complexity of forwarding decision, or perceived complexity of
the protocol that might discourage adoption.
If all the fields necessary for current functionality are in the fixed
portion of the shim, and RBridges that don't do the feature can ignore
it, then that would not be a problem. But for instance, if they have to
look at the inner header to find the VLAN tag (in order to know whether
to filter a multicast), or the inner destination address (for IP derived
multicast -- though maybe it's the layer 3 destination address that
matters...not sure), then having a variable length shim header could be
a cost

@@@ There is no getting around the fact that providing extensions makes
things more complex. And since extensions can be present or absence, it
necessarily leads to a variable length shim in cases where extensions
might be present. However, the extension proposal in my presentation,
which does incorporate some ideas I got from others, tries to minimize
the additional complexity. In particular, it tries to assure that any
Rbridge that might be an egress Rbridge will not receive any extension
that it does not understand. A goal of the extension design is that an
Rbridge the does not understand any extensions would not need any
additional code.

@@@ If there are fields after the shim in the current design that are
clearly needed for normal operation, such as inner VLAN tag for
broadcast/multicast filtering, then it seems like it might be a good
idea to mirror them in the shim.

@@@ But, beyond normal Rbridge operation, there is no obvious limit on
how deeply some QoS policy might want to look into a packet. It could
certainly want to look at TCP port, for example, which already requires
it, in the Rbridge case, to skip over a variable length assortment of
802.1 inserts between the inner MAC addresses and the inner payload. If
a feature outside of TRILL already has to do something that complex, it
doesn't seem like much of a burden for it to understand a variable
length shim due to extensions. Thus, the proposal in my presentation
provides an overall extensions size to make it relatively easy to skip
them.

b) features: LIDs ... any others?

@@@ LIDs seem like a nice extension that has the characteristic that you
only would want to include it if both  end point Rbridges understood it
(see comments under "c)" below).

@@@ Someone might want a security extension. Even if it turned out to
use 802.1AE, it seem like you would need a way to indicate that such
information was present in the Rbridge shim.

@@@ Of course, the most interesting extensions would be those that are
not currently thought of.

c) not sure

@@@ Adding feature can be done in different ways. I think they may all
be logically equivalent but they would have very different
implementation impact. For example, instead of extensions, you could
have a version number so that when you define extension N, if you use
that extension, you have to assert version N. This seems like a bad idea
because you have to upgrade all your equipment to know about version N.
Possibly that makes sense for an extension that every Rbridge actually
has to understand, but maybe such a radical extension is best considered
to be a revision of the base protocol. More reasonable extension
proposals would provide more or less end-to-end Rbridge extensions in
such a way that intervening Rbridges could ignore them.

Radia

@@@ Thanks,
@@@ Donald

----- Original Message -----
From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Wednesday, November 29, 2006 7:58 pm
Subject: [rbridge] Extensions

> Hi,
> 
> It is not so much that I think that TRILL needs any particular 
> extension added right now, it is just that if there is ever a reason
to 
> add an extension, it would be good for the extension framework to have

> been decided in advance. The presentation that I didn't have time to 
> make at the TRILL WG meeting in San Diego has now been converted from 
> MS Power Point and is on the Working Group agendas and presentations 
> web page for the 67th IETF meeting in HTML and is also available at
> http://www.pothole.com/~dee3 in PDF.
> 
> Donald
> 
> -----Original Message-----
> From: [email-masked] [[email-masked]] On 
> Behalf Of Radia Perlman
> Sent: Monday, November 13, 2006 8:01 PM
> Cc: [email-masked]
> Subject: Re: [rbridge] Should we optimize the common case?
> 
> ......
> 
> Another thing we haven't talked about on the list (and ran out of time

> at the meeting), is Don Eastlake's suggestion of allowing the shim 
> header to be variable length, so that we can optionally put in thing 
> like LIDs.
> 
> Radia
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Content-class: urn:content-classes:message
Date: Tue, 5 Dec 2006 13:16:56 -0500
From: "Don Fedyk" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Draft minutes posted
Status: RO
Content-Length: 506

Hi Erik

In the minutes: 
802.1ah header synergy?  On this point myself, and I recall Ali Sajassi
and Donald Oconnor all stood up and said that 802.1ah is going to be a
standard encapsulation header. My point was Trill should see what it
could deliver on this encapsulation before inventing similar but
different headers.

Regards,
Don  

> -----Original Message-----
> From: [email-masked] 
> At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> 
> Any corrections?
> 
>     Erik
> 

Date: Tue, 05 Dec 2006 09:59:08 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Draft minutes posted
Status: RO
Content-Length: 90

At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt

Any corrections?

    Erik

From: "Gray, Eric" <[email-masked]>
To: =?iso-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>, [email-masked]
Date: Fri, 1 Dec 2006 18:35:04 -0500 
Cc: [email-masked]
Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized
Status: RO
Content-Length: 9221

Guillermo,

	I think I'm missing some context here.

	I want to understand what you mean by "concatenation of 
two 802.1Q VLAN tags (to yield a 24-bit VLAN identifier)" - are 
you speaking of explicit concatenation (in the sense that both
802.1Q VLAN tags are used simultaneously in making a forwarding
decision), or are you talking about a general sense of layered
802.1Q (in which only one VLAN tag is used - at a time in the
making of a single forwarding decision)?

--
Eric

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Guillermo Ib??ez
> Sent: Friday, December 01, 2006 5:44 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized
> 
> 
> I wonder whether the IEEE position against extending VLANs to 24 bit 
> applies in the RBridges context. See the mail below from the 
> liaison to 
> IETF.
> Guillermo
> 
> Extracted text: "The possible concatenation of two 802.1Q 
> VLAN tags (to 
> yield a 24-bit VLAN identifier) has
> been discussed, is of considerable concern, and is believed to be not 
> just a violation of the
> 802.1Q standard but also of the architectural principles on 
> which 802.1 
> standardization is
> based".
> 
> 
> From: "Romascanu, Dan (Dan)" <[email-masked] 
> <mailto:[email-masked]>>
> To: "IESG" <[email-masked] <mailto:[email-masked]>>; <[email-masked] 
> <mailto:[email-masked]>>
> Cc: < [email-masked] <mailto:[email-masked]>>; 
> <[email-masked] <mailto:[email-masked]>>; 
> "Tony Jeffree"
> <[email-masked] <mailto:[email-masked]>>
> Sent: Wednesday, September 06, 2006 2:55 PM
> Subject: IEEE 802.1 WG liaison letter to the IETF
> The IEEE 802.1 Working Group approved the following liaison letter to
> the IETF, containing clarifications in response to several queries
> related to the use of IEEE 802.1Q VLAN tags.
> 
> http://www.ieee802.org/1/files/public/docs2006/liaison-contrib
> -to-ietf-m
> ef-dsl-forum-0706.pdf 
> <http://www.ieee802.org/1/files/public/docs2006/liaison-contri
> b-to-ietf-mef-dsl-forum-0706.pdf>
> 
> Please distribute this letter to the interested Working 
> Groups that are
> not included in the distribution list.
> 
> Dan
> (wearing the hat of IEEE 802.1 WG liaison to the IETF)
> 
> 
> __________________________________________________
> 
> [email-masked] escribi?:
> > Silvano explained a reason for an "outer" vs an "inner" 
> VLAN tag, which is really to accomplish making
> > a 24-bit VLAN tag, hierarchically assigned by 12 bits for 
> customer, and 12 bits for use by that customer.
> >
> > The only changes we'd need to the base spec is as follows:
> >
> > a) the VLAN tag specified in the per-VLAN IS-IS instance 
> would be 24 bits instead of 12 (the per-VLAN instance
> > is the thing where R1 says what endnodes are attached, and 
> whether R1 has an IP multicast router
> > attached, and what IP multicast groups have members attached).
> >
> > b) For unicast traffic: the ingress RBridge R1 looks up the 
> egress RBridge R2 based on
> > the 24-bit VLAN tag, (using the 12 bits in the frame 
> indicating the customer-defined VLAN, plus 12 bits R1 infers
> > based on which port R1 received the frame from)
> > R1 puts   the "which customer" portion of the VLAN tag in 
> the outer header. The reason for this is
> > in case R2 has ports to two different customers, and there 
> are overlapping endnode address spaces, R2 will
> > need the outer VLAN tag to determine which port to 
> decapsulate the frame onto.
> >
> > c) for unknown destination/multicast: the ingress RBridge 
> R1 puts the "which customer" portion of the VLAn
> > tag into an outer VLAN tag, and RBridges in the core filter 
> based on the 24-bit VLAN by using both the inner
> > and outer 12 bits.
> >
> > This proposal still treats the infrastructure (all the 
> transit links) as shared by all VLANs, which I like the
> > robustness and simplicity of.
> >
> > Radia
> >
> >
> >
> > ----- Original Message -----
> > From: Radia Perlman <[email-masked]>
> > Date: Thursday, November 30, 2006 7:36 pm
> > Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized
> >
> >   
> >> There's been a lot of discussion, and I believe this is what is 
> >> going 
> >> on: In this email I will attempt to just
> >> explain, and not advocate. If I want to express opinions, I'll 
> >> reply to 
> >> this.
> >>
> >> The first question we have to ask is what things people are  doing 
> >> with 
> >> VLANs. The next is to ask
> >> which subset of these (possibly "all") we want to support with 
> >> TRILL, 
> >> and to answer that we have
> >> to also answer what the cost/benefit of solving each with TRILL is.
> >>
> >> Things VLANs can provide:
> >> a) separate endnodes into communities, to enforce that only VLAN A 
> >> nodes 
> >> can talk to VLAN A nodes
> >> b) scoping things like ARP, so an ARP for a VLAN A node only gets 
> >> sent 
> >> on VLAN A links
> >> c) security -- making sure that VLAN A nodes cannot snoop 
> on VLAN B 
> >> trafficd) provisioning -- making sure that the only traffic on a 
> >> VLAN A link is 
> >> VLAN A traffic, or
> >> perhaps BGP-policy-like, as in, "this link is willing to carry 
> >> VLANs A, 
> >> B, and Q, but not D".
> >>
> >> Perhaps this is not an exhaustive list, but I hope it's 
> close enough.
> >>
> >> What are the costs of providing these things?
> >>
> >> The solution that I'd been assuming solves a) and b). That 
> solution 
> >> is 
> >> summarized as follows:
> >> If RBridges R1 and R2 are on the same link, they are 
> neighbors, and 
> >> they 
> >> can send transit traffic to each other,
> >> regardless of the VLAN on which it originated. This can be thought 
> >> of as 
> >> RBridges create a cloud,
> >> which keeps VLAN traffic segregated at the endpoints, but is a 
> >> single 
> >> shared infrastructure for all
> >> VLANs within the cloud.
> >>
> >> That solution does not solve c) and d), though if the 
> transit links 
> >> are 
> >> all point-to-point links
> >> between RBridges, this is moot. The case that isn't solved is when 
> >> a 
> >> link is both a transit link
> >> and a shared link with a bunch of endnodes in a VLAN.
> >>
> >> Suppose we want to solve those?
> >>
> >> What I think people would be asking for is to have the VLAN 
> >> determine 
> >> not just the destination, but what
> >> path the packet takes. So some links would only allow certain VLAN 
> >> traffic on them, even for transit.
> >> Which would mean multiple forwarding tables, since paths 
> would have 
> >> to 
> >> be VLAN-dependent.
> >>
> >> So, I think the basic strategies are:
> >>
> >> a) create as much connectivity as possible between RBridge 
> >> neighbors. If 
> >> R1,  R2, and R3 are on the same
> >> shared/bridged link, and R1 can only talk to R2 if it puts 
> "VLAN X" 
> >> into 
> >> the header, and R1 can only
> >> talk to R3 if it puts "VLAN Y" into the header, R1 discovers this 
> >> case 
> >> by being configured that the
> >> link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with 
> >> both, 
> >> and wdiscovers that on the
> >> adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to 
> >> stick 
> >> "VLAN Y". So R1 does whatever
> >> is necessary to talk to its neighbors, but it is only relevant on 
> >> the 
> >> hop. R1 reports in its link state packet that
> >> it has a neighbor R2, and R3. All RBridges can use the link for 
> >> transit 
> >> for all VLANs.
> >>
> >> b) only allow R1 and R2 to be IS-IS neighbors if they can talk to 
> >> each 
> >> other with a null VLAN tag. A link
> >> that requires a VLAN tag can only be used as an ingress or egress 
> >> link 
> >> from the cloud.
> >>
> >> c) copy the VLAN tag to the outer header, assume any link that 
> >> requires 
> >> a particular VLAN tag wants to exclude
> >> transit traffic for all other VLANs, or even for null tags, on the 
> >> link 
> >> Run separate core instances of IS-IS for
> >> each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN 
> >> A 
> >> links, plus links that allow
> >> for null tags.
> >>
> >> d) like with c), but allow a link to be configured as "there are 
> >> VLAN A 
> >> endnodes here, but transit traffic for any VLAN
> >> is fine".
> >>
> >> Solutions c) and d) require separate forwarding tables per VLAN, 
> >> and 
> >> either separate instances of IS-IS, or
> >> a link attribute that lists legal VLAN tags for the link. VLAN A 
> >> segments might become disconnected
> >> because although there is RBridge connectivity, it isn't through 
> >> links 
> >> that say it's OK to have VLAN A traffic.
> >>
> >> Radia
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> [email-masked]
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>     
> >
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >   
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

From: "Gray, Eric" <[email-masked]>
To: [email-masked]
Date: Fri, 1 Dec 2006 18:25:58 -0500 
Cc: [email-masked]
Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized
Status: RO
Content-Length: 7379

I have no fundamental objections to making this change.

However, it may be important to realize that the supposed
purpose for this change implies a "service provisioning"
model for RBridge/TRILL deployment as opposed to a strictly
enterprise model.  Even in the case where we're speaking of
an enterprise so large that the enterprise's IT functions 
effectively as a service provider, we potentially open the
door to the _general_ service provisioning problem space.

I hope this is not the fore-runner to a number of simple 
changes that might lead us to proposing a solution to a set
of problems the IETF is already addressing elsewhere...

--
Eric

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, December 01, 2006 2:59 PM
> To: Radia Perlman
> Cc: [email-masked]
> Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized
> 
> Silvano explained a reason for an "outer" vs an "inner" VLAN 
> tag, which is really to accomplish making
> a 24-bit VLAN tag, hierarchically assigned by 12 bits for 
> customer, and 12 bits for use by that customer.
> 
> The only changes we'd need to the base spec is as follows:
> 
> a) the VLAN tag specified in the per-VLAN IS-IS instance 
> would be 24 bits instead of 12 (the per-VLAN instance
> is the thing where R1 says what endnodes are attached, and 
> whether R1 has an IP multicast router
> attached, and what IP multicast groups have members attached).
> 
> b) For unicast traffic: the ingress RBridge R1 looks up the 
> egress RBridge R2 based on
> the 24-bit VLAN tag, (using the 12 bits in the frame 
> indicating the customer-defined VLAN, plus 12 bits R1 infers
> based on which port R1 received the frame from)
> R1 puts   the "which customer" portion of the VLAN tag in the 
> outer header. The reason for this is
> in case R2 has ports to two different customers, and there 
> are overlapping endnode address spaces, R2 will
> need the outer VLAN tag to determine which port to 
> decapsulate the frame onto.
> 
> c) for unknown destination/multicast: the ingress RBridge R1 
> puts the "which customer" portion of the VLAn
> tag into an outer VLAN tag, and RBridges in the core filter 
> based on the 24-bit VLAN by using both the inner
> and outer 12 bits.
> 
> This proposal still treats the infrastructure (all the 
> transit links) as shared by all VLANs, which I like the
> robustness and simplicity of.
> 
> Radia
> 
> 
> 
> ----- Original Message -----
> From: Radia Perlman <[email-masked]>
> Date: Thursday, November 30, 2006 7:36 pm
> Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized
> 
> > There's been a lot of discussion, and I believe this is what is 
> > going 
> > on: In this email I will attempt to just
> > explain, and not advocate. If I want to express opinions, I'll 
> > reply to 
> > this.
> > 
> > The first question we have to ask is what things people are  doing 
> > with 
> > VLANs. The next is to ask
> > which subset of these (possibly "all") we want to support with 
> > TRILL, 
> > and to answer that we have
> > to also answer what the cost/benefit of solving each with TRILL is.
> > 
> > Things VLANs can provide:
> > a) separate endnodes into communities, to enforce that only VLAN A 
> > nodes 
> > can talk to VLAN A nodes
> > b) scoping things like ARP, so an ARP for a VLAN A node only gets 
> > sent 
> > on VLAN A links
> > c) security -- making sure that VLAN A nodes cannot snoop on VLAN B 
> > trafficd) provisioning -- making sure that the only traffic on a 
> > VLAN A link is 
> > VLAN A traffic, or
> > perhaps BGP-policy-like, as in, "this link is willing to carry 
> > VLANs A, 
> > B, and Q, but not D".
> > 
> > Perhaps this is not an exhaustive list, but I hope it's 
> close enough.
> > 
> > What are the costs of providing these things?
> > 
> > The solution that I'd been assuming solves a) and b). That solution 
> > is 
> > summarized as follows:
> > If RBridges R1 and R2 are on the same link, they are neighbors, and 
> > they 
> > can send transit traffic to each other,
> > regardless of the VLAN on which it originated. This can be thought 
> > of as 
> > RBridges create a cloud,
> > which keeps VLAN traffic segregated at the endpoints, but is a 
> > single 
> > shared infrastructure for all
> > VLANs within the cloud.
> > 
> > That solution does not solve c) and d), though if the transit links 
> > are 
> > all point-to-point links
> > between RBridges, this is moot. The case that isn't solved is when 
> > a 
> > link is both a transit link
> > and a shared link with a bunch of endnodes in a VLAN.
> > 
> > Suppose we want to solve those?
> > 
> > What I think people would be asking for is to have the VLAN 
> > determine 
> > not just the destination, but what
> > path the packet takes. So some links would only allow certain VLAN 
> > traffic on them, even for transit.
> > Which would mean multiple forwarding tables, since paths would have 
> > to 
> > be VLAN-dependent.
> > 
> > So, I think the basic strategies are:
> > 
> > a) create as much connectivity as possible between RBridge 
> > neighbors. If 
> > R1,  R2, and R3 are on the same
> > shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" 
> > into 
> > the header, and R1 can only
> > talk to R3 if it puts "VLAN Y" into the header, R1 discovers this 
> > case 
> > by being configured that the
> > link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with 
> > both, 
> > and wdiscovers that on the
> > adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to 
> > stick 
> > "VLAN Y". So R1 does whatever
> > is necessary to talk to its neighbors, but it is only relevant on 
> > the 
> > hop. R1 reports in its link state packet that
> > it has a neighbor R2, and R3. All RBridges can use the link for 
> > transit 
> > for all VLANs.
> > 
> > b) only allow R1 and R2 to be IS-IS neighbors if they can talk to 
> > each 
> > other with a null VLAN tag. A link
> > that requires a VLAN tag can only be used as an ingress or egress 
> > link 
> > from the cloud.
> > 
> > c) copy the VLAN tag to the outer header, assume any link that 
> > requires 
> > a particular VLAN tag wants to exclude
> > transit traffic for all other VLANs, or even for null tags, on the 
> > link 
> > Run separate core instances of IS-IS for
> > each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN 
> > A 
> > links, plus links that allow
> > for null tags.
> > 
> > d) like with c), but allow a link to be configured as "there are 
> > VLAN A 
> > endnodes here, but transit traffic for any VLAN
> > is fine".
> > 
> > Solutions c) and d) require separate forwarding tables per VLAN, 
> > and 
> > either separate instances of IS-IS, or
> > a link attribute that lists legal VLAN tags for the link. VLAN A 
> > segments might become disconnected
> > because although there is RBridge connectivity, it isn't through 
> > links 
> > that say it's OK to have VLAN A traffic.
> > 
> > Radia
> > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > [email-masked]
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
> 

Date: Fri, 01 Dec 2006 23:44:14 +0100
From: =?ISO-8859-1?Q?Guillermo_Ib=E1=F1ez?= <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized
Status: RO
Content-Length: 7784

I wonder whether the IEEE position against extending VLANs to 24 bit 
applies in the RBridges context. See the mail below from the liaison to 
IETF.
Guillermo

Extracted text: "The possible concatenation of two 802.1Q VLAN tags (to 
yield a 24-bit VLAN identifier) has
been discussed, is of considerable concern, and is believed to be not 
just a violation of the
802.1Q standard but also of the architectural principles on which 802.1 
standardization is
based".

From: "Romascanu, Dan (Dan)" <[email-masked] 
<mailto:[email-masked]>>
To: "IESG" <[email-masked] <mailto:[email-masked]>>; <[email-masked] 
<mailto:[email-masked]>>
Cc: < [email-masked] <mailto:[email-masked]>>; 
<[email-masked] <mailto:[email-masked]>>; 
"Tony Jeffree"
<[email-masked] <mailto:[email-masked]>>
Sent: Wednesday, September 06, 2006 2:55 PM
Subject: IEEE 802.1 WG liaison letter to the IETF
The IEEE 802.1 Working Group approved the following liaison letter to
the IETF, containing clarifications in response to several queries
related to the use of IEEE 802.1Q VLAN tags.

http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-m
ef-dsl-forum-0706.pdf 
<http://www.ieee802.org/1/files/public/docs2006/liaison-contrib-to-ietf-mef-dsl-forum-0706.pdf>

Please distribute this letter to the interested Working Groups that are
not included in the distribution list.

Dan
(wearing the hat of IEEE 802.1 WG liaison to the IETF)

__________________________________________________

[email-masked] escribi?:
> Silvano explained a reason for an "outer" vs an "inner" VLAN tag, which is really to accomplish making
> a 24-bit VLAN tag, hierarchically assigned by 12 bits for customer, and 12 bits for use by that customer.
>
> The only changes we'd need to the base spec is as follows:
>
> a) the VLAN tag specified in the per-VLAN IS-IS instance would be 24 bits instead of 12 (the per-VLAN instance
> is the thing where R1 says what endnodes are attached, and whether R1 has an IP multicast router
> attached, and what IP multicast groups have members attached).
>
> b) For unicast traffic: the ingress RBridge R1 looks up the egress RBridge R2 based on
> the 24-bit VLAN tag, (using the 12 bits in the frame indicating the customer-defined VLAN, plus 12 bits R1 infers
> based on which port R1 received the frame from)
> R1 puts   the "which customer" portion of the VLAN tag in the outer header. The reason for this is
> in case R2 has ports to two different customers, and there are overlapping endnode address spaces, R2 will
> need the outer VLAN tag to determine which port to decapsulate the frame onto.
>
> c) for unknown destination/multicast: the ingress RBridge R1 puts the "which customer" portion of the VLAn
> tag into an outer VLAN tag, and RBridges in the core filter based on the 24-bit VLAN by using both the inner
> and outer 12 bits.
>
> This proposal still treats the infrastructure (all the transit links) as shared by all VLANs, which I like the
> robustness and simplicity of.
>
> Radia
>
>
>
> ----- Original Message -----
> From: Radia Perlman <[email-masked]>
> Date: Thursday, November 30, 2006 7:36 pm
> Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized
>
>   
>> There's been a lot of discussion, and I believe this is what is 
>> going 
>> on: In this email I will attempt to just
>> explain, and not advocate. If I want to express opinions, I'll 
>> reply to 
>> this.
>>
>> The first question we have to ask is what things people are  doing 
>> with 
>> VLANs. The next is to ask
>> which subset of these (possibly "all") we want to support with 
>> TRILL, 
>> and to answer that we have
>> to also answer what the cost/benefit of solving each with TRILL is.
>>
>> Things VLANs can provide:
>> a) separate endnodes into communities, to enforce that only VLAN A 
>> nodes 
>> can talk to VLAN A nodes
>> b) scoping things like ARP, so an ARP for a VLAN A node only gets 
>> sent 
>> on VLAN A links
>> c) security -- making sure that VLAN A nodes cannot snoop on VLAN B 
>> trafficd) provisioning -- making sure that the only traffic on a 
>> VLAN A link is 
>> VLAN A traffic, or
>> perhaps BGP-policy-like, as in, "this link is willing to carry 
>> VLANs A, 
>> B, and Q, but not D".
>>
>> Perhaps this is not an exhaustive list, but I hope it's close enough.
>>
>> What are the costs of providing these things?
>>
>> The solution that I'd been assuming solves a) and b). That solution 
>> is 
>> summarized as follows:
>> If RBridges R1 and R2 are on the same link, they are neighbors, and 
>> they 
>> can send transit traffic to each other,
>> regardless of the VLAN on which it originated. This can be thought 
>> of as 
>> RBridges create a cloud,
>> which keeps VLAN traffic segregated at the endpoints, but is a 
>> single 
>> shared infrastructure for all
>> VLANs within the cloud.
>>
>> That solution does not solve c) and d), though if the transit links 
>> are 
>> all point-to-point links
>> between RBridges, this is moot. The case that isn't solved is when 
>> a 
>> link is both a transit link
>> and a shared link with a bunch of endnodes in a VLAN.
>>
>> Suppose we want to solve those?
>>
>> What I think people would be asking for is to have the VLAN 
>> determine 
>> not just the destination, but what
>> path the packet takes. So some links would only allow certain VLAN 
>> traffic on them, even for transit.
>> Which would mean multiple forwarding tables, since paths would have 
>> to 
>> be VLAN-dependent.
>>
>> So, I think the basic strategies are:
>>
>> a) create as much connectivity as possible between RBridge 
>> neighbors. If 
>> R1,  R2, and R3 are on the same
>> shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" 
>> into 
>> the header, and R1 can only
>> talk to R3 if it puts "VLAN Y" into the header, R1 discovers this 
>> case 
>> by being configured that the
>> link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with 
>> both, 
>> and wdiscovers that on the
>> adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to 
>> stick 
>> "VLAN Y". So R1 does whatever
>> is necessary to talk to its neighbors, but it is only relevant on 
>> the 
>> hop. R1 reports in its link state packet that
>> it has a neighbor R2, and R3. All RBridges can use the link for 
>> transit 
>> for all VLANs.
>>
>> b) only allow R1 and R2 to be IS-IS neighbors if they can talk to 
>> each 
>> other with a null VLAN tag. A link
>> that requires a VLAN tag can only be used as an ingress or egress 
>> link 
>> from the cloud.
>>
>> c) copy the VLAN tag to the outer header, assume any link that 
>> requires 
>> a particular VLAN tag wants to exclude
>> transit traffic for all other VLANs, or even for null tags, on the 
>> link 
>> Run separate core instances of IS-IS for
>> each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN 
>> A 
>> links, plus links that allow
>> for null tags.
>>
>> d) like with c), but allow a link to be configured as "there are 
>> VLAN A 
>> endnodes here, but transit traffic for any VLAN
>> is fine".
>>
>> Solutions c) and d) require separate forwarding tables per VLAN, 
>> and 
>> either separate instances of IS-IS, or
>> a link attribute that lists legal VLAN tags for the link. VLAN A 
>> segments might become disconnected
>> because although there is RBridge connectivity, it isn't through 
>> links 
>> that say it's OK to have VLAN A traffic.
>>
>> Radia
>>
>>
>> _______________________________________________
>> rbridge mailing list
>> [email-masked]
>> http://mailman.postel.org/mailman/listinfo/rbridge
>>
>>     
>
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

Date: Fri, 01 Dec 2006 11:58:42 -0800
From: [email-masked]
To: Radia Perlman <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [rbridge] VLAN tags, inner/outer, revisted and summarized
Status: RO
Content-Length: 5908

Silvano explained a reason for an "outer" vs an "inner" VLAN tag, which is really to accomplish making
a 24-bit VLAN tag, hierarchically assigned by 12 bits for customer, and 12 bits for use by that customer.

The only changes we'd need to the base spec is as follows:

a) the VLAN tag specified in the per-VLAN IS-IS instance would be 24 bits instead of 12 (the per-VLAN instance
is the thing where R1 says what endnodes are attached, and whether R1 has an IP multicast router
attached, and what IP multicast groups have members attached).

b) For unicast traffic: the ingress RBridge R1 looks up the egress RBridge R2 based on
the 24-bit VLAN tag, (using the 12 bits in the frame indicating the customer-defined VLAN, plus 12 bits R1 infers
based on which port R1 received the frame from)
R1 puts   the "which customer" portion of the VLAN tag in the outer header. The reason for this is
in case R2 has ports to two different customers, and there are overlapping endnode address spaces, R2 will
need the outer VLAN tag to determine which port to decapsulate the frame onto.

c) for unknown destination/multicast: the ingress RBridge R1 puts the "which customer" portion of the VLAn
tag into an outer VLAN tag, and RBridges in the core filter based on the 24-bit VLAN by using both the inner
and outer 12 bits.

This proposal still treats the infrastructure (all the transit links) as shared by all VLANs, which I like the
robustness and simplicity of.

Radia

----- Original Message -----
From: Radia Perlman <[email-masked]>
Date: Thursday, November 30, 2006 7:36 pm
Subject: [rbridge] VLAN tags, inner/outer, revisted and summarized

> There's been a lot of discussion, and I believe this is what is 
> going 
> on: In this email I will attempt to just
> explain, and not advocate. If I want to express opinions, I'll 
> reply to 
> this.
> 
> The first question we have to ask is what things people are  doing 
> with 
> VLANs. The next is to ask
> which subset of these (possibly "all") we want to support with 
> TRILL, 
> and to answer that we have
> to also answer what the cost/benefit of solving each with TRILL is.
> 
> Things VLANs can provide:
> a) separate endnodes into communities, to enforce that only VLAN A 
> nodes 
> can talk to VLAN A nodes
> b) scoping things like ARP, so an ARP for a VLAN A node only gets 
> sent 
> on VLAN A links
> c) security -- making sure that VLAN A nodes cannot snoop on VLAN B 
> trafficd) provisioning -- making sure that the only traffic on a 
> VLAN A link is 
> VLAN A traffic, or
> perhaps BGP-policy-like, as in, "this link is willing to carry 
> VLANs A, 
> B, and Q, but not D".
> 
> Perhaps this is not an exhaustive list, but I hope it's close enough.
> 
> What are the costs of providing these things?
> 
> The solution that I'd been assuming solves a) and b). That solution 
> is 
> summarized as follows:
> If RBridges R1 and R2 are on the same link, they are neighbors, and 
> they 
> can send transit traffic to each other,
> regardless of the VLAN on which it originated. This can be thought 
> of as 
> RBridges create a cloud,
> which keeps VLAN traffic segregated at the endpoints, but is a 
> single 
> shared infrastructure for all
> VLANs within the cloud.
> 
> That solution does not solve c) and d), though if the transit links 
> are 
> all point-to-point links
> between RBridges, this is moot. The case that isn't solved is when 
> a 
> link is both a transit link
> and a shared link with a bunch of endnodes in a VLAN.
> 
> Suppose we want to solve those?
> 
> What I think people would be asking for is to have the VLAN 
> determine 
> not just the destination, but what
> path the packet takes. So some links would only allow certain VLAN 
> traffic on them, even for transit.
> Which would mean multiple forwarding tables, since paths would have 
> to 
> be VLAN-dependent.
> 
> So, I think the basic strategies are:
> 
> a) create as much connectivity as possible between RBridge 
> neighbors. If 
> R1,  R2, and R3 are on the same
> shared/bridged link, and R1 can only talk to R2 if it puts "VLAN X" 
> into 
> the header, and R1 can only
> talk to R3 if it puts "VLAN Y" into the header, R1 discovers this 
> case 
> by being configured that the
> link needs either VLAN X or VLAN Y tags, sends IS-IS Hellos with 
> both, 
> and wdiscovers that on the
> adjacency to R2, R1 has to stick "VLAN X" and to R3, R1 has to 
> stick 
> "VLAN Y". So R1 does whatever
> is necessary to talk to its neighbors, but it is only relevant on 
> the 
> hop. R1 reports in its link state packet that
> it has a neighbor R2, and R3. All RBridges can use the link for 
> transit 
> for all VLANs.
> 
> b) only allow R1 and R2 to be IS-IS neighbors if they can talk to 
> each 
> other with a null VLAN tag. A link
> that requires a VLAN tag can only be used as an ingress or egress 
> link 
> from the cloud.
> 
> c) copy the VLAN tag to the outer header, assume any link that 
> requires 
> a particular VLAN tag wants to exclude
> transit traffic for all other VLANs, or even for null tags, on the 
> link 
> Run separate core instances of IS-IS for
> each VLAN tag. Perhaps announcing in the VLAN A instance, all VLAN 
> A 
> links, plus links that allow
> for null tags.
> 
> d) like with c), but allow a link to be configured as "there are 
> VLAN A 
> endnodes here, but transit traffic for any VLAN
> is fine".
> 
> Solutions c) and d) require separate forwarding tables per VLAN, 
> and 
> either separate instances of IS-IS, or
> a link attribute that lists legal VLAN tags for the link. VLAN A 
> segments might become disconnected
> because although there is RBridge connectivity, it isn't through 
> links 
> that say it's OK to have VLAN A traffic.
> 
> Radia
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge
>