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

["Thomas D. Nadeau" <[e-mail]>]

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