Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS Transport Profile Data Plane Architecture) to Proposed Standard

From: John E Drake <[email-masked]>
Date: Tue, 1 Jun 2010 05:44:31 -0700

There is only one s bit per label stack.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, May 31, 2010 11:37 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; IETF-Announce; [email-masked]
> Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS
> Transport Profile Data Plane Architecture) to Proposed Standard
> 
> 
> hi,all editors
> About section 3.2 , there is the following paragraph:
> "   If the section is an LSP, this information MAY be implied by
>   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
>   of the S bit.  Additional labels MAY also be used if necessary to
>   distinguish different payload types"
> IMO, if the client traffic of section layer is MPLS-labeled, the S bit of
> section label must be set 1.
> if my understanding is true, maybe violate MPLS-TP framework?
> in my memory,only S bit of the lowest label should be set 1 in MPLS Label
> stack,
> there can be only one S-bit set in a label stack.
> 
> maybe i  misunderstand the sentence? I hope it can clarify this paragragh
> clearly.
> 
> best regards
> liu
> 
> 
> 
> 
> 
> 
> 
> 
> The IESG <[email-masked]>
> 发件人:  [email-masked]
> 
> 2010-06-01 06:27
> 请答复 给
> [email-masked]
> 
> 收件人
> IETF-Announce <[email-masked]>
> 抄送
> [email-masked], [email-masked]
> 主题
> [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS Transport
> Profile Data Plane Architecture) to Proposed Standard
> 
> 
> 
> 
> 
> 
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> 
> - 'MPLS Transport Profile Data Plane Architecture '
>   <draft-ietf-mpls-tp-data-plane-03.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-06-14. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-data-plane-03.txt
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19
> 671&rfc_flag=0
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> 
> 
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is
> solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this communication to
> others.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the originator of
> the message. Any views expressed in this message are those of the
> individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.

---

From: [email-masked]
Date: Wed, 2 Jun 2010 08:54:00 +0800

John
thank you for replying , but I think this descirbles is not completely 
clear.
I hope the editor can further clarify the paragragh.
thank you.

best regards
liu

John E Drake <[email-masked]> 
发件人:  [email-masked]
2010-06-01 20:44

收件人
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, IETF-Announce <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
Re: [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS Transport 
Profile Data Plane Architecture) to Proposed Standard

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 02 Jun 2010 13:10:00 +0100

Liu

As John says, there is only one s bit in a label stack.

> > section label must be set 1.

Please look at Fig 2 of draft-ietf-mpls-tp-framework.

The section would add an additional label at the bottom of the stacks
shown in the figure.

A payload indicator label would be the label below the dashed line, and
the LSP and section labels would be below that in the figure.

However only one S bit is set in the stack.

> > maybe i misunderstand the sentence? I hope it can clarify this paragragh
I do not think that any further clarification is needed in the dataplane
text.

- Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Loa Andersson <[email-masked]>
Date: Wed, 02 Jun 2010 14:36:26 +0200

All,

a label stack consists of one or more label stack entries, there is one
s bit in each of the label stack entries, only one of the s bits are set
(indicating that this is the bottom of the label stack)

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: John E Drake <[email-masked]>
Date: Wed, 2 Jun 2010 05:55:55 -0700

Loa,

I'm sorry, that's right.  There is only one label stack entry per stack in which the 'S' bit is set.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Loa Andersson
> Sent: Wednesday, June 02, 2010 5:36 AM
> To: [email-masked]
> Cc: [email-masked]; IETF-Announce; [email-masked]
> Subject: Re: [mpls-tp] [mpls] Last Call: draft-ietf-mpls-tp-data-plane
> (MPLS Transport Profile Data Plane Architecture) to Proposed Standard
> 
> All,
> 
> >> ZTE  Information  Security  Notice:  The  information  contained  in
> this  mail  is  solely  property  of  the  sender's  organization.  This
> mail  communication  is  confidential.  Recipients  named  above  are
> obligated  to  maintain  secrecy  and  are  not  permitted  to  disclose
> the  contents  of  this  communication  to  others.
> >> This  email  and  any  files  transmitted  with  it  are  confidential
> and  intended  solely  for  the  use  of  the  individual  or  entity  to
> whom  they  are  addressed.  If  you  have  received  this  email  in
> error  please  notify  the  originator  of  the  message.  Any  views
> expressed  in  this  message  are  those  of  the  individual  sender.
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Wed, 2 Jun 2010 14:33:27 +0100

Loa/Stewart,

Loa wrote 02 June 2010 13:36:

> a label stack consists of one or more label stack entries, 
> there is one s bit in each of the label stack entries, only 
> one of the s bits are set (indicating that this is the bottom 
> of the label stack)
> 
> /Loa

I think most folks understand this is traditional MPLS sublayer behaviour.  However, traditional MPLS sublayering is not a behaviour that a transport network should provide - in a transport network we require a transparent client/server behaviour......in other words this is layering and not sublayering.

A key corollary of the above observation is that we have *sharing of the same* DP/CP/MP functional component instances in sublayering and *independent existence/operation of different* DP/CP/MP functional component instances in layering.  And specifically wrt to layer network addressing, this means:
-	sublayering => one set of common access points in the same routing instance in a single MPLS-TP layer network 
-	layering => disjoint sets of independent access points (even if they use identical addressing formats) in different/independent routing instances in different/independent MPLS-TP layer networks.

Now, it should be obvious even to a tyro IMO that traditional MPLS sublayering is not required in a MPLS-TP co-ps mode transport network....and perhaps even more obviously (?) a transport network should not spawn an adjunct co-ps mode PW layer network running over it.

However, we still seem very keen on making these mistakes in MPLS-TP.  In which case I would suggest we stop calling MPLS-TP a 'transport network' because it isn't...it's now simply yet another spin of MPLS as-is.  Further, if we are going to mix layering and sublayering we still need to have a good architectural way of being able to distinguish them and understand the addressing structures in each case within a set of nested LSPs. 

I still do not understand what this means and have asked for help in clarifying this a few times already.

Note carefully that, from OAM considerations, in a co-ps mode network whose forwarding is based on label-swapping the CV function should be run on all connections/LSPs and this must contain the absolute SA of the connection/LSP (not some locally source generated string of bits).

Further, you should note that there is an additional wrinkle here wrt to the format of the addressing (ie Global_ID-based or ICC-based) which Munkund Mani initially raised (Fri 28/05/2010 07:37) and I expanded on because this is also impacted by whether one is considering layering or sublayering....**noting this also obviously impacts the nature of SA inserted in CV OAM messages as noted above**....I extract the relevant mail extract below on this point from Munkund's mail of today re-asking for this point to be answered by the authors:

====
Hi

Could the draft authors please clarify the questions mentioned below??
 
With Regards
Mukund

On Fri, May 28, 2010 at 12:29 PM, <[email-masked]> wrote:

Good question....I'd like to add a sub-question to this:
 
Case A:  Sublayering implies nested LSPs that belong to the *same* layer network, ie they are in a common routing instance and bounded by a common set of access points.
 
Case B:  Layering implies nested LSPs that belong to *different* layer networks, ie they are in different routing instances and bounded by different sets of access points (in each disjoint layer network).
 
Note - Case A is traditional MPLS behaviour whereas case B is what *should* be done in a proper transport network, ie a transport network should not have traditional MPLS LSP sublayering but be based on client/server relationships between nested LSPs.
 
So......
 
1    What does an LSP access point address look like in each of the 2 cases of sublayering and layering noted above?
 
2    In case A then all of the sublayer access points must belong to same addressing format  (ie either all Global_ID-based or all ICC-based but they cannot be mixed - but we still have the issue of differentiating layering from sublayering as noted in 1 above), whereas in case B they do not have to belong to the same addressing format (ie one (server or client) LSP may use the Global_ID format whereas another (client or server) LSP may use the ICC format).  So can the authors please comment as to whether what I have just described is allowed?
 
===

regards, Neil

> >> > From: [email-masked] [mailto:[email-masked]] On 
> >> > Behalf Of [email-masked]
> >> > " If the section is an LSP, this information MAY be 
> implied by the 
> >> > LSP label or, if the LSP payload is MPLS-labeled, by the 
> setting of 
> >> > the S bit. Additional labels MAY also be used if necessary to 
> >> > IMO, if the client traffic of section layer is 
> MPLS-labeled, the S
> >> bit of
> > A payload indicator label would be the label below the dashed line, 
> > and the LSP and section labels would be below that in the figure.
> >
> >> > in my memory,only S bit of the lowest label should be 
> set 1 in MPLS
> >> Label
> >> > stack,
> >> > maybe i misunderstand the sentence? I hope it can clarify this 
> >> > paragragh clearly.
> > I do not think that any further clarification is needed in the 
> > dataplane text.
> >
> > - Stewart
> >
> >
> >> >
> >> > best regards
> >> > liu
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > The IESG plans to make a decision in the next few weeks, and 
> >> > solicits final comments on this action. Please send substantive 
> >> > comments to the [email-masked] mailing lists by 2010-06-14. 
> >> > Exceptionally, comments may be sent to [email-masked] instead. In 
> >> > either case, please retain the beginning of the Subject 
> line to allow automated sorting.
> >> >
> >> > ZTE Information Security Notice: The information 
> contained in this
> >> mail is
> >> > solely property of the sender's organization. This mail 
> >> > communication is confidential. Recipients named above 
> are obligated 
> >> > to maintain
> >> secrecy and
> >> > If you have received this email in error please notify the 
> >> > originator of the message. Any views expressed in this 
> message are 
> >> > those of the individual sender.
> >> ZTE  Information  Security  Notice:  The  information  
> contained  in  this  mail  is  solely  property  of  the  
> sender's  organization.  This  mail  communication  is  
> confidential.  Recipients  named  above  are  obligated  to  
> maintain  secrecy  and  are  not  permitted  to  disclose  
> >> This  email  and  any  files  transmitted  with  it  are  
> confidential  and  intended  solely  for  the  use  of  the  
> individual  or  entity  to  whom  they  are  addressed.  If  
> you  have  received  this  email  in  error  please  notify  
> the  originator  of  the  message.  Any  views  expressed  in 
>  this  message  are  those  of  the  individual  sender.
>                                               +46 767 72 92 
> 13 _______________________________________________
> mpls mailing list
> [email-masked]

---

From: John E Drake <[email-masked]>
Date: Wed, 2 Jun 2010 08:40:31 -0700

Neil,

The short answer is that the MPLS label stack tells you nothing wrt sub-layering or layering.  I.e., all sub-layering and layering is done using the same MPLS label stack.

Thanks,

John

> Of [email-masked]
> Sent: Wednesday, June 02, 2010 6:33 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> I think most folks understand this is traditional MPLS sublayer behaviour.
> However, traditional MPLS sublayering is not a behaviour that a transport
> network should provide - in a transport network we require a transparent
> client/server behaviour......in other words this is layering and not
> sublayering.
> 
> A key corollary of the above observation is that we have *sharing of the
> same* DP/CP/MP functional component instances in sublayering and
> *independent existence/operation of different* DP/CP/MP functional
> component instances in layering.  And specifically wrt to layer network
> addressing, this means:
> -	sublayering => one set of common access points in the same routing
> instance in a single MPLS-TP layer network
> -	layering => disjoint sets of independent access points (even if they
> use identical addressing formats) in different/independent routing
> instances in different/independent MPLS-TP layer networks.
> 
> Now, it should be obvious even to a tyro IMO that traditional MPLS
> sublayering is not required in a MPLS-TP co-ps mode transport
> network....and perhaps even more obviously (?) a transport network should
> not spawn an adjunct co-ps mode PW layer network running over it.
> 
> 
> However, we still seem very keen on making these mistakes in MPLS-TP.  In
> which case I would suggest we stop calling MPLS-TP a 'transport network'
> because it isn't...it's now simply yet another spin of MPLS as-is.
> Further, if we are going to mix layering and sublayering we still need to
> have a good architectural way of being able to distinguish them and
> understand the addressing structures in each case within a set of nested
> LSPs.
> 
> Note carefully that, from OAM considerations, in a co-ps mode network
> whose forwarding is based on label-swapping the CV function should be run
> on all connections/LSPs and this must contain the absolute SA of the
> connection/LSP (not some locally source generated string of bits).
> 
> Further, you should note that there is an additional wrinkle here wrt to
> the format of the addressing (ie Global_ID-based or ICC-based) which
> Munkund Mani initially raised (Fri 28/05/2010 07:37) and I expanded on
> because this is also impacted by whether one is considering layering or
> sublayering....**noting this also obviously impacts the nature of SA
> inserted in CV OAM messages as noted above**....I extract the relevant
> mail extract below on this point from Munkund's mail of today re-asking
> for this point to be answered by the authors:
> 
> ====
> Hi
> 
> Case A:  Sublayering implies nested LSPs that belong to the *same* layer
> network, ie they are in a common routing instance and bounded by a common
> set of access points.
> 
> Case B:  Layering implies nested LSPs that belong to *different* layer
> networks, ie they are in different routing instances and bounded by
> different sets of access points (in each disjoint layer network).
> 
> Note - Case A is traditional MPLS behaviour whereas case B is what
> *should* be done in a proper transport network, ie a transport network
> should not have traditional MPLS LSP sublayering but be based on
> client/server relationships between nested LSPs.
> 
> So......
> 
> 1    What does an LSP access point address look like in each of the 2
> cases of sublayering and layering noted above?
> 
> 2    In case A then all of the sublayer access points must belong to same
> addressing format  (ie either all Global_ID-based or all ICC-based but
> they cannot be mixed - but we still have the issue of differentiating
> layering from sublayering as noted in 1 above), whereas in case B they do
> not have to belong to the same addressing format (ie one (server or
> client) LSP may use the Global_ID format whereas another (client or
> server) LSP may use the ICC format).  So can the authors please comment as
> to whether what I have just described is allowed?
> 
> ===
> 
> regards, Neil
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 2 Jun 2010 12:00:20 -0400

Neil,

I believe I understand your concerns.

If existing implementations had observed a simple requirement - towit, thou
shalt not _ever_ peak beyond the top label (unless and until told to do so -
for example, if the label is supposed to be popped) - then there could be as
many set S-bits as you want to define corresponding (sub)layers for.

In spite of the fact that only a single S-bit is supposed to be set for a label
stack - according to specification - if people also observed the specified
behavior that is supposed to protect the opacity of the remaining labels in
the label stack, then the fact that each remaining able might also have its
S-bit set would be something nobody would be aware of.

Unfortunately, as so often happens, the bits were hardly dry on the protocol
specification before implementors had already departed from the letter of
the specification.  Specifically, people were almost immediately looking for
"the one (and presumed only) set S-bit" so that they could use the header
(presumed - at least initially - to be an IPv4 header) assumed to follow it.

Hence, what we would have - if we allowed more than one S-bit to be set
- is mutually incompatible "cheats" against the protocol specification.

Clearly if one implementation sets arbitrarily many S-bits while others look
for the one and only set S-bit in order to establish a hash value to be used
in distributing traffic across N (N>1) equal cost paths, things don't work as
people expect them to.

As a result, the only way to truly get the separate layering effect you're after
is to insert a break in the layer (by - for example - encapsulating an LSP at
one layer in Ethernet and then putting it in a PW).  The issue is then whether
or not this additional overhead is really what every service provider wants.

--
Eric
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Wednesday, June 02, 2010 3:33 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS    Transport Profile Data Plane Architecture) to Proposed Standard

Loa/Stewart,

====
Hi

With Regards
Mukund

So......

===

regards, Neil

---

From: <[email-masked]>
Date: Wed, 2 Jun 2010 17:46:07 +0100

Thank you Eric.... this is a useful response.  Please see below:

>Eric Gray wrote 02 June 2010 17:00
> 
> Neil,
> 

NH=> I hope you/I are not in a minority.  These points are very important if we are to make a success of MPLS-TP as a *transport network*.  If not, then we should drop this (transport network) claim and just say it's another spin of MPLS.  There is nothing wrong with this, as taking the CP/MP OOB, stopping merging and stopping (some) transparency violations via ECMP-like DPI snooping is excellent progress IMO.....it's just we fall short of what c/should have been achieved.

> 
> If existing implementations had observed a simple requirement 
> - towit, thou shalt not _ever_ peak beyond the top label 
> (unless and until told to do so - for example, if the label 
> is supposed to be popped) - then there could be as many set 
> S-bits as you want to define corresponding (sub)layers for.
> 
> In spite of the fact that only a single S-bit is supposed to 
> be set for a label stack - according to specification - if 
> people also observed the specified behavior that is supposed 
> to protect the opacity of the remaining labels in the label 
> stack, then the fact that each remaining able might also have 
> its S-bit set would be something nobody would be aware of.
> 
> Unfortunately, as so often happens, the bits were hardly dry 
> on the protocol specification before implementors had already 
> departed from the letter of the specification.  Specifically, 
> people were almost immediately looking for "the one (and 
> presumed only) set S-bit" so that they could use the header 
> Clearly if one implementation sets arbitrarily many S-bits 
> while others look for the one and only set S-bit in order to 
> establish a hash value to be used in distributing traffic 
> across N (N>1) equal cost paths, things don't work as people 
> expect them to.
> 
> As a result, the only way to truly get the separate layering 
> effect you're after is to insert a break in the layer (by - 
> for example - encapsulating an LSP at one layer in Ethernet 
> and then putting it in a PW).  The issue is then whether or 
> not this additional overhead is really what every service 
> provider wants.

NH=> Understand.  But the whole point of a transport network is to create client topology....whatever that client is, including another MPLS-TP layer network.  Indeed, if we are not careful (and I think it's possibly too late already) we will see folks pushing for E-NNIs in non-TOS layer networks and also trying to peer interwork *different* non-TOS technologies because we do not have a good client/server solution.  It is trivially easy to prove that a non-TOS layer network (and most technologies are non-TOS) does not need E-NNI peer interworking...it just creates unnecessary technical/commercial/security problems that can be avoided.

I have no idea why many other operators seem silent on this matter Eric.....but if they follow the UK regulatory model (as many might)  then it is not really viable for OpenReach to 'peer' with the SP customers they serve, they have to provide a transparent client/server service and treat all customers (including other lines of business in BT) equally.  So they need a proper transport network technology that respects client/server independence and provides a transparent service to their customers.  

Aside=> I suggested to Stewart a long time ago that we should consider using a special/reserved label to create a functional demarc between nested LSPs that belong to different MPLS-TP layer networks...this is far more elegant and efficient than the sledgehammer solution of inserting a degenerate (1-hop) Ethernet + PW pair of layer networks.  My view is still that a transport network has no need for sublayering (and for sure no MS PW layer network), but if we ignore this and are happy not to claim a transport role here then I think we must still sort out the sublayering/layering issue and I would still recommend using a special label for this purpose.  And don't forget the other point I/Mukund raised on how different access point addressing formats can get handled in a mixed sublayer/layered stack of nested LSPs....I still don't understand this aspect.

regards, Neil
> From: [email-masked] [[email-masked]] On 
> Behalf Of [email-masked] [[email-masked]]
> Subject: Re: [mpls-tp] [mpls] Last Call: 
> draft-ietf-mpls-tp-data-plane (MPLS    Transport Profile Data 
> Plane Architecture) to Proposed Standard
> 
> Loa/Stewart,
> 
> > a label stack consists of one or more label stack entries, there is 
> > one s bit in each of the label stack entries, only one of 
> the s bits 
> > are set (indicating that this is the bottom of the label stack)
> >
> > /Loa
> 
> I think most folks understand this is traditional MPLS 
> sublayer behaviour.  However, traditional MPLS sublayering is 
> not a behaviour that a transport network should provide - in 
> a transport network we require a transparent client/server 
> behaviour......in other words this is layering and not sublayering.
> 
> A key corollary of the above observation is that we have 
> *sharing of the same* DP/CP/MP functional component instances 
> in sublayering and *independent existence/operation of 
> different* DP/CP/MP functional component instances in 
> layering.  And specifically wrt to layer network addressing, 
> this means:
> -       sublayering => one set of common access points in the 
> same routing instance in a single MPLS-TP layer network
> -       layering => disjoint sets of independent access 
> points (even if they use identical addressing formats) in 
> different/independent routing instances in 
> different/independent MPLS-TP layer networks.
> 
> Now, it should be obvious even to a tyro IMO that traditional 
> MPLS sublayering is not required in a MPLS-TP co-ps mode 
> transport network....and perhaps even more obviously (?) a 
> transport network should not spawn an adjunct co-ps mode PW 
> layer network running over it.
> 
> 
> However, we still seem very keen on making these mistakes in 
> MPLS-TP.  In which case I would suggest we stop calling 
> MPLS-TP a 'transport network' because it isn't...it's now 
> simply yet another spin of MPLS as-is.  Further, if we are 
> going to mix layering and sublayering we still need to have a 
> good architectural way of being able to distinguish them and 
> understand the addressing structures in each case within a 
> set of nested LSPs.
> 
> I still do not understand what this means and have asked for 
> help in clarifying this a few times already.
> 
> Note carefully that, from OAM considerations, in a co-ps mode 
> network whose forwarding is based on label-swapping the CV 
> function should be run on all connections/LSPs and this must 
> contain the absolute SA of the connection/LSP (not some 
> locally source generated string of bits).
> 
> Further, you should note that there is an additional wrinkle 
> here wrt to the format of the addressing (ie Global_ID-based 
> or ICC-based) which Munkund Mani initially raised (Fri 
> 28/05/2010 07:37) and I expanded on because this is also 
> impacted by whether one is considering layering or 
> sublayering....**noting this also obviously impacts the 
> nature of SA inserted in CV OAM messages as noted 
> above**....I extract the relevant mail extract below on this 
> point from Munkund's mail of today re-asking for this point 
> to be answered by the authors:
> 
> ====
> Hi
> 
> Case A:  Sublayering implies nested LSPs that belong to the 
> *same* layer network, ie they are in a common routing 
> instance and bounded by a common set of access points.
> 
> Case B:  Layering implies nested LSPs that belong to 
> *different* layer networks, ie they are in different routing 
> instances and bounded by different sets of access points (in 
> each disjoint layer network).
> 
> Note - Case A is traditional MPLS behaviour whereas case B is 
> what *should* be done in a proper transport network, ie a 
> transport network should not have traditional MPLS LSP 
> sublayering but be based on client/server relationships 
> between nested LSPs.
> 
> So......
> 
> 1    What does an LSP access point address look like in each 
> of the 2 cases of sublayering and layering noted above?
> 
> 2    In case A then all of the sublayer access points must 
> belong to same addressing format  (ie either all 
> Global_ID-based or all ICC-based but they cannot be mixed - 
> but we still have the issue of differentiating layering from 
> sublayering as noted in 1 above), whereas in case B they do 
> not have to belong to the same addressing format (ie one 
> (server or client) LSP may use the Global_ID format whereas 
> another (client or server) LSP may use the ICC format).  So 
> can the authors please comment as to whether what I have just 
> described is allowed?
> 
> ===
> 
> regards, Neil
> 
> confidential and
> > >> intended
> > contained  in  this  mail  is  solely  property  of  the sender's  
> > organization.  This  mail  communication  is confidential.  
> Recipients  
> > named  above  are  obligated  to maintain  secrecy  and  are  not  
> > permitted  to  disclose the  contents  of  this  communication  to  
> > others.
> individual  
> > or  entity  to  whom  they  are  addressed.  If you  have  
> received  
> > this  email  in  error  please  notify the  originator  of  the  
> > message.  Any  views  expressed  in  this  message  are  those  of  
> > the  individual  sender.

---

From: [email-masked]
Date: Thu, 3 Jun 2010 11:31:01 +0800

I agree  loa's description.if so ,it is more clear to everyone.

thank you
liu

John E Drake <[email-masked]> 
发件人:  [email-masked]
2010-06-02 20:55

收件人
Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, IETF-Announce <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] [mpls] Last Call: draft-ietf-mpls-tp-data-plane (MPLS 
Transport Profile Data Plane Architecture) to Proposed Standard

Loa,

I'm sorry, that's right.  There is only one label stack entry per stack in 
which the 'S' bit is set.

Thanks,

John

> >> > From: [email-masked] [mailto:[email-masked]] On 
Behalf
> Of
and
> paragragh
dataplane
> >> > The IESG plans to make a decision in the next few weeks, and 
solicits
> >> > solely property of the sender's organization. This mail 
communication
> is
originator
> of

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 07 Jun 2010 17:12:05 -0400

Neil,

Its been an MPLS-TP requirement from day one that we not change the
MPLS forwarding in a way that is not backward compatible.

A change to the semantics of the S bit would not be backward
compatible.  Therefore you are just wasting keystrokes venting about
layering and sublayering again with no chance of changing anything.

For example, an LSP may carry an IP packet that is forwarded through a
node or a PW that terminates at the same node.  Since a PW label with
a 4 or a 6 in the first nibble (part of the label number) can be
valid, there would be no way to distinguish the bottom of stack in
this case.  If that LSP must have the S bit set in MPLS-TP to be
considered a "proper layer", then in this case the LSP cannot be an
MPLS-TP LSP, it must be a MPLS LSP.

If there was no sublayering in MPLS-TP as per your preference and
every S bit was set, then the S-bit would be meaningless.  You
complain about the use of a TTL and then you want to render the S bit
meaningless by setting it to one all the time.  There is no point to
gratuitous non-backwards compatible changes to the data plane.

It would be sufficient to add to the draft that the the S bit has no
meaning with regard to layering and will continue to be used as the
bottom of label stack indication as it has been used (for over a
decade).  This would certainly remove any ambiguity.

Unless I'm mistaken, last call already ended.

Curtis

In message <[email-masked]>
[email-masked] writes:

regards, Neil