Subject: [rbridge] Use of 802.1ah Encaps

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 6 Dec 2006 08:44:58 -0500

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: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] 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: rbridge-bounces at postel.org 
> > [mailto:rbridge-bounces at postel.org] 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: rbridge-bounces at postel.org
> > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> > > 
> > > Any corrections?
> > > 
> > >     Erik
> > > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: dwfedyk at nortel.com (Don Fedyk)
Date: Wed, 6 Dec 2006 11:14:39 -0500

Hi Eric 

> From: Gray, Eric [mailto:Eric.Gray at marconi.com] 
> 
> Ali/Don,
> 
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. 

> 	link-state routing protocol for shortest path routing
Encapsulation and the use of link state are orthogonal concepts so I
disagree. 

> 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

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 06 Dec 2006 09:25:25 -0800

Don Fedyk wrote:
...
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061206/c5b40dbf/signature-0001.bin

---

From: stbryant at cisco.com (Stewart Bryant)
Date: Wed, 06 Dec 2006 17:49:50 +0000

> 	aimed at "plug-and-play" applicability.

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

> 	link-state routing protocol for shortest path routing

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

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed, 06 Dec 2006 10:01:53 -0800

> using an IEEE 802.1 Ethernet data plane your baseline choices are 802.1Q

Is there a TTL in the 802.1ah header?

    Erik

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Wed, 6 Dec 2006 15:24:07 -0500

Hi Don,

See below at @@@

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] 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 

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

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

...