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

[Peng He <[e-mail]>]

I agree with Phil on this ' Operators are well aware of the risks of
using LAG such as giant flows on a single member link, differential
delay, etc...I think it just needs to be noted..'..


Regards,
Peng

On Mon, Mar 8, 2010 at 1:22 PM, Phil Bedard <[e-mail]> wrote:
> This seems similar to RFC 4201 which covers signaling for bundled links, as opposed to LAG.   The strongest point being no single LSP/flow can be larger than a single member link.  In the RSVP-TE case you use setup/hold priority and bandwidth reservations to determine which LSPs stay during times of reduced bandwidth.   I think Curtis (or perhaps someone else) mentioned allowing MPLS-TP to ONLY use bundling and not LAG.
>
> The problem can be solved by just not using LAG or link bundling however this increases the amount of information in the network, in the case of dynamic link information dissemination and LSP path provisioning.  It also does not allow one to oversubscribe a single link, which is one of the main reason people use LAG today.  In our network, we have LSPs >10G and an optical infrastructure only capable of supporting OTU2 transport... We rely on the entropy of data in the higher layer for even distribution.
>
> I don't think we want to specify the mechanisms for distributing traffic across the underlying lower layer links which make up the LAG.  Like has previously been said, there are many imux techniques for different Layer1 technologies.  Some use distribution techniques like byte interleaving which may not work well with mapping a single flow to a physical component.    Operators are well aware of the risks of using LAG such as giant flows on a single member link, differential delay, etc.   I think it just needs to be noted.
>
> Phil
>
>
> On Mar 8, 2010, at 3:24 AM, Maarten Vissers wrote:
>
>> Curtis,
>>
>> MPLS-TP and other packet transport technologies can be run over a compound
>> link. Such compound link can be provided by multiple section layer transport
>> paths or by multiple edge-to-edge LSPs. In both cases the nodes at the edge
>> of such compound link have to make sure that all traffic within a
>> service/transport path is transported via only one link within the compound
>> link. This to maintain e.g. the order of packets/frames within the
>> service/transport path.
>>
>> To deploy the survivability provided by compound links, ITU-T Q.9/15 has
>> developed the Adaptive Compound Link SubNetwork Group protection with
>> Inherent monitoring (ACL-SNCG/I) mechanism. This ACL-SNCG/I protection
>> controls the distribution of
>> 1) PWs, service-LSPs and service path layer PST LSPs over a service path
>> layer component links (supported by edge-to-edge LSPs) within a compound
>> link,
>> 2) edge-to-edge LSPs and transport path layer PST LSPs over a transport path
>> layer component links (supported by sections)within a compound link .
>>
>> The initial work done assumed the presence of non-adaptive media, which
>> would cause a component link to be completely available or completely
>> unavailable (as in ethernet LAG). At the moment this work is being extended
>> to also support adaptive media, which are able to reduce their bandwidth to
>> a lower level; i.e. creating a partly available state in between the
>> original two states.
>>
>> Input to the distribution process is the CIR(EIR) and relative priority of
>> each service path or transport path that is carried over the compound link
>> and the available bandwidth of each component link within the compound link.
>> The distribution process computes the distribution of the service paths, or
>> transport paths. If the bandwidth of the compound link becomes too small to
>> support all, then the lowest priority service/transport paths are blocked
>> and packets/frames of those paths are not longer forwarded over the compound
>> link.
>>
>> A service path or transport path's bandwidth must always be smaller then the
>> bandwidth of the component links.
>>
>> Regards,
>> Maarten
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Curtis Villamizar
>> Sent: vrijdag 5 maart 2010 6:51
>> To: Adrian Farrel
>> Cc: [e-mail]; Rui Costa
>> 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
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>