On Thu, Dec 4, 2008 at 9:40 PM, Tony Li <[EMAIL PROTECTED]> wrote: > Right now, when we're doing L3 switching on an IP header, I consider that to > be the atomic primitive, regardless of the L2 encapsulation. > > What has changed has been the introduction of these 'L2.5' technologies like > MPLS. There we switch based on the label, not on the real payload > addressing, and it does introduce complexity.
Hi Tony, I say I MPLS is a plain old layer-3 technology that happens to run another layer-3 technology on top of it. I say GRE is the same. And I say that ethernet frames in the current incarnation of ethernet are also a layer 3 technology, with packets stored and forwarded in a switched network that can and in many cases does span hundreds of forwarding nodes. Only the logic that recognizes the start and end of the frame over what these days is a point-to-point link between host and switch still qualifies as layer-2. Calling ethernet frames layer-2 merely because in the ethernet of two decades ago they really were treated as layer 2 just serves to confuse the architectural discussion with a distinction that has long since ceased to exist. They're all layer-3 technologies today. We stack up as many layer-3 protocols as we need to to get to layer 4 and we use a mapping function or protocol at each level of the layer-3 stack to find the right address at the next level down. "Map-encap" just adds another layer-3 level to the two or three that are *already there*. While useful as shorthand, we all know the OSI Network Model is fubar. It would be a shame to let it box in our thinking. > Are we very sure that that model is what we're willing to live with moving > forward? Consider that some MPLS implementations, as part of the MPLS > switching operation, grovel all the way up the label stack and find the IP > header to hash its addresses so that they can correctly do ECMP. Is that > the kind of architecture that we consider clean and neat? I'll cede the point because: A) This is not an inherent limitation of map-encap systems. TRRP functions quite happily with the ITR directly on the originating host and the end-user application software in full control of its behavior. B) The notion of stripping the host of any architectural possibility of interacting directly with the network core makes me pretty nervous too. Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
