Re: [rbridge] Review of draft-ietf-trill-rbridge-protocol-13.txt

[Radia Perlman <[e-mail]>]

To reinforce what Caitlin said, TRILL is layered above 802, and as such 
it's similar to IP in both its
interaction with Ethernet and its independence from it. TRILL devices 
are, as Caitlin said,
like endnodes to layer 2.  There might be new features (such as congestion
feedback) that would be useful to exploit.  There are sometimes subtle 
issues in adjacent layers
that should be thought through (e.g., VRRP moving a MAC address around), 
so it's really good
to have experts checking out if there are any subtle issues. And TRILL 
has uncovered some (like
the need to consider what VLAN tag(s) to use in IS-IS Hellos, and to be 
defensive against
VLAN translation). But if there really were any work going on in IEEE 
that would break TRILL,
it would also likely break many other IETF protocols as well.

Radia



Caitlin Bestler wrote:
> Roger Lapuh wrote:
>   
>> Hi Don (Eastlake)
>>
>> I know you were not trying to imply this, but I got the impression from 
>> your comments that others might infer that the current link-state 
>> based  IEEE 802.1 project could take a long time and will not see any 
>> market validation soon. Thus I wanted to point out that a pre-standard 
>> version of 802.1aq (SPBm) has been shipping and is generally available 
>> since 2008 and is deployed in several carrier - as well as enterprise 
>> customer (data center) networks. It has been proven to be a scalable and 
>> robust solution with great potentials to extend beyond L2 
>> virtualization. With that in mind there are several vendors implementing 
>> it as well.
>>
>> For broad market adoption, it makes sense for any new link-state 
>> Ethernet approach to provide maximum interoperability with existing IEEE 
>> standards.
>>
>> Also, while going through the TRILL draft I was wondering how well you 
>> perceive end-stations and applications will handle the out-of-ordered 
>> (Unicast) packets that you point out within the TRILL design in section 
>> 4.5 page 48?
>>
>>  
>>
>>     
>
> There are two major points that need to be made in regard to 802.1 
> projects as they relate to Trill/RBridges.
>
> First, 802.1 will always have work in progress. This is not some sort
> of slam that implies 802.1 cannot finish things, but rather a
> recognition that one of 802.1 strengths is that it continually evolves.
> 802.1 networking will not stabilize until it has been obsolete for
> several years. Deployed RBRidges will of course have to track these
> changes, but only because they almost certainly *include* an 802.1Q
> Bridge. Layering is nice, but extra boxes take space and power.
>
> But by positioning TRILL as an EISS client (with some minor ISS client
> usage as noted) insulates TRILL from 802.1 protocol evolution, and
> provides clear guidance on how to deal with each new evolution in
> the protocol -- because new 802.1 protocols seldom disturb the EISS 
> interface and would be very explicit about how to deal with 
> compatability if a new extension to the EISS interface was
> required.
>
>
> Second, Shortest Path Briding may address some of the same problem-space
> as TRILL, but it takes a distinctly different solution. SPB, like most
> current work in 802.1, is based upon creating "clouds" with special
> characteristics out of a set of 802.1 Bridges that are directly
> connected with each other. Essentially any new feature grows out
> from a core.
>
> TRILL, by contrast can be deployed from the edges. It does not care
> what type of 802.1 Bridges provide connectivity between RBridges, just
> that the connectivity exists. A SPB-cloud, however, requires an unbroken
> chain of SPB Bridges.
>
> This distinction alone, in my opinion, justifies keeping TRILL as a
> distinct solution whatever the state of deployment of SPB or SPBB is.
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://mailman.postel.org/mailman/listinfo/rbridge
>   

_______________________________________________
rbridge mailing list
[e-mail]
http://mailman.postel.org/mailman/listinfo/rbridge