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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
David Allan I writes:
>  
> Hi Curtis:
>  
> I agree than in the absence of snooping of ACH TLVs an entropy label
> is the only other alternative to add entropy specifically to OAM
> flows.

And since existing hardware, just about any core router built in the
last decade, already hashes on the label stack, this works with
existing forwarding hardware where snooping the ACH TLVs would not.

> However if you assume labels are the only input into entropy, you have
> a problem in that a LAG would then decouple the OAM from the flow it
> is to fate share with simply because of the existence of the
> GAL. Adding an entropy label would only muddy the waters further...

Hardware should ingore labels 0-15 in the hash computation.  If
existing hardware does not, then new hardware should.  In the single
label on the label stack case if LAG behavior decoupled the GAL
traffic from payload, an entropy label on the OAM would insure that
the path taken by traffic was tested at least some of the time.

> Something would think a LAG broke if it broke, but somewhat unlikely
> the right thing would know...OTOH that would be the status quo
> anyway...with or without...

Did not parse.

What I think you were getting at is that some intuition says that if a
member is broken the server layer would know about it.  Where that is
not the case is where the member is carrying traffic but has an
insegment misprogramming on one or more ASIC.  The server layer
injects traffic beyond that point and exercises only the outsegment.

> Hmmmm
> D
>  
>  
>  
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Sunday, March 07, 2010 3:23 PM
> To: David Allan I
> Cc: Thomas D. Nadeau; Adrian Farrel; [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP => ~ETH aggregation? 
>  
>  
> In message <[e-mail]>
> David Allan I writes:
> >  
> > Such a requirement could only be considered if it did not ADD an additional point of failure...
> >  
> > An entopy mechanism unique to the OAM subsystem would fall under the cateogy of things that added points of failure, hence was actually detremental to overall system reliability...
> >  
> > My 2 cents
> > D
>  
>  
> No additional point of failure is added.  I think fat-pw is already in
> use in non MPLS-TP context.
>  
> Maybe an example would help.
>  
> Consider layer A, B, C.  B is a client of A.  C is a client of B.
> Lets not try to assign administrative boundaries as it is irrelevant
> at this point.  At layer B it is helpful to be able to verify that the
> service being provided at layer A actually works.  There is no way for
> layer B to predict or control the label stack added by layer C, but
> that label stack creates entropy in the payload that layer B must
> provide.  If the OAM does not have any entropy, then layer B cannot
> verify that its own LSP or PW is delivering the service promised to
> layer C.
>  
> If there is no LAG within layer A, then the additional label in the
> stack has no effect since layer A looks only at the top of stack for
> both ordinary payload and layer B OAM traffic.  If there is a LAG
> within layer A, then all members of the LAG are exercised, although
> somewhat randomly.  With entropy, layer B and can detect an error
> within layer A, but cannot diagnose it.
>  
> Using PW with fat-pw (draft-ietf-pwe3-fat-pw-03) the two ends
> negociate to determine that both ends can handle an extra label below
> the PW label.  If so the stack has a various TE labels, the PW label,
> and then the entropy label, then a PW control word that indicates
> either client payload or GACH and OAM.  The existing MPLS Ping uses a
> 127.x destination address to add entropy.  The extension to MPLS-TP
> extension to MPLS Ping can use fat-pw with PW but needs an equivalent
> capability with GAL.
>  
> Putting an entropy label at the BOS below the GAL label provides an
> equivalent solution to fat-pw.  Vendors who recognize a need for this
> have two options.  Just do it as a configured option and float an
> informational draft with no signaling or define signaling for use with
> GAL that is equivalent to the fat-pw signaling.
>  
> Curtis
>  
>  
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of Thomas D. Nadeau
> > Sent: Friday, March 05, 2010 2:35 PM
> > To: Adrian Farrel; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP => ~ETH aggregation?
> >  
> >  
> >     Adrian,
> >  
> >     While I agree %100 with you about layering violations, I am not sure that Curtis is asking for one. I think what he is asking for a mechanism to exercise the entropy of the server layer if it exists, as a general means of interfacing between the client/server layers. It would seem like a reasonable part of the "interface" between the two layers to be able to specify this, but only if done in a way independent of the specific server type, because as you say, that would create a nightmare of combinations for the client to support.  It might be good to add this as an additional requirement to the MPLS-TP (general or OAM) requirements.
> >  
> >     --Tom
> >  
> >  
> >  
> > On 3/5/10 2:18 PM, "Adrian Farrel" <[e-mail]> wrote:
> >  
> > > 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
> > > ----- 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