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

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

    I am not sure this would be unique to OAM; its directly related to the
underlying data plane (and trouble-shooting it).  In our client/server layer
parlance, its unique to one type of supported server layer, but concievably
could be of others in the future.

    --Tom



On 3/5/10 2:46 PM, "David Allan I" <[e-mail]> wrote:

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