Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]

From: <[email-masked]>
Date: Thu, 27 Aug 2009 17:31:16 +0100

Thanks Lou, 

> Neil,
> 	There's a critical qualifier in your statement:
> > (with a desire to preserve the original S bit concept)
> 
> What do you see as the 'S bit concept'?

NH=> MPLS is quite unique in employing a digital wrapper concept, ie
add/remove headers at will.  One cannot create topology on the fly by
this (which harps back to the flawed single CP IP-to-Optics idea) but
one can create arbitrary depths of sublayering within what is still
essentially a single layer network (there are some subtleties here wrt
to the relationship with IP, but let me park those).

Doing this does create both benefits and drawbacks.  For example, labels
can have quite different semantics depending on which protocol issued
them, so if there is misconnectivity (for whatever causal reason) then a
receiving node may make incorrect forwarding/handling decisions.
(Aside=> In ITU functional architecture speak this would be considered
as not having consistent characteristic information in the layer
network).  One can, however, mitigate the impact of such defects if one
can ensure that there is always consistent OAM associated with each
LSP...because now, even under misconnectivity and the potential for a
reciever to take the wrong action on the header/label, the OAM would
still be processed the same and thus the defect condition detected.  If
the OAM used on each LSP was also different, then you have a compounded
problem of lack of consistent characteristic information here too.

My personal view, when considering a co-ps mode MPLS-TP transport
network role, is that the S bit concept is not required...at least
against a concept of arbitrary stacking.  IMO each LSP should represent
a single autonomous layer network in its own right.  However, I am also
conscious that the S bit is a 'big thing' in MPLS history and so many
folks would want to keep it even in a transport role.  (Aside=> It's not
just the S bit that is largely redundant here, but in a properly
designed co-ps mode network one does not require a TTL field as the CP
(or MP) should be able to verify no lopps before allowing and LSP to be
established.  Soemthing I am sure you are very familiar with from
GMPLS/CCAMP work).

> 
> My bet is that the difference in what we each see as the 'S 
> bit concept'
> will come down to what I see as "common practice" vs. "what is allowed
> by spec".
> 
> WRT your proposal to provide the 'functional breakwater' via 
> a reserved
> label, I think this is a more significant forwarding function 
> change to
> MPLS than formally stating the use of multiple S bits.  The S bit is
> already used to denote layer boundaries (in 3031/3032 terms, between
> MPLS and the 'network layer')

NH=> I think there is far too much attaention paid to the old OSI
'network layer' view, and also the related L1/2/3 view.  The only
strictly accurate view of the 'network layer' is that it can take on 3
different modes, ie co-cs, co-ps and cl-ps, all are different, all are
important (none more important that the other).  But having worked in
CCAMPs and GMPLS for so long this ought to be quite obvious to you I
suspect.

BTW - I would really struggle to justify calling MPLS a 'network layer'
in the old OSI sense anyway.  Especially if one takes the (more
important) view that the reason IP is critical is that it can directly
support external message/fiole/stream applications...now that
observation is highly significant.  MPLS cannot do this of course...at
least as currently designed

 while a reserved label is 
> *never* used for
> this.  This discussion is almost an architectural aesthetics 
> question as
> I don't see any real difference in functional effect.

NH=> Even under misconnectivity and the risk of making wrong decisions?
But I tend to agree that I am trying to find a good/clean architectural
solution.

> In 
> particular, I
> don't see how the use of reserved label provides any greater
> misconnectivity mitigation when compared against the use of a  layer
> assigned (and pushed) label with the S bit set.  Perhaps you didn't
> presume that a such a label would be pushed (whihc is required per
> section 3.4.1) or am I missing something?

NH=> I'm simply making the observation that a normal fowarding label
will potentially have a far higher incidence of being 'in use' within a
MPLS network (at all levels in the stack) whereas a special label will
have a much more restricted use, ie just to nodes where the MPLSoverMPLS
client/server function is being used.  So it should follow that there is
less risk of making a misconnectvity error here.  It is also very clear
in its well-known global meaning should it turn-up somewhere where it
should not be due to a misconnectivity defect.

regards, Neil
> 
> Lou
> 
> On 8/27/2009 11:38 AM, [email-masked] wrote:
> > Thanks Lou for the helpful response.  You asked a question:
> > 
> > NH=> What I am essentially postulating here is that the
> >>> misconnectivity risk is larger with a normal fowarding 
> >> label (drawn from
> >>> the >15 value population) than with a special reserved 
> >> label (drawn from
> >>> the 0-15 set)....simply on the basis of how many nodes 
> >> would expect to
> >>> see (ie have issued) the relevant label in the 2 cases.
> >>>
> >> So how do you prefer/propose to address this point?
> >>
> >> Thanks,
> >> Lou
> > 
> > When I first looked at this problem (a long time ago now) it seemed
> > rather important that the solution should:
> > (i) be efficient/simple, ie don't insert a Eth PW as this 
> is rather a
> > sledgehamer approach to creating functional isolation between 2
> > different MPLS stacks;
> > (ii) try and ensure we could minimise the risk of misdelivery under
> > defect conditions....which is always a possibility due to 
> the arbitrary
> > LSP sublayering hierarchy that a digital wrapper, ie S bit, approach
> > has.
> > 
> > I therefore concluded that for the unique case of 
> MPLS(TP)overMPLS(TP)
> > (with a desire to preserve the original S bit concept) it 
> would be best
> > to use a gloabally well-known label that is *not* used in the DP for
> > normal LSP forwarding purposes...that is a label drawn from the 0-15
> > set.
> > 
> > This would have special DP significance (ie a functional breakwater
> > between different MPLS LSP stacks) and would have a very restricted
> > pouplation size compared to a normal fowarding label (drawn 
> from the >15
> > value label set).  Thus, this would help mitigate the risk of
> > misconnectivity between different operator MPLS networks.
> > 
> > I still think this is what we should do here.
> > 
> > regards, Neil
> > 
> >> -----Original Message-----
> >> From: Lou Berger [mailto:[email-masked]] 
> >> Sent: 27 August 2009 16:22
> >> To: Harrison,N,Neil,DEY2 R
> >> Cc: [email-masked]
> >> Subject: Re: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]
> >>
> >> Neil,
> >> 	See below.
> >>
> >> On 8/27/2009 10:56 AM, [email-masked] wrote:
> >>> Thanks Lou,
> >>>
> >>> Assuming I am reading this correctly, the client semantic 
> >> (ie 'who') is
> >>> carried by the (20 bit) service label....so how does 
> >> setting S=1 here
> >>> add value?  
> >> The way I see it is that the S bit provides an unambiguous 
> >> indication of
> >> when forwarding should stop at a particular layer of the 
> >> network.  So if
> >> operating within an MPLS-TP domain, the domain boundary is always
> >> represented in the packet.
> >>
> >> I think this is important from a misdelivery/misconfiguration
> >> perspective.  If we didn't care about such cases, it's not 
> >> clear that an
> >> S bit would ever have been needed.  Even in the original 
> definition of
> >> MPLS.
> >>
> >> Also, I think the use of labels after the S bit is allowed 
> >> for by 3032.
> >> Sure there's an implicit expectation that the 'Network 
> Layer Protocol'
> >> carried by MPLS isn't MPLS, but if MPLS is itself considered 
> >> a 'Network
> >> Layer Protocol' then this is allowed by 3032.
> >>
> >>> Seems to me we could set S=1 in all headers and just rely on
> >>> the label semantic with this logic.
> >>>
> >> Sure. we could also always set it to 0.  Again, this holds 
> >> true for base
> >> MPLS too.
> >>
> >>> BTW - I don't think choosing a normal forwarding header is 
> >> a good idea
> >>> anyway for the case of MPLS(TP)overMPLS(TP).  Not only have 
> >> we got the
> >>> existing case of misconncetivity between LSPs in the same 
> party MPLS
> >>> layer network, now we can have this between different party 
> >> MPLS layer
> >>> networks.  
> >> If you're saying misconnection between different layers, 
> than this is
> >> what use of the S bit precludes.  If you're saying 
> misconnection among
> >> different clients at the same layer, while this is true, I 
> >> don't see how
> >> it differs from any misconection case.
> >>
> >>> What I am essentially postulating here is that the
> >>> misconnectivity risk is larger with a normal fowarding 
> >> label (drawn from
> >>> the >15 value population) than with a special reserved 
> >> label (drawn from
> >>> the 0-15 set)....simply on the basis of how many nodes 
> >> would expect to
> >>> see (ie have issued) the relevant label in the 2 cases.
> >>>
> >> So how do you prefer/propose to address this point?
> >>
> >> Thanks,
> >> Lou
> >>
> >>> regards, Neil  
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] 
> >>>> [mailto:[email-masked]] On Behalf Of Lou Berger
> >>>> Sent: 27 August 2009 15:00
> >>>> To: [email-masked]
> >>>> Subject: [mpls-tp] [Fwd: Re: That S-bit discussion (again)]
> >>>>
> >>>> Looks like the LabN and IETF servers have decided to not 
> >> talk to each
> >>>> other, so this message didn't make it to the list.
> >>>>
> >>>> Lou
> >>>>
> >>>> -------- Original Message --------
> >>>> Subject: Re: [mpls-tp] That S-bit discussion (again)
> >>>> Date: Wed, 26 Aug 2009 13:22:10 -0400
> >>>> From: Lou Berger <[email-masked]>
> >>>> To: Adrian Farrel <[email-masked]>
> >>>> CC: Drake, John E <[email-masked]>, [email-masked],
> >>>> [email-masked]
> >>>>
> >>>> Adrian/All,
> >>>>
> >>>> I agree with John on this. I think this issue is now 
> addressed in:
> >>>> http://tools.ietf.org/html/draft-ietf-mpls-tp-framework-02#sec
> >>>> tion-3.4.1
> >>>>
> >>>> Note that this section is quite a bit different than in 
> >> the 01 rev and
> >>>> it's worth taking a look.
> >>>>
> >>>> It explicitly covers S bit handling:
> >>>>
> >>>>    Within the MPLS-TP transport network, the network layer 
> >>>> protocols are
> >>>>    carried over the MPLS-TP LSP using a separate MPLS 
> >> label stack (the
> >>>>    server stack).  The server stack is entirely under the 
> >>>> control of the
> >>>>    nodes within the MPLS-TP transport network and it is 
> not visible
> >>>>    outside that network.  In accordance with [RFC3032], 
> the bottom
> >>>>    label, with the 'bottom of stack' bit set to '1', defines 
> >>>> the network
> >>>>    layer protocol being transported.  Figure 5 shows how 
> >> an a client
> >>>>    network protocol stack (which may be an MPLS label stack 
> >>>> and payload)
> >>>>    is carried over as a network layer transport service over 
> >>>> an MPLS-TP
> >>>>    transport network.
> >>>>
> >>>>          +------------------------------------+
> >>>>          |        MPLS-TP LSP label(s) (S=0)  | n*4 octets
> >>>>          .                                    . (four octets 
> >>>> per label)
> >>>>          +------------------------------------+
> >>>>          |      Service label (s=1)           |   4 octets
> >>>>          +------------------------------------+
> >>>>          |       Client Network               |
> >>>>          |       Layer Protocol               |
> >>>>          |           Stack.                   |
> >>>>          +------------------------------------+
> >>>>
> >>>>       Note that the Client Network Layer Protocol
> >>>>       Stack may include an MPLS label stack
> >>>>       with the S bit set (S=1).
> >>>>
> >>>>
> >>>>          Figure 5: Network Layer Transport Service Protocol Stack
> >>>>
> >>>> It also covers handling on the terminating PE (Mach Chen's 
> >> question):
> >>>>    A label per network layer protocol payload type that is to be
> >>>>    transported is REQUIRED.  Such labels are referred to 
> >> as "Service
> >>>>    Labels", one of which is shown in Figure 5.  The 
> mapping between
> >>>>    protocol payload type and Service Label is either 
> configured or
> >>>>    signaled.
> >>>>
> >>>> Lou
> >>>>
> >>>> On 8/25/2009 6:39 PM, Drake, John E wrote:
> >>>>> Adrian,
> >>>>>
> >>>>> This is consistent with my understanding and is what is 
> written in
> >>>>> section 3.4.1 of the overview I-D.
> >>>>>
> >>>>> RFC 3032 uses the terminology defined in RFC 3031 and 
> >>>> 'network layer' is
> >>>>> defined to be 'layer 3'.  RFC 3032 is silent as to whether 
> >>>> an MPLS stack
> >>>>> can be part of a network layer payload.  Section 3.4.1 
> >>>> explicitly states
> >>>>> that it can.
> >>>>>
> >>>>> To answer your separate question, it seems to be pretty 
> >>>> clear that RFC
> >>>>> 3032 considers  the transport of a network layer payload 
> >> without an
> >>>>> intervening pseudo-wire to be the normal case.  I think it 
> >>>> is also the
> >>>>> case that if the client is transporting pseudo-wire 
> >>>> payloads, they would
> >>>>> start with a client MPLS stack.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> John 
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Adrian Farrel [mailto:[email-masked]] 
> >>>>>> Sent: Tuesday, August 25, 2009 3:21 PM
> >>>>>> To: [email-masked]
> >>>>>> Subject: [mpls-tp] That S-bit discussion (again)
> >>>>>>
> >>>>>> Prompted by something Neil said, he and I have had a quick 
> >>>>>> exchange and find we don't have the same interpretation of 
> >>>> RFC 3032.
> >>>>>> To quote from Section 2.1 of the RFC...
> >>>>>>
> >>>>>>    The label stack entries appear AFTER the data link layer 
> >>>>>> headers, but
> >>>>>>    BEFORE any network layer headers.  The top of the label 
> >>>>>> stack appears
> >>>>>>    earliest in the packet, and the bottom appears latest.  
> >>>> The network
> >>>>>>    layer packet immediately follows the label stack entry 
> >>>>>> which has the
> >>>>>>    S bit set.
> >>>>>>
> >>>>>>    Each label stack entry is broken down into the 
> >> following fields:
> >>>>>>       1. Bottom of Stack (S)
> >>>>>>
> >>>>>>          This bit is set to one for the last entry in the 
> >>>> label stack
> >>>>>>          (i.e., for the bottom of the stack), and zero for 
> >>>> all other
> >>>>>>          label stack entries.
> >>>>>>
> >>>>>> Our debate may a bit legalistic :-)
> >>>>>>
> >>>>>> What is a "label stack," and what is a "network layer 
> >>>> header/packet"?
> >>>>>> I am suggesting that, by definition, a label stack is 
> >>>>>> something that ends with an S-bit set to 1. Anything that 
> >>>>>> follows is payload. Therefore, if what follows is another 
> >>>>>> label stack, this is just fine, and that separate label stack 
> >>>>>> will also have its S-bit set to 1 at the bottom of the stack. 
> >>>>>> In my world, this does not represent one label stack with two 
> >>>>>> S=1 settings; it is two label stacks each with one S=1 setting.
> >>>>>>
> >>>>>> I accept that *one* way to carry MPLS over MPLS is to simply 
> >>>>>> increase the depth of a single label stack (and so have just 
> >>>>>> one S=1). But I suggest that the better way to achieve 
> >>>>>> demarcation between client and server networks (such as MPLS 
> >>>>>> over MPLS-TP) is to set S=1 at the bottom of the MPLS-TP 
> >>>>>> stack. In this view, the client MPLS stack is the "network 
> >>>>>> layer header."
> >>>>>>
> >>>>>> [It is a separate question whether the MPLS over MPLS-TP 
> >>>>>> payload is carried native or via a packet-PW. I suggest we 
> >>>>>> try to answer one question before embarking on the second 
> >>>> question!]
> >>>>>> Opinions?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Adrian 
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> mpls-tp mailing list
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>>>>
> >>>>> _______________________________________________
> >>>>> mpls-tp mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> mpls-tp mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>>
> >>>
> >>>
> > 
> > 
> > 
>

---

From: Yong Lucy <[email-masked]>
Date: Thu, 27 Aug 2009 11:51:11 -0500

Thank you Lou's notice about this thread. I agree with Adrian, John, Lou's
S-bit interpretation. In addition, I think it is necessary to revise the
current framework draft to clarify that MPLS-TP consider dynamic MPLS PW as
a client network, not as a PW client because dynamic MPLS PW relies on MPLS
DP & CP. MPLS-TP PW client should be a static MPLS PW that use the MPLS
label semantics and is configured without MPLS CP involvement.

I have stated this more detail in another email. Hope MEAD team can consider
this suggestion.

Regards,
Lucy  

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Thursday, August 27, 2009 11:31 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 12:53:26 -0400

Neil,
	Thank you for the response.  I think it's helpful to provide context
and perspective.  I agree or have no argument with most of your message,
and only one point that I want to follow up on:

> should not be due to a misconnectivity defect.

When using the S bit as the layer boundary identifier, the label value
is ignored, so the fact that it is in use is immaterial.  I think the
two alternative we have are:

      With Reserved Label:      With TP Layer S bit

 [     TP Label, s = 0   ]
 [      Reserved Label   ]    [     TP Label, s = 1   ]
 [Client MPLS label stack]    [Client MPLS label stack]
 [         data          ]    [         data          ]

In the first case it's the reserved label value that provides the
'functional breakwater'(and the S bits MUST be 0 in the whole TP label
stack), in the second it's the presence of S=1 (and the S bits MUST be 0
in the rest of the TP label stack).

Given both are a unique and fixed bit pattern in the label stack, I just
don't see how either case provides any different misconnectivity
risks/benefits.

Is it time to agree to disagree?

BTW I do agree that the discussion would be different if one were not
allowed to set the S bit in the TP domain when the client traffic is
MPLS.  As I said before, I just don't see this restriction.

Thanks,

Lou

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 18:11:10 +0100

Thanks Lou for the explanation...and on your specific follow-up point:
 
> is ignored, so the fact that it is in use is immaterial.

NH=> Perhaps I misundertood the original intent....which I thought was
that the 'service label' carried the context of what the client actually
was (after the 'service label' with S=1).

  I think the
> stack),

NH=> In my mind I would have the reserved label with S=1...but yes you
are right that it's the reserved label value that carries the key
semantic as to what the client is, ie another/different MPLS LSP stack.

> in the second it's the presence of S=1 (and the S 
> bits MUST be 0

NH=> I still think there is a difference here.  In the 2nd case above
(ie arbitrary TP forwarding label and S=1) this would be valid
irrespective of what follows, ie all client cases, not just client=MPLS
case.  So if a MPLSoverMPLS LSP where S=1 became misconnected to some
other node expecting a different client it would still pass the 'normal
forwarding label + S=1' test and then proceed to process the client
information incorrectly.  

Or have I missed something?

regards, Neil

---

From: Lou Berger <[email-masked]>
Date: Thu, 27 Aug 2009 18:30:59 -0400

Neil,
	See below.

> was (after the 'service label' with S=1).

I'm not sure what you mean.  3.4.1 says:
         +------------------------------------+
         |        MPLS-TP LSP label(s) (S=0)  | n*4 octets
         .                                    . (four octets per label)
         +------------------------------------+
         |      Service label (s=1)           |   4 octets
         +------------------------------------+
         |       Client Network               |
         |       Layer Protocol               |
         |           Stack.                   |
         +------------------------------------+

So the "TP Label, s = 1" is the same as "Service label (s=1)",i.e., the
TP network only adds one label with the S bit = 1, not two as I think
you are saying above.

> semantic as to what the client is, ie another/different MPLS LSP stack.

Sounds like wearing a belt with suspenders (braces) to me ;-)

> Or have I missed something?

Ahh, so your point is that the use of the reserved label eliminates
misconections between an MPLS client and a non-MPLS client.  Right?

Yes, this is true, but it does nothing for misconections between an MPLS
client and another MPLS client, or between non-MPLS clients.  Sounds
like an optimization for a very narrow special case.  Do you really
think adding a reserved label is warranted for such a narrow special
case?  Isn't a provider most likely to have multiple/many customers of
similar client types?

Thanks for the interesting discussion.
Lou

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 23:58:06 +0100

Thank you Lou...not sure if anything is coalescing from this yet.  Some

> I'm not sure what you mean.  3.4.1 says:

NH=> No, I only meant a single label, ie service label (ie implies
client knowledge held by CP/MP) with S=1 in that label header.
> Sounds like wearing a belt with suspenders (braces) to me ;-)

NH=> ...better than wearing an unnecessary outer MS-PW apparel IMO ;-)
> misconections between an MPLS client and a non-MPLS client.  Right?

NH=> As a by-product yes.  The intent, however, is a globally well-known
meaning for the specific case of MPLSoverMPLS *because* we (or some at
least) want to retain S bit sublayering....if not then treat all client
alike and scrap the S bit!  This takes us to a true client/server per
LSP case...which is rather a good model for a transport network (CF
GMPLS work for the co-cs mode...no sublayering issue here).
> 
> Yes, this is true, but it does nothing for misconections 
> between an MPLS client and another MPLS client, or between non-MPLS
clients.

NH=> Yes I know...and this is what I pointed out at the start.
Sublayering in MPLS means we always have the issue that misconnections
can occur in *this* MPLS layer network.  That is a fact today and a
consequence of the S bit sublayering architecture (remember I said it
has benefits and drawbacks).  What I was trying to avoid was carrying
this *general* case over into MPLSoverMPLS, ie between the MPLS network
of 2 different parties.....or at least to try and minimise any
carry-over incidence of such, which my proposal does but a normal
fowarding label does not.

> Sounds
> like an optimization for a very narrow special case.

NH=> Well it is a special case caused by sublayering.  If you don't like
it then let's deprecate the S bit in MPLS-TP and have each LSP a layer
network in its own right.

>  Do you really
> case? 

NH=> If folks want to retain S bit sublayering in MPLS-TP then yes I do.

>  Isn't a provider most likely to have multiple/many customers of
> similar client types?

NH=> Not sure I am following you.  For a general (non-MPLS) client case
we have the PW adaptation.  If we removed S bit sublayering we would
have the same PW adaptation case for an MPLS client, ie each LSP is a
layer network in its own right.  But if we want to retain sublayering
(ie S bit attempting to remain true to the original MPLS design...for
good or bad) then it does warrant a special case.  I'm struggling to
grasp why this is hard to understand.
> Thanks for the interesting discussion.

NH=> You are welcome.  But I think its more than simply 'interesting'
Lou, because if MPLS-TP is serious about becoming a next gen transport
network the one thing it MUST do is elegantly/efficiently solve the
MPLSoverMPLS case as a true client/server case....and this is precisely
what I am trying to do.  So I am not really understanding the resistance
to help fix an important practical problem.

regards, Neil

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Aug 2009 09:54:45 -0400

Neil,

> Thank you Lou...not sure if anything is coalescing from this yet.  Some

agreed (both points.)

> client knowledge held by CP/MP) with S=1 in that label header.

Okay, we're in-sync on this point.

> NH=> ...better than wearing an unnecessary outer MS-PW apparel IMO ;-)

No argument about this point (at least one hopes...)

> GMPLS work for the co-cs mode...no sublayering issue here).

I 100% concur on the point that all LSP clients should be treated the
same.  This point is far more important (IMO) than if the in-packet
demarcation is a 1 or n bits, and is really one of the prime motivations
for my position.

That said, using multiple labels within a network is an important tool
within a network (notably for protection and transit state reduction)
and I don't think we should lose it.

> fowarding label does not.

Okay, I believe I understand your perspective.  It just seems to me that
this isn't a case worth minimizing (given that it does nothing to help
cross-connections within the same client type) at the expense of
treating all clients in a common fashion.

> network in its own right.

I think I covered this point above.

> grasp why this is hard to understand.

I'm seeing this issue as really two points:

(1) n vs 1 bit for demarcation.  I don't think this point is so
significant and can accept either, but MPLS historically has used the S
bit in the common case so would prefer that.  This is not an
absolute/fundamental position for me, but think it might be for some.

(2) the independence of the MPLS label stack from the client (network)
layer.  As discussed above, I think this is the primary point and
believe this is a point worth pushing.  Which to me means no special
label for an MPLS client.  That said, there is precedent for a special,
client-type specific reserved label (IPv4 and IPv6 Explicit NULL labels)
so we could define the MPLS Explicit NULL label if it was really
beneficial.  I just haven't seen a benefit that outweighs the downside.

> what I am trying to do.  

I think we're in agreement here.

> So I am not really understanding the resistance

See above.

Lou

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 28 Aug 2009 09:38:29 -0700

I agree with all of Lou's points, which is rare. 

> Sent: Friday, August 28, 2009 6:55 AM
> To: [email-masked]
> Cc: [email-masked]
> > Thank you Lou...not sure if anything is coalescing from this yet.  
> > Some more responses in-line:
> 
> agreed (both points.)
> 
> > 
> > 
> >> Neil,
> >> 	See below.
> >>
> >> So the "TP Label, s = 1" is the same as "Service label 
> (s=1)",i.e., 
> >> the TP network only adds one label with the S bit = 1, not 
> two as I 
> >> think you are saying above.
> > 
> >>>> in the second it's the presence of S=1 (and the S bits 
> MUST be 0 in 
> >>>> the rest of the TP label stack).
> >>>>
> >>>> Given both are a unique and fixed bit pattern in the 
> label stack, I 
> >>>> just don't see how either case provides any different 
> >>>> misconnectivity risks/benefits.
> >>>>
> > NH=> As a by-product yes.  The intent, however, is a globally 
> > well-known meaning for the specific case of MPLSoverMPLS 
> *because* we 
> > (or some at
> > least) want to retain S bit sublayering....if not then treat all 
> > client alike and scrap the S bit!  This takes us to a true 
> > client/server per LSP case...which is rather a good model for a 
> > transport network (CF GMPLS work for the co-cs mode...no 
> sublayering issue here).
> 
> I 100% concur on the point that all LSP clients should be 
> treated the same.  This point is far more important (IMO) 
> than if the in-packet demarcation is a 1 or n bits, and is 
> really one of the prime motivations for my position.
> 
> That said, using multiple labels within a network is an 
> important tool within a network (notably for protection and 
> transit state reduction) and I don't think we should lose it.
> 
> between an 
> >> MPLS client and another MPLS client, or between non-MPLS
> > clients.
> > 
> > this *general* case over into MPLSoverMPLS, ie between the MPLS 
> > network of 2 different parties.....or at least to try and 
> minimise any 
> Okay, I believe I understand your perspective.  It just seems 
> to me that this isn't a case worth minimizing (given that it 
> does nothing to help cross-connections within the same client 
> type) at the expense of treating all clients in a common fashion.
> 
> > 
> > 
> >> Sounds
> > NH=> Well it is a special case caused by sublayering.  If you don't 
> > like it then let's deprecate the S bit in MPLS-TP and have 
> each LSP a 
> > layer network in its own right.
> > 
> 
> > NH=> Not sure I am following you.  For a general (non-MPLS) client 
> > case we have the PW adaptation.  If we removed S bit sublayering we 
> > would have the same PW adaptation case for an MPLS client, 
> ie each LSP 
> > is a layer network in its own right.  But if we want to retain 
> > sublayering (ie S bit attempting to remain true to the 
> original MPLS 
> > design...for good or bad) then it does warrant a special case.  I'm 
> > struggling to grasp why this is hard to understand.
> 
> (1) n vs 1 bit for demarcation.  I don't think this point is 
> so significant and can accept either, but MPLS historically 
> has used the S bit in the common case so would prefer that.  
> This is not an absolute/fundamental position for me, but 
> think it might be for some.
> 
> (2) the independence of the MPLS label stack from the client 
> (network) layer.  As discussed above, I think this is the 
> primary point and believe this is a point worth pushing.  
> Which to me means no special label for an MPLS client.  That 
> said, there is precedent for a special, client-type specific 
> reserved label (IPv4 and IPv6 Explicit NULL labels) so we 
> could define the MPLS Explicit NULL label if it was really 
> > MPLSoverMPLS case as a true client/server case....and this is 
> > precisely what I am trying to do.
> 
> > So I am not really understanding the resistance to help fix an 
> > important practical problem.
> 
> See above.
> 
> Lou
> 
> > 
> > regards, Neil
> > 
> >> Lou
> >>
> >>> regards, Neil