Subject: [mpls-tp] A best-case solution for MPLS-TP

From: <[email-masked]>
Date: Wed, 24 Dec 2008 13:15:37 -0000

Folks,

Here are a set of proposals that, IMO, will result in the simplest and
best-case solution for MPLS-TP.   I've omitted any detailed
analysis/arguments.

I would like to hear opinions for/against each of these + any supporting
arguments.

1	OOB CP/MP which re-uses GMPLS for the CP:
This requires a reserved label (X say) from the 0-15 set which never
appears in the traffic DP as a forwarding (or other semantic) label.

2	A transparent MPLS-TPoverMPLS-TP client server relationship:
If folks wish to keep the notion of sublayering (ie same party CP/MP
ownership across set of nested LSPs), which is implicit in the use of
the S-bit in MPLS, then we need a way to functionally isolate different
sublayer LSP stacks.  The best (for many reasons) solution here is to
use a further reserved label (Y say) from the 0-15 set which can only
appear in the DP as part of the (server owned/applied) client/server
adaptation and has the globally well known semantic of "label Y
indicates a DP/CP/MP functional separator between the LSP sublayers
above and below label Y".

This technique can also be used for the cases of MPLSoverMPLS-TP and
MPLS-TPoverMPLS.

3	OAM indicate:
The DP OAM used for defect detection/handling should be as simple/sparse
as possible and look (and be processed) as close as possible to normal
DP traffic units......the use of an additional DP label header
specifically for an OAM alert function should therefore be avoided if
possible.  This type of OAM should be inserted/extracted at LSP trail
termination points.  There is currently no OAM indicate field in the
MPLS header.  However, since MPLS-TP will be a co-ps mode technology
there is no requirement for a TTL field in the traffic unit header.
Indeed, the GMPLS CP (or the MP) will be able verify there are no loops
prior to activating a MPLS-TP LSP (just like GMPLS does for the co mode
technologies it controls today).  Given that the TTL field represent 25%
of the MPLS-TP header it is important to be able to re-use this field
wisely.  An OAM indicate function only requires 1 bit here.

4	PWs and the CW/AC relationships:
PWs were a product of how MPLS was originally specified...but those
causal drivers must be removed in MPLS-TP.  Further, it is important to
understand that we should not create an unnecessary co-ps mode layer
network above MPLS-TP....this rather defeats the whole purpose of
MPLS-TP.  So if PWs are retained in MPLS-TP they must revert to a form
of adaptation and not become a network entity (like an MPLS-TP LSP is).
If one analyses the CW one finds little of real value worth retaining in
an adaptation role.  The AC seems to hold more potential value
however.....though I would suggest more thought is given to
distinguishing functional uses that more correctly belong in the OOB
CP/MP (ie and thus should use label X as per item 1 above) from those
that more correctly belong in the traffic DP.

If the AC is retained we need to indicate when the payload is AC.  I
would argue this should be via a normal MPLS-TP header field...just like
the case for the OAM noted in 3 above.  And if the TTL field is
recovered then another bit flag here would be ideal (rather than
imposing another DP label).

5	CSI vs PPI (Client/server interworking vs peer-partition
interworking):
When we are dealing with a non-top-of-stack layer network (and both MPLS
and MPLS-TP are like this, but so is Ethernet...IP is NOT however, as it
is designed to be able to fulfil a top-of-stack role) then there is no
need whatsoever to try and interwork any of the DP/CP/MP components. 

6	TCM OAM sublayers:
MPLS-TP should not use nested TCM OAM sublayers.  Just like the point
wrt S bit noted above, TCM implies sublayers, and this in turn implies a
common CP/MP across those sublayers....and since we have to address this
issue as noted above in 2 for MPLS-TPoverMPLS-TP we should not allow
this situation to be recreated with TCM when multiple different parties
are involved.

If folks want to segment an end-end LSP for OAM diagnosis purposes (this
is NOT the same as defect detection/handling OAM) then we should look to
use more simple ways of tapping-off an end-end OAM flow at intermediate
points (which should a rare event anyway) instead of burdening the whole
network with a complex set of sublayering configuration costs/problems.

Merry Xmas everyone....look forward to hearing your views on the above.

regards, Neil

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 24 Dec 2008 10:48:16 -0800

Inline 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>Sent: Wednesday, December 24, 2008 5:16 AM
>To: [email-masked]
>Subject: [mpls-tp] A best-case solution for MPLS-TP
>
>Folks,
>
>I would like to hear opinions for/against each of these + any 
>supporting arguments.
>
>
>This requires a reserved label (X say) from the 0-15 set which 
>never appears in the traffic DP as a forwarding (or other 
>semantic) label.

JD:  Reserved label in what?  The GMPLS CP uses IP packets.

>If folks wish to keep the notion of sublayering (ie same party 
>CP/MP ownership across set of nested LSPs),

JD:  I am assuming that you are referring to LSP Hierarchy?

>which is implicit 
>in the use of the S-bit in MPLS, then we need a way to 
>functionally isolate different sublayer LSP stacks.

JD:  Since each label stack is self contained, I think this isolation is
already there.  I.e., there doesn't seem to be anything to preclude
multiple label stacks in a given packet.

>The best 
>(for many reasons) solution here is to use a further reserved 
>label (Y say) from the 0-15 set which can only appear in the 
>DP as part of the (server owned/applied) client/server 
>adaptation and has the globally well known semantic of "label 
>Y indicates a DP/CP/MP functional separator between the LSP 
>sublayers above and below label Y".

JD:  Andy Malis (I think) and I are assuming that MPLS, IP, and PWs (at
least) will be reusing a server MPLS LSP.

Presumably this label is only present when the payload is MPLS?

Does it provide any utility to the egress client in demultiplexing MPLS,
IP, and PW packets?

Does it provide any utility to the egress server in providing
server/client demarcation, given that the end of stack bit is set in the
server stack?

How would the ingress server know to place this label in the server
label stack? 

>
>This technique can also be used for the cases of 
>MPLSoverMPLS-TP and MPLS-TPoverMPLS.
>
>
>3	OAM indicate:
>The DP OAM used for defect detection/handling should be as 
>simple/sparse as possible and look (and be processed) as close 
>as possible to normal DP traffic units......the use of an 
>additional DP label header specifically for an OAM alert 
>function should therefore be avoided if possible.  This type 
>of OAM should be inserted/extracted at LSP trail termination 
>points.  There is currently no OAM indicate field in the MPLS 
>header.  However, since MPLS-TP will be a co-ps mode 
>technology there is no requirement for a TTL field in the 
>traffic unit header.
>Indeed, the GMPLS CP (or the MP) will be able verify there are 
>no loops prior to activating a MPLS-TP LSP (just like GMPLS 
>does for the co mode technologies it controls today).  Given 
>that the TTL field represent 25% of the MPLS-TP header it is 
>important to be able to re-use this field wisely.  An OAM 
>indicate function only requires 1 bit here.

JD:  I think a label, rather that a bit in the MLPS header, will improve
the veracity of an OAM packet's transit of the data plane.  Plus, I
think changing the MPLS header at this point is a non-starter.

>PWs were a product of how MPLS was originally specified...but 
>those causal drivers must be removed in MPLS-TP.  Further, it 
>is important to understand that we should not create an 
>unnecessary co-ps mode layer network above MPLS-TP....this 
>rather defeats the whole purpose of MPLS-TP.  So if PWs are 
>retained in MPLS-TP they must revert to a form of adaptation 
>and not become a network entity (like an MPLS-TP LSP is).
>If one analyses the CW one finds little of real value worth 
>retaining in an adaptation role.  The AC seems to hold more 
>potential value however.....though I would suggest more 
>thought is given to distinguishing functional uses that more 
>correctly belong in the OOB CP/MP (ie and thus should use 
>label X as per item 1 above) from those that more correctly 
>belong in the traffic DP.
>
>If the AC is retained we need to indicate when the payload is 
>AC.  I would argue this should be via a normal MPLS-TP header 
>field...just like the case for the OAM noted in 3 above.  And 
>if the TTL field is recovered then another bit flag here would 
>be ideal (rather than imposing another DP label).

JD:  Agreed, except for my comment above about using a label rather than
an MPLS header bit

>When we are dealing with a non-top-of-stack layer network (and 
>both MPLS and MPLS-TP are like this, but so is Ethernet...IP 
>is NOT however, as it is designed to be able to fulfil a 
>top-of-stack role) then there is no need whatsoever to try and 
>interwork any of the DP/CP/MP components. 

JD:  Agreed

>
>
>6	TCM OAM sublayers:
>MPLS-TP should not use nested TCM OAM sublayers.  Just like 
>the point wrt S bit noted above, TCM implies sublayers, and 
>this in turn implies a common CP/MP across those 
>sublayers....and since we have to address this issue as noted 
>above in 2 for MPLS-TPoverMPLS-TP we should not allow this 
>situation to be recreated with TCM when multiple different 
>parties are involved.
>
>If folks want to segment an end-end LSP for OAM diagnosis 
>purposes (this is NOT the same as defect detection/handling 
>OAM) then we should look to use more simple ways of 
>tapping-off an end-end OAM flow at intermediate points (which 
>should a rare event anyway) instead of burdening the whole 

JD: Agreed.  It seems that goal of the existing tandem connection stuff
was to provide an example of the term 'arbitrary complexity.

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 24 Dec 2008 21:56:37 +0100

Hi Neil,

Because MPLS-TP should be the result of cooperation between
ITU-T and IETF I have added the ITU-T list to this email.

You wrote:

> Here are a set of proposals that, IMO, will result in the simplest
> and best-case solution for MPLS-TP.   I've omitted any detailed 
> analysis/arguments.

To make MPLS-TP a proper profile backwards compatibility is
very important. I miss that in some of your proposals.

> I would like to hear opinions for/against each of these + any

OK, here is my .02

> 1	OOB CP/MP which re-uses GMPLS for the CP: This requires a reserved
> label (X say) from the 0-15 set which never appears in the traffic DP
> as a forwarding (or other semantic) label.

Why something new? Currently IP packets are uesed for that purpose.

> 2	A transparent MPLS-TPoverMPLS-TP client server relationship: If
> folks wish to keep the notion of sublayering (ie same party CP/MP 
>  the S-bit in MPLS, then we need a way to functionally isolate
> different sublayer LSP stacks.  The best (for many reasons) solution
> here is to use a further reserved label (Y say) from the 0-15 set
> which can only appear in the DP as part of the (server owned/applied)
> client/server adaptation and has the globally well known semantic of
> "label Y indicates a DP/CP/MP functional separator between the LSP

Are you trying to create ME levels in an MEG, where each level is
a sublayer? The CP/MP is related to the whole MEG.

> 3	OAM indicate: The DP OAM used for defect detection/handling should
> be as simple/sparse as possible and look (and be processed) as close
> as possible to normal DP traffic units......the use of an additional
> DP label header specifically for an OAM alert function should
> therefore be avoided if possible.  This type of OAM should be
> inserted/extracted at LSP trail termination points.  There is
> currently no OAM indicate field in the MPLS header.  However, since
> MPLS-TP will be a co-ps mode technology there is no requirement for a
> TTL field in the traffic unit header. Indeed, the GMPLS CP (or the
> MP) will be able verify there are no loops prior to activating a
> MPLS-TP LSP (just like GMPLS does for the co mode technologies it
> controls today).  Given that the TTL field represent 25% of the
> MPLS-TP header it is important to be able to re-use this field 

I think you are not allowed to touch the existing MPLS label at all
(see the discussion around the "re-use" of the EXP bits).
Why not use the *label Y* you mention in point 2 above, this will
exist at each sublayer anyway as you propose.

> 4	PWs and the CW/AC relationships: PWs were a product of how MPLS was
> originally specified...but those causal drivers must be removed in
> MPLS-TP.  Further, it is important to understand that we should not
> create an unnecessary co-ps mode layer network above MPLS-TP....this
> rather defeats the whole purpose of MPLS-TP.  So if PWs are retained
> in MPLS-TP they must revert to a form of adaptation and not become a
> network entity (like an MPLS-TP LSP is). If one analyses the CW one
> finds little of real value worth retaining in an adaptation role.
> The AC seems to hold more potential value however.....though I would
> suggest more thought is given to distinguishing functional uses that
> more correctly belong in the OOB CP/MP (ie and thus should use label
> X as per item 1 above) from those that more correctly belong in the
> traffic DP.
> 
> would argue this should be via a normal MPLS-TP header field...just
> like the case for the OAM noted in 3 above.  And if the TTL field is 

There is no MPLS-TP specific header field because it is the
MPLS header field. The option that remains is again use the
*label Y* again that you propose in point 2 above.

> interworking): When we are dealing with a non-top-of-stack layer
> network (and both MPLS and MPLS-TP are like this, but so is
> Ethernet...IP is NOT however, as it is designed to be able to fulfil
> a top-of-stack role) then there is no need whatsoever to try and

What should be done if the two peers are MPLS-TP or MPLS-TP and MPLS?
Go up to the client layer and hand over the client signal?

> 6	TCM OAM sublayers: MPLS-TP should not use nested TCM OAM sublayers.
> Just like the point wrt S bit noted above, TCM implies sublayers, and
> this in turn implies a common CP/MP across those sublayers....and
> since we have to address this issue as noted above in 2 for
> MPLS-TPoverMPLS-TP we should not allow this situation to be recreated
> with TCM when multiple different parties are involved.
> 
> If folks want to segment an end-end LSP for OAM diagnosis purposes
> (this is NOT the same as defect detection/handling OAM) then we
> should look to use more simple ways of tapping-off an end-end OAM
> flow at intermediate points (which should a rare event anyway)
> instead of burdening the whole network with a complex set of
> sublayering configuration costs/problems.

See my response above to point 2, using MEL for sublayering will
provide the functionality required by TCM.

I propose to keep TCM for SDH and OTN and use another term in
MPLS(-TP) to avoid unwanted expectations.
(Even though ANSI T1.105.05 is very informative, both its content
and the contributors list)

Happy Holidays, Huub.

-- 
================================================================
It's better to light a candle -- than to complain about darkness
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Wed, 24 Dec 2008 22:23:09 -0000

Thanks Huub....my last mail before the Xmas break (well, that's what
I've told my wife ;))...... 

Huub wrote 24 December 2008 20:57
> ITU-T and IETF I have added the ITU-T list to this email.
NH=> OK thanks.  The more folks look/think about this the better.
> very important. I miss that in some of your proposals.
NH=> We have to strike a balance here and not simply take things forward
if there is a better way.  I have retained:
-	the basic traffic unit and functional fields....which are a
small/limited resource to say the least, and suggested a re-spin of the
TTL field which is redundant in a co mode layer network that can be used
more wisely in MPLS-TP IMO.
- 	The S bit sublayering....my personal view is this is not
required, but if folks want to keep it (for whatever reason) we need to
introduce a new way of dealing with MPLS-TPoverMPLS-TP sublayers that
belong to *different* MPLS-TP networks (ie keep the DP (eg S bit), CP,
MP distinct in each sublayer stack).  The reserved label idea is simply
more elegant/efficient than using another technology (eg Ethernet was in
Stewart's old draft) to force this logical DP/CP/MP separation.
-	re-use of GMPLS CP
...so not a lot really changes....just trying to avoid problems like
creating an unncessary/new co-ps PW layer above MPLS-TP.

> Why something new? Currently IP packets are uesed for that purpose.
NH=> OK, you understand func arch stuff and will understand it when I
say that the CI of a layer network must be consistent right?  This means
that the DP should always present a consistent traffic unit.  This was
not the case in MPLS, an interface here could present raw IP (if
CP/MP...traffic IP DP had null encaps in MPLS traffic unit, ie quite a
different behaviour) or an MPLS traffic unit....and that is just not
right.  Taking the CP/MP OOB, as is forced when dealing with the co-cs
mode (as per GMPLS), would seem a very logical and worthwhile
improvement that should be adopted in MPLS-TP.  There is also an
immediate security benefit as well as cleaning-up the CI aspect of the
DP.
 
> Are you trying to create ME levels in an MEG, where each 
> level is a sublayer? The CP/MP is related to the whole MEG.]
NH=> 'No' and 'I know' respectively.  But this is not the problem I am
addressing.  However, you are right to raise this as I am not sure all
folks really grasp just how careful one has to be with sublayering, ie
sublayering *implies* a common CP/MP to all sublayer entities.....the
S-bit in MPLS as-is is sublayering, and nested TCM levels are just a
different form of sublayering.  We in BT really don't like the notion of
TCM for many reasons, but irrespective of our views on TCM we still have
to address the S bit issue of sublaying in MPLS-TP.

Now, if we decided to get rid of sublayering altogether in MPLS-TP (ie S
bit behaviour just goes) we would NOT require a reserved label...that
is, all LSPs represent independent layer networks in DP/CP/MP.  However,
if some folks want to keep the sublayering concept and the S bit (which
is what I am assuming whether I agree with it or not) then we must find
a way to deal with it.  Put simply, in a client/server relationship
between 2 *different* MPLS networks (each of which wants to have its own
independent sublayering/S-bit) we have to functionally isolate them in
DP/CP/MP.

It the old draft Stewart had on this (expired) we did this by inserting
another technology between the 2 different MPLS networks...Ethernet was
chosen for this purpose, but in practice it could have been any other
network technoology.  This is rather a sledgehammer approach.

I gave a lot of thought to this at the time and could see a more
elegant/efficient way of using a reserved label for this job.  

And to put a little more flesh on this is for anyone who is still having
problems understanding what I am saying here, consider this:
-	S=0....no problem, client always MPLS *but* it is the *same*
MPLS network sublayer stack.  We cannot have an LSP for a *different*
MPLS network after a S=1 case.
-	S=1 *before* we employ the reserved label => IP or 'else'/PW, ie
it *cannot* be MPLS
-	S=1 *after* we emply the reserved label => IP, MPLS LSP of a
*different* MPLS network, or 'else'/PW (the 'else' here does not need
all the original PW CW paraphenalia, eg CW...but folks can keep them if
it feels more comfortable to them).

> additional 
> > MPLS-TP header it is important to be able to re-use this 
> field wisely.  
> > An OAM indicate function only requires 1 bit here.
> 
> I think you are not allowed to touch the existing MPLS label 
> at all (see the discussion around the "re-use" of the EXP bits).
NH=> I assume you mean *MPLS header fields* in total and not (as
written) just the *MPLS (20 bit) label field*?  If that is the case we
will waste 25% of the header on the TTL in MPLS-TP.  One can do this
(one can do a lot of crazy things)...whether this is smart or not is a
different question (and you can no doubt guess how smart I think would
be).

> Why not use the *label Y* you mention in point 2 above, this 
> will exist at each sublayer anyway as you propose.
NH=> Well, we can use a special DP 'OAM alert label' (as per label 14 in
case of Y.1711)....not a great idea but next best thing I guess if we
are happy to waste the redundant TTL field.  I personally don't see this
the same as the label Y case noted above....as the label Y case is
specific to delimiting *different* sets of LSP sublayers, but the OAM
alert label can apply to any LSP, ie at any level within a set of nested
LSP sublayers.

> retained 
> > more correctly belong in the OOB CP/MP (ie and thus should 
> use label X 
> > as per item 1 above) from those that more correctly belong in the 
> > traffic DP.
> > 
NH=> And yet again I come back to same point I made above, ie label Y is
specific to delimiting *dfferent* sets of nested LSP sublayers, but if
folks want the AC to apply to any LSP *within* a sublayer this is a
different identifier problem.  And this is also why I think it rather
important to decouple the AC from the CW (the latter is specific to the
old PW mindset, the AC can apply to any LSP).

> > Ethernet...IP is NOT however, as it is designed to be able 
> to fulfil a 
NH=> Well, If you carry IP over SDH VC4 and PDH 140M server hops what
amount of interworking do you see between the SDH VC4 and PDH 140M
paths?....answer is of course 'none', and we just pass the IP client
transparently.  Never forget that PWs are an artifical 'thing' created
for MPLS as-is (to solve problems in MPLS as-is)...they are not a
'normal' component of a transport network.  So I would be very wary of
making PWs the common interworking glue...esp the CW!

The one thing we must not do (but its happening right now sadly in PWE3
for MPLS) is allow PWs to create yet another co-ps mode layer network
above MPLS-TP....that would be almost unforgiveable IMO.

Having said that, if folks really want to have the AC 'common' between
MPLS and MPLS-TP they could pass this (as well as the client per se)
end-end.  But just be careful is my advice.

Aside=> You come from a transport background Huub and you will recognise
the importance of GFP here to existing PDH/SDH/OTN transport networks.
You might want to have a little think about interworking a new transport
network with existing ones that already use GFP.....I'll say no more
than that here.

> > (this is NOT the same as defect detection/handling OAM) 
> then we should 
> > look to use more simple ways of tapping-off an end-end OAM flow at 
> > intermediate points (which should a rare event anyway) instead of 
> > burdening the whole network with a complex set of sublayering 
> > configuration costs/problems.
> 
> See my response above to point 2, using MEL for sublayering 
> will provide the functionality required by TCM.
NH=> TCM is an OAM sledgehammer.  If we want a discussion on TCM/OAM per
se lets do this on separate thread as I, Andy and Alan have looked at
this areas in great depth over many years...OAM is my professional
technical area of expertise as I'm sure you know.  It will for sure
create 'arbitrary complexity' as John Drake wryly remarked that we can
ill afford ie "JD: It seems that goal of the existing tandem connection
stuff was to provide an example of the term 'arbitrary complexity.".
> (Even though ANSI T1.105.05 is very informative, both its 
> content and the contributors list)
> 
> Happy Holidays, Huub.
NH=> You too Huub...regards, Neil.....now on hols for a few days.....
> It's better to light a candle -- than to complain about 
> darkness _______________________________________________
> mpls-tp mailing list
> [email-masked]