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

["Adrian Farrel" <[e-mail]>]

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
>> > _______________________________________________
>> > mpls-tp mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mpls-tp
>
>