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

[<[e-mail]>]

Adrian....bottom-line is you are technically right...more in-line: 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 05 March 2010 19:19
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Comments on 
> draft-fbb-mpls-tp-data-plane-00: ~ECMP =>~ETH aggregation?
> 
> Hi Curtis,
> 
> I think I have a fundamental disagreement with you about layering.

NH=> Join the queue!
> 
> I believe that a client layer is independent of its server 
> layer, and that a server layer is independent of the client layer.

NH=> This is the way it should be Adrian.  Unfortunately this is not the
case with MPLS.  The mere fact that PWs exist shows that MPLS failed to
get layering right.  MPLS-TP really should fix this if it wants to be
taken seriously as a transport network.  Sadly, this does not look like
it is going to happen....hard-nosed commercials and soft-nosed
face-saving/embarassment hold-sway.  
> 
> 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.

NH=> Totally correct Adrian.  But there is a little more to it than just
this:

1	The principle service a server layer transport network provides
to its clients is *transparency* (of information transported).  This has
several implications, but a key one is that the server layer must not
attempt to understand the information contained in the client
symbols...and it for sure must not change these client symbols.  LAG and
any type inverse muxing in some server layer network must make specific
assumptions not only about the client traffic unit structure but also
about the importance (also see next item) of client traffic
units.....this type of DPI/snooping is a very, very bad idea for a
server layer transport network....indeed, it indicates an immediate
failure of purpose as it obviously violates the key transparency
requirement.


2	In all networking cases there must be a top-of-stack network
technology present that supports the external message/file/stream
applications.  IP is dominant in this role.  Most other technologies,
including Ethernet where LAG came from and also MPLS, currently cannot
fulfil this role.  It is only in this top-of-stack network that one can
say anything meaningful about importance.....noting that:
-	importance has no relationship to the application type....any
message/file/stream application can assume any importance...and this is
why all successful transport networks (to date all such network are
co-cs mode) must make no judgement on this metric, ie all client *bits*
(a bit is the atomic information symbol) are treated equally and
ordering of bits is preserved....this is also why a transport network
must not have any QoS (sic) classes, and indeed the co-cs mode
does-not/cannot have any QoS classes.
-	the above is not simply wrt *within* client instance X but
applies *across* all client instances of the server layer....in other
words it is even more meaningless to try and make importance judgements
*between* applications in different client service instances
-	in a cl-ps network the traffic unit must carry the importance
semantic...indeed the traffic unit must carry full information labels
wrt SA, DA and PID.....one can take no labelling short-cuts in the cl-ps
mode
-	in a co-ps or co-cs network network it is the parent connection
that carries the importance semantic and *not* the child traffic
units...and it is because the parent connection contains implicit
information itself that we can take some labelling short-cuts in the
child traffic units, eg omit SA, omit PID, reduce scope of DA label to
link unique.

> 
> 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.

NH=> Exactly so, this is why we need client and server independence.
What you also saying (a little differently to how I would) is that we do
not have transparency here.  It's obvious from Curtis's comments he does
not grasp these issues very well....which is why he also thinks adding
arbitrary 'entropy' 127/8 SA labels in *client* IP OAM ping pkts is a
good way to test the ECMP layering violations that usually come with
*server layer* LDP.  The problem here is the server layer merging LDP
and its layering violating ECMP bedfellow.  Adding entropy (what a grand
name for stating we have no idea what we are testing!) is not a great
OAM idea in a transport network as Dave as already pointed out. 

regards, Neil
> 
> 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
>