Subject: [rbridge] Use of 802.1ah Encaps

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 13 Dec 2006 19:00:39 -0500

Don,

	I think you've garbled the discussion, somewhat.

	Please see below...

--
Eric 

> -----Original Message-----
> From: Don Fedyk [mailto:dwfedyk at nortel.com] 
> 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:Eric.Gray at marconi.com] 
> > 
> > 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:dwfedyk at nortel.com] 
> > > 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:Eric.Gray at marconi.com] 
> > > > 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: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 14 Dec 2006 07:33:57 +0100

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?:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: dwfedyk at nortel.com (Don Fedyk)
Date: Thu, 14 Dec 2006 10:47:53 -0500

Hi Eric 

> 	I think you've garbled the discussion, somewhat.
I'll answer inline here specifically. Thanks for providing more context.

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

> 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. 

> 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.
> 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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 15 Dec 2006 12:27:03 +0100

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

---

From: dwfedyk at nortel.com (Don Fedyk)
Date: Fri, 15 Dec 2006 12:37:11 -0500

Hi Guillermo

See Inline.

> From: Guillermo Ib??ez [mailto:gibanez at it.uc3m.es] 
>
> 
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. 

> 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
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. 

> 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. 

> case), 802.1ah does not seem the way to go regarding simplicity in 
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

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 15 Dec 2006 19:16:04 +0100

Don,
See inline
Guillermo
> 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 leg…
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.
> 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.
> 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 is the key point. Hop by hop part, directly related to handle the 
intermediate legacy bridges problem.
> 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".
> 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.
>>> 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.
>>> 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.
>>> either, specially considering the campus networks of 
>>>       
>> moderate sizes that 
>>     
>>>>> 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
>>     
>>>>> Eric I understand what is proposed but I still question 
>>>>>           
>> if a greater
>>     
>>>>> synergy cannot be achieved between encapsulating headers. 
>>>>>           
>>  A shim is a
>>