Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

From: <[email-masked]>
Date: Tue, 10 Mar 2009 10:45:54 -0000

Thanks Sasha....I am so pleased someone else has latched on to this (but
to be fair I do think others have understood what I meant here, eg
Adrian F, John D and Malcolm B).  I have tried to clarify a little
further below:

Sasha wrote 10 March 2009 05:54
 
> I must say that I find Neil's statement below about MPLS-TP 
> NOT being a profile 
> of the existing MPLS most worrying.

NH=> Please don't.  This should not been seen as a cause for concern.
This all comes back to what defines a layer network...and most important
here is to simply think of the access points and whether they can
communicate with each other (and one can see immediately that the
addressing of access points is key here, but it is not the only thing as
we also require consistent Characteristic Information (CI)).  Let me
give a couple of examples to illustrate what I mean and then I'll come
back and deal with MPLS/MPLS-TP.

IPv4 and IPv6 are examples of 2 quite different IP cl-ps mode layer
networks.  This one is quite obvious, the traffic unit (ie packet) has a
different structure (ie the CI is different) and they have different
addressing formats.  Quite clearly an IPv4 access point cannot directly
communicate with a IPv6 access point.
  
IMPORTANT ASIDE => Both these IP layer networks are what I have started
to call 'top-of-stack', and what I mean by this is that they do not
normally support higher layer networks but they do support end-system
adaptation functions for message/file/stream applications, eg
UDP/TCP/RTP.  This issue (ie whether a network is top-of-stack or not)
is crucial when we come to consider peer-interworking....the simple rule
is 'if not top of stack then we do not need peer-interworking across
E-NNIs.'....we would just make unnecessary work/cost for ourselves doing
that.  And this is important for MPLS and MPLS-TP cases, as neither of
these are top-of-stack networks...ergo they have no need to interwork as
peers.

Consider now the SDH VC4 and VC12 layer networks.  Here it is very
obvious that we cannot connect a VC4 access point to a VC12 access
point....the CI is very different.  However, the access points of both
the VC4 and VC12 layer networks could have exactly the same addressing
format;  they simply exist in a different layer network space.  Moreover
they can use the same OOB CP (say GMPLS), though they are quite
different instances of the CP.

Now consider Ethernet and PBB-TE.  Here the traffic unit looks
identical.  They may even use the same addressing format for access
points.  However Ethernet is a cl-ps mode layer network and PBB-TE is a
co-ps mode layer network, so we clearly cannot interwork them directly
as peers (there will be conflicts of the CP and the DP OAM, eg AIS/FDI
must never appear in a cl-ps mode network, which is why IEEE threw this
out of 802.1ag (though it is still in Y.1731)).

What I am trying to show here is that it is very common, and indeed
sensible, to want to **re-use** components (like addressing, CP
signalling/routing, and even traffic units in the Ethernet/PBB-TE case)
in **different layer networks**.  The fact that they don't interwork as
peers is also very common...and often we take this for granted and don't
even really think about it, eg VC4 and VC12 SDH cases.

Let me now come back to MPLS and MPLS-TP.  MPLS is not singular in
itself, but it is also not like a normal layer network because it allows
both MPLS and IP traffic units to co-exist in the DP and this creates an
immediate/obvious problem wrt not having consistent CI...something that
MPLS-TP must fix and will fix.  Moreover, the traffic units of an MPLS
LSP only have context wrt to the protocol that created them, eg LDP,
RSVP-TE and MP-BGP4 can all create MPLS LSPs/traffic units...and it
should be intuitively clear that, for example, MPLS traffic units issued
from an LDP access point are not 'meaningful' to an RSVP-TE access point
(which is why you may have seen me remark in the past that even though
the DP traffic unit CI is not consistent in MPLS we ought to at least
try and get the DP OAM consistent, because if DP traffic does get
misconnected then the sink access point will always process the DP OAM
in same/consistent manner and correct;y detect the defect).

Now MPLS-TP will remove most of the major CI problems in MPLS, and it
will also remove the merging problem.  This has an immediate very
profound effect that PWs are not relevant to MPLS-TP.  Indeed all
clients will be treated equally.  Further, we will add a PPP-based PID
to the DP (assuming we adopt Stewart's draft
draft-bryant-pwe3-packet-pw-00.txt) and will will add the GMPLS based
logically OOB CP.  We may even add different OAM.  All this means that
MPLS-TP will be a different layer network instance to any curent spin of
MPLS.  This is just a fact and nothing to get worried/upset about.
However, what we should not do is generate FUD with talks of 'bacakwards
compatibility' and 'peer interworking' with MPLS as-is....all of this is
not necessary...and as I noted above no variety of MPLS is top-of-stack
so peer interworking them is a non-issue.  All we are doing with MPLS-TP
is re-using existing MPLS (and GMPLS for the CP) components to create a
new layer network.

Hopefully that helps clear things up a bit.

> 
> My worry has been initially triggered by a string of specific 
> proposals on this list which, 
> if accepted, IMHO and FWIW, would mean exactly that. (One 
> recent example 
> is the proposal to restrict MPLS-TP to using only 
> per-interface label state.)
> 
> Neil's message makes this trend explicit (which is good!), 
> and, IMHO, calls for some action.

NH=> The main action we need Sasha is a bit more honesty and to start
getting things done architecturally right.  For example, I'd like to see
everyone accept that MPLS-TP will not have PWs....it's just a fact
guys....look at is as an improvement over MPLS, because that is exactly
what it is.

I would also like to see:

-	the DP OAM look identical to DP traffic....this is such an
obvious thing to get right I find it hard to understand those who argue
against it.  So if we are going to use
draft-bryant-pwe3-packet-pw-00.txt for the new MPLS-TP DP adaptation
(though I do struggle to understand why the CW is useful here...GFP
ought to be looked at at least for adaptation, and this also has a PID
field), then the OAM indicate flag needs to be here....not sitting under
the GAL;

-	I'd like to keep CP/MP protocols cleanly seperated from the DP
traffic and DP OAM.

> 
> I believe that the agreement (worked out by the JWT) to 
> develop MPLS-TP as the profile of MPLS 
> (and not as something very else) is the sole justification for:
> (a) Sharing protocol numbers between MPLS and MPLS-TP (so 
> that the two cannot be distinguished in
> in the data plane)
> (b) Developing MPLS-TP at IETF.
> 
> If the JWT-defined framework is broken, what remains?

NH=> I'd suggest we exercise some common sense now.  MPLS is not
singular anyway as I have tried here and many times previously to point
out.  Since we are not going to interwork them (and we don't now if you
think about is, ie we don't interwork LDP and RSVP-TE access points)
then this is a moot point IMO.

I simply want to try and get MPLS-TP into the best shape that is
possible.  And I think we can do that if there is the will to do this.
Needs some honesty however.

regards, Neil
> 
> Regards,
>      Sasha
> 
> ________________________________________
> From: [email-masked] [[email-masked]] On 
> Behalf Of [email-masked] [[email-masked]]
> Sent: Monday, March 09, 2009 7:14 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements  
> forMPLS(-TP)    overMPLS(-TP)
> 
> Thanks Stewart,  please see in-line:
> 
> Stewart Bryant wrote 09 March 2009 15:08
> >
> > Loa Andersson wrote:
> > > Malcolm,
> > >
> > > Malcolm Betts wrote:
> > >> Ben, see in line below - I have snipped some text for clarity:
> > > <snipped even more - Loa>
> > >
> > >>
> > >> I think that the requirements draft should indicate that
> > all frames,
> > >> i.e. client data, OAM, SCC, MCC, etc MUST receive
> > identical treatment in
> > >> the data plane and therefore MUST use the same header structure.
> > >
> > > all packets with the same label on top will get the same 
> treatment,
> > > given that the TC field is the same, won't they? Is this
> > what you mean
> > > by "header structure" or did I miss something
> > >
> > > /Loa
> > >>
> > >
> > >
> >
> > There is a bunch of confusion about what happens in MPLS networks.
> 
> NH=> I agree.  And I think one of the most worrying things I 
> am seen is
> to assume that MPLS-TP will somehow just be a profile of what MPLS is
> today.  It won't be.  Sure we will re-use many component parts, but we
> will also be adding some new ones like a PID field in the DP, probably
> new OAM and we will be taking CP/MP functions logically OOB 
> wrt traffic
> DP.
> 
> Of a more general/practical architectural note however is 
> that MPLS (any
> spin) and MPLS-TP are *not* top-of-stack layer networks, and 
> this means
> there in no sense in trying to interwork them as peers.  They will
> either carry other non top-of-stack layer networks (so this 
> one is very
> obvious reason as to why peer interworking is not required, ie
> MPLS/MPLS-TP terminated either side and only client passed
> transparently)  or IP which is the top-of-stack layer network 
> (and here,
> ie in the IP layer, peer interworking is vital).
> 
> So any arguments based on being backwards compatible with 
> existing MPLS
> make little real sense.
> 
> >
> > In transport networks - set up statically or via GMPLS only
> > the top label
> > effects the path (although TC effects the queuing).
> 
> NH=> Strictly speaking Stewart a transport network should be fully
> transparent and treat all client symbols equally (which is what all
> co-cs mode networks do and it is one reason why they are so 
> succesful as
> transport networks).
> >
> > There are no standard methods for looking at any other label and in
> > any case this is only done in networks where the path is chosen
> > by an IGP.
> >
> > If we always use a PW then the requirement for client data, 
> OAM, SCC,
> > MCC to receive identical treatment in the path to the PE
> > occurs because
> > the label stack is identical.
> 
> NH=> The stark technical reality is that when we create MPLS-TP (by
> doing things differently to LDP MPLS)  then there is no need 
> for PWs (or
> even the CW)...all clients get treated equally, they have to 
> be else it
> won't be transport network.....so every client is a PW if you like
> (which kind-of makes the name PW and any distinction inferred by this
> quite irrelevant).
> >
> > The only case where the label stack will be different is when we are
> > carrying an LSP OAM in which case the GAL needs to be present.
> 
> NH=> This is both my original and Malcolm's point.  The defect
> detection/handling OAM very clearly belongs to the DP and it 
> should have
> an identical (in all respects) header to a normal traffic 
> unit.  This is
> why I said to you Stewart that if you are proposing
> http://www.ietf.org/internet-drafts/draft-bryant-pwe3-packet-pw-00.txt
> as the DP encaps for MPLS-TP then the OAM indicate function 
> needs to be
> in here, eg as a PPP codepoint say.  I don't see why we need the CW as
> its not doing much useful (as adapatation) but if you really want it
> then keep it.  But we should ensure that the OAM indicate is here and
> not under the GAL, else the DP OAM header will have a different format
> to normal DP traffic.
> 
> regards, Neil
> >
> >
> > Stewart
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 10 Mar 2009 19:26:37 +0000

My 2p

> is re-using existing MPLS (and GMPLS for the CP) components to create a

I see no need to peer interwork MPLS & MPLS-TP. When I speak of backwards
compatibility I mean ensuring that any new functions (e.g. Different OAM)
that is introduced for MPLS-TP must also be backwards compatible such that
it can be used if appropriate on existing deployed MPLS estate.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 10 Mar 2009 16:04:39 -0400

> it can be used if appropriate on existing deployed MPLS estate.

	Agree %100.

	--Tom