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

Adrian,

I interpreted Curtis to mean that the MPLS layer was managing the bundled link itself.  If the bundled link was managed by a lower layer, that lower layer wouldn't necessarily understand the label stack, including the entropy label.  One could almost say that, by definition, if the layer managing the bundled link understands the label stack, it is part of the MPLS layer.

I think it would be useful to remove the stipulation that for MPLS-TP the GAL must have the BOS bit set.

Thanks,

John

> -----Original Message-----
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf
> Of Adrian Farrel
> Sent: Wednesday, March 03, 2010 3:27 AM
> To: stbryant@cisco.com; curtis@occnc.com
> Cc: Rui Costa; mpls-tp@ietf.org
> 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" <stbryant@cisco.com>
> To: <curtis@occnc.com>
> Cc: "Rui Costa" <RCosta@ptinovacao.pt>; <mpls-tp@ietf.org>
> 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 <4B87B8C7.5010406@cisco.com>
> >> 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
> > mpls-tp@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp