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

["tom.petch" <[e-mail]>]

Neil

It is time you wrote
 draft-harrison-mpls-tp-getting-layering-right-00.txt
I could write it myself with what I have learnt from you but you
would still do it much better than I.

It is needed. Whether or not it is adopted by MPLS TP, the IETF needs
it on record.  MPLS is a very successful protocol, yet it could have been
significantly better, and that now shows with efforts to enhance it (shades
of IPv4:-).

The necessary changes may not happen this time around, but unless what
you say is recorded in the traditional archive of the IETF, the RFC series,
then the IETF may make the same mistakes again, with this or another
successful(!) protocol.

Tom Petch

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, March 05, 2010 10:38 PM
Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP=>~ETH
aggregation?


> 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
> >
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp