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

[<[e-mail]>]

None of this is LAG specific the problem space is broadly the same for all
server layer links that employ inverse multiplexing to offer higher
bandwidth than a single link in the server layer is capable of supporting.

I don't think we want to get bogged down in the details but just note that
server layer paths may in reality be composed of multiple links presented to
MPLS-TP as a single server layer path and that special care is required when
designing for such scenarios.

Ben
 


On 03/03/2010 16:00, "Alexander Vainshtein"
<[e-mail]> wrote:

> Adrian, Rui, and all,
> 
> I think that LAG presents two aspects of behavior that should be addressed (or
> at least noted) if we're going to use it in MPLS-TP.
> 
> 1. Effective BW of LAG (treated as a single link) depends on actual client
> traffic carried across and on the way this traffic is adapted into LAG client
> layer. E.g., if distribution uses hashing on the label stack, the same client
> traffic pattern could result in different effective BW depending on actual
> label allocation for specific flows. This effect exists even when the number
> of "live" links comprising a LAG does not change. And IMHO this behavior is
> (more or less) specific for LAG. (Well, effective BW of an Ethernet link also
> depends on actual traffic due to IPG and Preamble overhead; but the effect is
> not so noticeable, and does not depend on the way client is adapted into LAG).
> As a consequence, traffic engineering that involves LAG-based links looks more
> complicated.
> 
> 2. Effective BW of LAG (treated as a single link) can change as its comprising
> links go down and up.
> This behavior can be found in many other situations; VCAT with LCAS is one
> obvious example, and radio links with adaptive code modulation present another
> example (more difficult since link BW becomes a function of the weather
> conditions). 
> 
> This does not say that LAG cannot be used with MPLS-TP; only that its usage
> involves new challenges.
> 
> My 2c,
>      Sasha
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Adrian Farrel
> Sent: Wednesday, March 03, 2010 1:27 PM
> To: [e-mail]; [e-mail]
> Cc: Rui Costa; [e-mail]
> Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =>
> ~ETH aggregation?
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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
> 
> ----- 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