Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP => ~ETH aggregation?

[Curtis Villamizar <[e-mail]>]

In message <2BFD791F1A2A401DB0CBC435E0441E21@your029b8cecfe>
"Adrian Farrel" writes:
>  
> Hi Curtis,
>  
> I think I have a fundamental disagreement with you about layering.
>  
> I believe that a client layer is independent of its server layer, and that a 
> server layer is independent of the client layer.
>  
> So the OAM in the MPLS-TP layer is testing connectivity in the MPLS-TP 
> layer. If the server layer has "interesting" features, these must be tested 
> using OAM in the server layer, and faults or degradations detected in the 
> server layer will be reported at the MPLS-TP link ends.
>  
> For example, when building a composite link from a bundle of OC192s to 
> advertise as a single link in the IGP, I suspect that we run BFD over the IP 
> link to test for overall connectivity, and we run OAM on each OC192 to check 
> its connectivity. Any OC192 failure will result in a degradation being 
> reported at the IP link ends.
>  
> If we did try to architect MPLS-TP OAM to handle every potential type of 
> server technology and aggregation technique (and every possible way of 
> hashing data onto component links) I suspect we would end up with 
> outrageously complex MPLS-Tp OAM.
>  
> Cheers,
> Adrian


The client is not aware of how the service is being delivered but
needs a means to reliably determine if the service is being delivered.
Without the entropy there are situations where the client cannot
detect that the service has a fault which is undetected at the service
layer.  Testing a LAG member does not test all insegments and hash
values mapping through the forwarding hardware to that LAG member.

This is a real world problem and insegment problems (entire insegment
mapping broken in the problems of a decade ago, particularly for one
vendor) is the main reaon that MPLS has OAM capability today (BFD,
MPLS Ping, MPLS traceroute).  Reducing the reliability of that
capability in MPLS-TP would be a step backwards.

Curtis


> ----- Original Message ----- 
> From: "Curtis Villamizar" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>; "Rui Costa" 
> <[e-mail]>; <[e-mail]>
> Sent: Friday, March 05, 2010 5:50 AM
> Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP => 
> ~ETH aggregation?
>  
>  
> >
> > In message <21AFCCB59EFE4816B26E280DF3355CE2@your029b8cecfe>
> > "Adrian Farrel" writes:
> >>
> >> Surely the formation of the server layer and the use of OAM within the
> >> server layer is entirely an issue for the server layer.
> >>
> >> It is a mistake for the MPLS-TP layer to be aware of the underlying
> >> technology that provides the link connectivity between to adjacent LSRs. 
> >> The
> >> links provided by the server layer have certain resiliency and recovery
> >> properties, as well as properties associated with in-order (or not) 
> >> packet
> >> delivery that are announced to the MPLS-TP network (usually through
> >> configuration) and the MPLS-TP network can choose which links to use
> >> accordingly.
> >
> > The goal is to make OAM work by adding entropy.  If there is no
> > underlying LAG, then the entropy serves no purpose but does no harm.
> >
> > If there is an underlying LAG then not having entropy allows the OAM
> > traffic to test only one member.  For example, if an MPLS LSP hop
> > (section) is a LAG, traffic within that MPLS LSP would take different
> > LAG members if the entire label stack was not the same for all traffic
> > or if the LSP carried IP traffic from more than one host pair.  If the
> > OAM traffic had a fixed label stack it would test only one LAG member.
> >
> >> LAG at a server Ethernet layer is a way of providing a composite link to 
> >> the
> >> MPLS-TP layer. That link has specific properties, but the MPLS-TP layer
> >> cannot be expected to take specific measures to operate the link. That is
> >> the job of the server layer itself (noting that the adaptation into the 
> >> LAG
> >> is a function of the server layer, just as the operation).
> >
> > If CL is allowed for MPLS-TP, then OAM must work for CL.  We should
> > not knowingly just specify something that is broken.
> >
> >> So, the MPLS-TP layer runs OAM across the link. It doesn't know how the 
> >> link
> >> is formed. It is the responsibility of adaptation function to either
> >> distribute the MPLS-TP packets across the group members such that link
> >> degradation will be noticed by the MPLS-TP layer (this could be noted as 
> >> a
> >> requirement that the MPLS-TP layer puts on the server layer that link
> >> degradation should be detectable by any measure of MPLS-TP packets); or 
> >> the
> >> server layer must perform its own OAM to detect link degradation and 
> >> report
> >> it to the MPLS-TP layer at the link end points.
> >
> > For plain old MPLS, it doesn't know about any LAG either, but the
> > 127.x source addresses add the entropy needed to provide effective
> > OAM.  That is why IETF specified MPLS Ping and and rejected 1711 and
> > why MPLS Ping works and 1711 doesn't work.
> >
> >> LAG is not the only "complex" way of forming links in the MPLS-TP network
> >> from multiple links in the server network, and we really don't want to
> >> embark on making MPLS-TP understand each and every server technology.
> >>
> >> Cheers,
> >> Adrian
> >
> > However, any method which is capable of supporting an LSP that is
> > greater in capacity than any one component link needs to look below
> > the top label to do so.  I think that is trivailly provable given that
> > the top level is always the same for that LSP.
> >
> > Therefore no matter what we define CL to be, if this CL supports LSP
> > of greater than a LAG member size, a capability we currently have with
> > Ethernet LAG or ECMP over parallel links (another form of link
> > aggregation that predates Ethernet LAG by over a decade), then OAM
> > needs to provide entropy to insure that any CL/LAG/ECMP along the path
> > is exercised.
> >
> > Curtis
> >
> >
> >> ----- Original Message ----- 
> >> From: "Stewart Bryant" <[e-mail]>
> >> To: <[e-mail]>
> >> Cc: "Rui Costa" <[e-mail]>; <[e-mail]>
> >> Sent: Wednesday, March 03, 2010 10:59 AM
> >> Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP 
> >> =>
> >> ~ETH aggregation?
> >>
> >>
> >> > Curtis Villamizar wrote:
> >> >> In message <[e-mail]>
> >> >> Stewart Bryant writes:
> >> >>
> >> >>>  I would think that if the operator wanted the bandwidth more than 
> >> >>> they
> >> >>> wanted the fate sharing, they will deploy the technology.
> >> >>>  - Stewart
> >> >>>
> >> >>
> >> >>
> >> >> There is no reason not to put some entropy in the extension to MPLS
> >> >> Ping so that there was fate sharing over LAG.
> >> >>
> >> >> Curtis
> >> >>
> >> >>
> >> > Curtis
> >> >
> >> > Do you have some text in mind?
> >> >
> >> > - Stewart
> >> > _______________________________________________
> >> > mpls-tp mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/mpls-tp