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

[Maarten Vissers <[e-mail]>]

Curtis,

It will not be amusing for an operator when he deploys LAG as you describe
in which 
- the frames with Priority X of a p2p EVC (monitored with Y.1731 Frame
  Loss Measurement OAM) are distributed over multiple links in the LAG 
- causing a reordering of these frames
- resulting in the detection of lost frames or unexpected additional frames.

The reason this will not be amusing for the operator is that his EVC support
resutls in reporting of Severely Errored Seconds and possibly Unavailable
time by his UNI-N MEP functions and by the customer's UNI-C MEP functions,
thus causing non-compliance with the SLA for this EVC service.

Regards,
Maarten


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: vrijdag 19 maart 2010 4:57
To: Maarten Vissers
Cc: [e-mail]; [e-mail]
Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP
=>~ETH aggregation?


In message <008001cac416$b5286b10$[e-mail]>
Maarten Vissers writes:
>  
>  
> Curtis,
>  
> > Using src/dst or label stack based has insures that no microflow is 
> > reordered (this is important) but does reorder traffic within the 
> > outer LSP (this doesn't matter).
>  
> In a transport network with performance monitoring it **does matter** 
> if packets with the **same CoS** are forwarded over different links.
> Performance monitoring will provide incorrect results in such case.
>  
> When you put a Section LSP over a LAG/CL, then there is 1 Section LSP 
> and performance monitoring will not be functioning.
>  
> The better alternative is to put the set of edge-to-edge LSPs over a 
> LAG/CL and to use an Ethernet Section 'VLAN' per link. Now there will 
> be many edge-to-edge LSPs that have to traverse the LAG/CL and those 
> can be distributed over the links on the basis of their edge-to-edge 
> LSP label value.
>  
> When the the LAG/CL is between PE nodes, then you can use LAG or 
> ACL-SNCG/I for the set of PW, Service-LSP and transport service layer 
> PST-LSP connections between two PEs. The distribution is on the basis 
> of PW, service-LSP or PST-LSP label values in this case.
>  
> A further alternative is to disable performance monitoring of the 
> edge-to-edge LSPs. When this is done, then it is possible to do LAG/CL 
> between two P nodes on the basis of the PW, service-LSP and PST-LSP 
> label values. The performance monitoring in the transport service 
> layer connections is not impacted by this approach.
>  
> Regards,
> Maarten


Maarten,

Its sort of amusing when someone asserts that something that has been
deployed for over a decade and works extremely well can't work.

It was amusing when ITU tried to create a profile for packet networks in the
mid 1990s and asserted that IP would never be suitable for business because
it didn't have the strict QoS that ITU had declared manditory.

It was also amusing when ITU folks asserted that voice could never be run
over IP becaus the jitter was too high and it was too unreliable.

So now you are asserting that we can't run "real transport" traffic because
we don't have the equivalent PM.  This is despite the fact that provider
like Level3 using L2VPN, then PW, have already proven it to be very cost
effective and quite satisfactory.

We are going to have to agree to disagree for now.  For those who value PM
above all else, link bundling is the only way to go.  For those that want to
create LSP larger than a LAG member and have a more dynamic distribution of
load, LAG may be a better choice.  You assert that only the latter is valid.
I assert that *both* are valid choices and that we should simply acknowledge
that and let the market decide.

So I propose that we agree to disagree and make a concerted effort to
support both the LAG behaviour that is deployed and working and the link
bundling mode that some MPLS-TP advocates prefer.

It is fine to say that implementations MUST support link bundling and MAY
support LAG and then put in the OAM entropy needed to support LAG that won't
hurt the link bundling case.  It is even easy enough to make small
enhancements to signaling to identify nodes capapable of link bundle only or
LAG and link bundle and those capable of carving out single member capacity
for link bundle LSP from capacity otherwise used for LSP over LAG.

Curtis


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: zondag 14 maart 2010 6:12
> To: Maarten Vissers
> Cc: [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: 
> ~ECMP =>~ETH aggregation?
>  
>  
> In message <005601cabe98$d2783480$[e-mail]>
> Maarten Vissers writes:
> >  
> > 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
>  
>  
> Maarten,
>  
> Thank you for reminding me that the ITU is ignoring reality.  That is 
> nothing new though.
>  
>  ->    Input to the distribution process is the CIR(EIR)
>  
> The reality is that when LSP hierarchy is used (to reduce the number 
> of labels and reduce the amount of signaling that needs to occur on a 
> fault and in doing so improve scaling) or when MPLS is applied to a 
> small high bandwidth core, the LSPs are signaled with BW values that 
> are greater than the size of a single LAG/CL member.  This is where 
> src/dst or label stack based hash has worked very well for about a 
> decade.  This information is not in the signaling of the outer LSP.
>  
> Using src/dst or label stack based has insures that no microflow is 
> reordered (this is important) but does reorder traffic within the 
> outer LSP (this doesn't matter).
>  
> Curtis
>  
>  
> > -----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