Subject: [mpls-tp] MPLS-TP Sections vs PSTs

From: Lavanya Srivatsa <[email-masked]>
Date: Mon, 3 May 2010 20:54:41 +0530

Hello TP-group,

Reading through the definition of MPLS-TP Sections as given in draft-ietf-mpls-tp-data-plan-01 (Section 3.2), this seems to refer to the lower layer/level of a hierarchical LSP. This looks to be very similar in definition to that of a Path Segment Tunnel construct given in draft-ietf-mpls-tp-framework-11 (Section 3.13).
So are MPLS-TP Sections and Path Segment Tunnels the same or am I missing something here? If so, what is the difference between the two in their architecture or behaviour/functionality?

- Lavanya

---

From: John E Drake <[email-masked]>
Date: Mon, 3 May 2010 08:45:11 -0700

Lavanya,

A section is what anyone in the IETF would term a link.  For some reason it was deemed necessary to have another term.

Thanks,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lavanya Srivatsa
> Sent: Monday, May 03, 2010 8:25 AM
> To: MPLS TP
> Subject: [mpls-tp] MPLS-TP Sections vs PSTs
> 
> Hello TP-group,
> 
> 
> 
> Reading through the definition of MPLS-TP Sections as given in draft-ietf-
> mpls-tp-data-plan-01 (Section 3.2), this seems to refer to the lower
> layer/level of a hierarchical LSP. This looks to be very similar in
> definition to that of a Path Segment Tunnel construct given in draft-ietf-
> mpls-tp-framework-11 (Section 3.13).
> 
> So are MPLS-TP Sections and Path Segment Tunnels the same or am I missing
> something here? If so, what is the difference between the two in their
> architecture or behaviour/functionality?
> 
> 
> 
> - Lavanya

---

From: Lavanya Srivatsa <[email-masked]>
Date: Wed, 5 May 2010 00:51:40 +0530

John,

Thanks.

I got the same impression that an MPLS-TP Section referred to a link, based on what I read in the draft-ietf-mpls-tp-identifiers-01 draft, wherein it was stated as follows in section 4.2.1.2: "With regard to the MPLS Section, a G-ACh exists between A and Z. Only A and Z can insert, extract, or process packets on this G-ACh. The following figure (Figure 8) depicts the format of a G-ACh packet when used for an MPLS Section.  The GAL MAY provide the exception mechanism for a control channel in its own right without being    associated with a specific LSP, thus providing maintenance-related communications across a specific link interconnecting two LSRs.  In this case, the GAL is the only label in the stack."

However, what confused me and led me to think that an MPLS-TP Section seemed to be the same as a PST is the definition of an MPLS-TP Section that I found in the draft-ietf-mpls-tp-data-plane-02 draft (which is referred to by the MPLS-TP framework draft for the definition of the Section). This states as follows in section 3.2:

"Two MPLS-TP LSRs are considered to be topologically adjacent at a particular layer n >= 0 of the MPLS-TP LSP hierarchy if there exists connectivity between them at the next lowest network layer.  Such connectivity, if it exists, will be either an MPLS-TP LSP (if n > 0) or a data-link provided by the underlying server layer network (if n = 0), and is referred to as an MPLS-TP Section at layer n of the MPLS-TP LSP hierarchy.  Thus, the links traversed by a layer n+1 MPLS-TP LSP are layer n MPLS-TP sections.  Such an LSP is referred to as a client of the section layer, and the section layer as the server layer with respect to its clients."

I think there is an inconsistency in the above paragraph with respect to what the "layer n" refers to (which I have raised in a separate mail to the group). But that apart, from the above, I get the feeling that only the "data-link provided by the underlying server layer network (if n=0)" case seems to refer to a link. However the n>0 case seems to refer to a Section as an underlying LSP (server layer), which to me, in one sense, seems similar to the definition of a Path Segment Tunnel (hierarchical LSP) and is not in sync with the definition of a Section as simply a link.

Would appreciate thoughts/comments on this.

Relevant Draft Authors,

              Could you help with some clarifications on the above?

- Lavanya

________________________________________
From: John E Drake [[email-masked]]
Sent: Monday, May 03, 2010 9:15 PM
To: Lavanya Srivatsa; MPLS TP
Subject: RE: MPLS-TP Sections vs PSTs

Lavanya,

Thanks,

John

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 5 May 2010 00:13:47 +0300

Lavania, John and all,
This thread  looks to me like one more indicator of the somewhat messy notions we try to use in MPLS-TP.

For the reasons beyond my understanding, the transport people want to treat a regular data link as an LSP with stack depth 0. IMO this results in general confusion.

The Editors of the MPLS-TP data plane draft have promised to add a clarification that would explain the data links are different from "real LSP" Sections, because data links have their own methods for identifying "network layer" protocols. (In particular, MPLS-TP packets are identified as labeled packets using these methods:-).

One  question that IMO is worth asking is the following:

Do we really need to carry Management and Control plane traffic over data link sections using GAL and G-ACh, or could we go on carrying them directly over the data links as it is done today?
My 2c,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lavanya Srivatsa [[email-masked]]
Sent: Tuesday, May 04, 2010 10:21 PM
To: John E Drake; MPLS TP
Subject: Re: [mpls-tp] MPLS-TP Sections vs PSTs

John,

Thanks.

Relevant Draft Authors,

- Lavanya

Lavanya,

Thanks,

John

---

From: John E Drake <[email-masked]>
Date: Tue, 4 May 2010 14:56:18 -0700

> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Tuesday, May 04, 2010 2:14 PM
> To: Lavanya Srivatsa; John E Drake
> Cc: MPLS TP
> For the reasons beyond my understanding, the transport people want to
> treat a regular data link as an LSP with stack depth 0. IMO this results
> in general confusion.

JD:  Yes indeed

> 
> The Editors of the MPLS-TP data plane draft have promised to add a
> clarification that would explain the data links are different from "real
> LSP" Sections, because data links have their own methods for identifying
> "network layer" protocols. (In particular, MPLS-TP packets are identified
> as labeled packets using these methods:-).

JD:  Does this mean we will be eliminating 'section' as a synonym for 'link'?

> 	Do we really need to carry Management and Control plane traffic over
> data link sections using GAL and G-ACh, or could we go on carrying them
> directly over the data links as it is done today?

JD:  A good question.  Another good question:  is RFC 5718 really needed?

> From: [email-masked] [[email-masked]] On Behalf Of
> Lavanya Srivatsa [[email-masked]]
> I got the same impression that an MPLS-TP Section referred to a link,
> based on what I read in the draft-ietf-mpls-tp-identifiers-01 draft,
> wherein it was stated as follows in section 4.2.1.2: "With regard to the
> MPLS Section, a G-ACh exists between A and Z. Only A and Z can insert,
> extract, or process packets on this G-ACh. The following figure (Figure 8)
> depicts the format of a G-ACh packet when used for an MPLS Section.  The
> GAL MAY provide the exception mechanism for a control channel in its own
> right without being    associated with a specific LSP, thus providing
> maintenance-related communications across a specific link interconnecting
> two LSRs.  In this case, the GAL is the only label in the stack."
> 
> 
> 
> However, what confused me and led me to think that an MPLS-TP Section
> seemed to be the same as a PST is the definition of an MPLS-TP Section
> that I found in the draft-ietf-mpls-tp-data-plane-02 draft (which is
> referred to by the MPLS-TP framework draft for the definition of the
> Section). This states as follows in section 3.2:
> 
> "Two MPLS-TP LSRs are considered to be topologically adjacent at a
> particular layer n >= 0 of the MPLS-TP LSP hierarchy if there exists
> connectivity between them at the next lowest network layer.  Such
> connectivity, if it exists, will be either an MPLS-TP LSP (if n > 0) or a
> data-link provided by the underlying server layer network (if n = 0), and
> is referred to as an MPLS-TP Section at layer n of the MPLS-TP LSP
> hierarchy.  Thus, the links traversed by a layer n+1 MPLS-TP LSP are layer
> n MPLS-TP sections.  Such an LSP is referred to as a client of the section
> layer, and the section layer as the server layer with respect to its
> clients."
> 
> 
> 
> I think there is an inconsistency in the above paragraph with respect to
> what the "layer n" refers to (which I have raised in a separate mail to
> the group). But that apart, from the above, I get the feeling that only
> the "data-link provided by the underlying server layer network (if n=0)"
> case seems to refer to a link. However the n>0 case seems to refer to a
> Section as an underlying LSP (server layer), which to me, in one sense,
> seems similar to the definition of a Path Segment Tunnel (hierarchical
> LSP) and is not in sync with the definition of a Section as simply a link.
> 
> A section is what anyone in the IETF would term a link.  For some reason
> it was deemed necessary to have another term.
> 
> Thanks,
> 
> John
>

---

From: Lavanya Srivatsa <[email-masked]>
Date: Thu, 6 May 2010 01:18:35 +0530

John, Sasha,

Based on Sasha's comment about "real LSP" Sections and Stewart's response/clarification in the other mail thread about the confusing definition/text in the data-plane draft for an MPLS-TP Section, it seems clear that a Section could be a data link OR an (underlying) LSP for a client LSP above it.

So I am repeating my question here - what then, is the difference between a Section and a PST (now termed SPME)? Both are/can be, in one sense, lower layer/LSP in a hierarchical LSPs setup. 

Also, when RFC 5654 (sorry I had misquoted at the tp-identifiers draft in my earlier mail) states only a GAL would be sufficient for a packet carried on a Section, how would this be correct if the Section were an (underlying) LSP and not a data link?

Can you confirm what is correct here?

- Lavanya
________________________________________
From: John E Drake [[email-masked]]
Sent: Wednesday, May 05, 2010 3:26 AM
To: Alexander Vainshtein; Lavanya Srivatsa
Cc: MPLS TP
Subject: RE: MPLS-TP Sections vs PSTs

JD:  Yes indeed

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 May 2010 14:00:06 -0700

Dear Lavaya,
thank you for your questions as you've prompted me to clear my understanding
of the subject.
Since a PST is an LSP in itself, it might be seen by n+1 layer of MPLS-TP as
a Section. that might be either in Segment protection or OAM cases.
To your second  question, if PST is viewed as a Section, the GAL will be BoS
though the appropriate LSEs of the PST will be applied as well.

Regards,
Greg

On Wed, May 5, 2010 at 12:48 PM, Lavanya Srivatsa <
[email-masked]> wrote:

> John, Sasha,
>
> Based on Sasha's comment about "real LSP" Sections and Stewart's
> response/clarification in the other mail thread about the confusing
> definition/text in the data-plane draft for an MPLS-TP Section, it seems
> clear that a Section could be a data link OR an (underlying) LSP for a
> client LSP above it.
>
> So I am repeating my question here - what then, is the difference between a
> Section and a PST (now termed SPME)? Both are/can be, in one sense, lower
> layer/LSP in a hierarchical LSPs setup.
>
> Also, when RFC 5654 (sorry I had misquoted at the tp-identifiers draft in
> my earlier mail) states only a GAL would be sufficient for a packet carried
> on a Section, how would this be correct if the Section were an (underlying)
> LSP and not a data link?
>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: John E Drake <[email-masked]>
Date: Wed, 5 May 2010 14:35:36 -0700

The correct answer is that it is a desert topping and a floor wax.

> From: Lavanya Srivatsa [mailto:[email-masked]]
> Sent: Wednesday, May 05, 2010 12:49 PM
> To: John E Drake; Alexander Vainshtein
> Cc: MPLS TP
> So I am repeating my question here - what then, is the difference between
> a Section and a PST (now termed SPME)? Both are/can be, in one sense,
> lower layer/LSP in a hierarchical LSPs setup.
> 
> my earlier mail) states only a GAL would be sufficient for a packet
> carried on a Section, how would this be correct if the Section were an
> (underlying) LSP and not a data link?
> 
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or
> used for any purpose other than for what it is intended. If you have
> received this message in error, please notify the originator immediately.
> If you are not the intended recipient, you are notified that you are
> strictly prohibited from using, copying, altering, or disclosing the
> contents of this message. Aricent accepts no responsibility for loss or
> damage arising from the use of the information transmitted by this email
> including damage from virus."

---

From: <[email-masked]>
Date: Wed, 5 May 2010 23:11:36 +0100

My goodness how can we make such a simple issue so complex?  Perhaps you
missed all my posts of the last few years?  
 
MPLS as-is is unfortunately an architectural mess when considered as a
stand-alone co-ps mode transport network....and in a nutshell, a proper
co-ps mode transport network should:
-    be fully transparent......ignoring the full description of what
transparency requires here, please simply note that multiple QoS classes
per connection are a no-no in a transport network since this MUST
preserve client information ordering (noting that the server transport
layer must not make any judgment on urgency or, in particular,
importance of client symbols)
-    only have p2p and p2mp connections
-    not use any TTL....this is obviously quite unnecessary as the CP/MP
can check for no looping before placing a connection
-    not use any sublayering (this is the S bit in MPLS as-is)....not
only is this unnecessary but it is downright technically
wrong/dangerous...see Note
-    for sure not generate another PW co-ps mode layer network above
it!!!!!
-    be able to map a binary path layer signal to a section layer
physical q'ary signal..in other words be able to 'put bits on the wire'
like SDH, OTN and Ethernet can
 
Note - There is a *very big* difference between sublayering and
layering.  In the former we have a single/common layer network...in
particular note this has a set of common access points (ie addressable
access points of THIS singular layer network) and usually a common
routing process for this layer network graph.  In the case of true
layering (as indeed we need in a transport network) however none of that
applies.  Each LSP in a nested set of LSPs would belong to a different
layer network....so each LSP exists in a functionally disjoint DP/CP/MP
network sense to other nested LSPs.  So this is not like traditional
MPLS sublayering (S bit) at all.  And yet, if we are supposed to be
building a transport network we MUST have layering and not
sublayering...this is THE key raison d'etre for doing this.
 
So, to cut to the chase, S bit sublayering and PWs should not exist in
MPLS-TP...so why do they still exist?  Can someone (eg the Area
Directors) please explain why IETF continue to make this rather obvious
technical error?  
 
Aside=> If you need a technical (political?) way-out then simply say
'MPLS-TP is NOT a transport network (which is obviously true anyway IMO)
but is a type of MPLS as-is where we have taken the CP/MP OOB and banned
merging'....this is at least some very useful technical progress.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Greg Mirsky
	Sent: 05 May 2010 22:00
	To: Lavanya Srivatsa
	Cc: MPLS TP
	Subject: Re: [mpls-tp] MPLS-TP Sections vs PSTs

	Dear Lavaya,
	thank you for your questions as you've prompted me to clear my
understanding of the subject.
	Since a PST is an LSP in itself, it might be seen by n+1 layer
of MPLS-TP as a Section. that might be either in Segment protection or
OAM cases.
	To your second  question, if PST is viewed as a Section, the GAL
will be BoS though the appropriate LSEs of the PST will be applied as
well.
	
	Regards,
	Greg

	On Wed, May 5, 2010 at 12:48 PM, Lavanya Srivatsa
<[email-masked]> wrote:

		John, Sasha,
		
		Based on Sasha's comment about "real LSP" Sections and
Stewart's response/clarification in the other mail thread about the
confusing definition/text in the data-plane draft for an MPLS-TP
Section, it seems clear that a Section could be a data link OR an
(underlying) LSP for a client LSP above it.
		
		So I am repeating my question here - what then, is the
difference between a Section and a PST (now termed SPME)? Both are/can
be, in one sense, lower layer/LSP in a hierarchical LSPs setup.
		
		Also, when RFC 5654 (sorry I had misquoted at the
tp-identifiers draft in my earlier mail) states only a GAL would be
sufficient for a packet carried on a Section, how would this be correct
if the Section were an (underlying) LSP and not a data link?

		- Lavanya

		Cc: MPLS TP
		
		> From: Alexander Vainshtein
[mailto:[email-masked]]
		> This thread  looks to me like one more indicator of
the somewhat messy
		> notions we try to use in MPLS-TP.
		>
		
		JD:  Yes indeed
		
		> as labeled packets using these methods:-).
		
		JD:  Does this mean we will be eliminating 'section' as
a synonym for 'link'?
		
		> directly over the data links as it is done today?
		
		JD:  A good question.  Another good question:  is RFC
5718 really needed?
		
		> > From: [email-masked]
[mailto:[email-masked]] On
		> Behalf
		> > Reading through the definition of MPLS-TP Sections
as given in draft-
		> ietf-
		> > definition to that of a Path Segment Tunnel
construct given in draft-
		> ietf-
		> > So are MPLS-TP Sections and Path Segment Tunnels the
same or am I
		> missing

---

From: "tom.petch" <[email-masked]>
Date: Thu, 6 May 2010 08:53:01 +0200

----- Original Message -----
From: "John E Drake" <[email-masked]>
To: "Lavanya Srivatsa" <[email-masked]>; "MPLS TP"
<[email-masked]>
Sent: Monday, May 03, 2010 5:45 PM

> Lavanya,
>
> A section is what anyone in the IETF would term a link.  For some reason it
was deemed necessary to have another term.
John

I think that there is a distinction worth drawing, at least in this context.

The IAB recently defined a link as

"A communication facility or medium over which nodes can
   communicate at the link-layer, i.e., the layer immediately
    below IP.  Examples are Ethernets (simple or bridged), PPP
    links, X.25, Frame Relay, or ATM networks as well as
    Internet (or higher) layer "tunnels", such as tunnels over
    IPv4 or IPv6 itself."

which for me captures the IETF flavour of "who cares? it's off
the bottom of our radar"
whereas in an ITU-T context, that link might be PPP over ATM over
optical transport over DWDM, and those eg working on DWDM
have little truck with those working on ATM yet both are topics
worthy of study.  Section is a more precise
concept in this alphabet soup, as Maarten Vissers has described on a number of
occasions on this list, and so could prove a useful
refinement in the context of MPLS-TP.

Tom Petch.

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Thu, 6 May 2010 12:08:13 +0200

Did I miss the MPLS in the definition of section in the IAB section definition?
If so why - can the IAB elaborate?

./
Lieven

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of tom.petch
> Sent: 06 May 2010 08:53
> To: John E Drake; Lavanya Srivatsa; MPLS TP

---

From: John E Drake <[email-masked]>
Date: Thu, 6 May 2010 05:51:35 -0700

YMMV

> From: tom.petch [mailto:[email-masked]]
> Sent: Wednesday, May 05, 2010 11:53 PM
> it

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 6 May 2010 16:36:48 +0200

Hi Neil,

Thanks for sharing this.

One simple question. You say: "-    not use any TTL....this is obviously
quite unnecessary as the CP/MP can check for no looping before placing a
connection"...........if this is a valid claim, so why do we need to
support a CV function? 

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext [email-masked]
Sent: Thursday, May 06, 2010 1:12 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Sections vs PSTs

regards, Neil

	Dear Lavaya,
	
	Regards,
	Greg

	John, Sasha,

	
	Also, when RFC 5654 (sorry I had misquoted at the tp-identifiers
draft in my earlier mail) states only a GAL would be sufficient for a
packet carried on a Section, how would this be correct if the Section
were an (underlying) LSP and not a data link?

	- Lavanya

	Cc: MPLS TP
	
	> This thread  looks to me like one more indicator of the
somewhat messy
	
	JD:  Yes indeed
	
	> as labeled packets using these methods:-).
	
	JD:  Does this mean we will be eliminating 'section' as a
synonym for 'link'?
	
	> directly over the data links as it is done today?
	
	JD:  A good question.  Another good question:  is RFC 5718
really needed?
	
	> > Reading through the definition of MPLS-TP Sections as given
in draft-
	> > definition to that of a Path Segment Tunnel construct given
in draft-
	> > So are MPLS-TP Sections and Path Segment Tunnels the same or
am I

---

From: <[email-masked]>
Date: Thu, 6 May 2010 16:00:05 +0100

Is this a serious question Nurit?  A CV checks for:
-    breaks
-    mismerging
-    misconnectivity
....all of which can happern at any time after a connection has been
initially placed
and it can also detect looping (at least I catered for it when I wrote
Y.1711 a long time ago).  
 
regards, neil

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
	Sent: 06 May 2010 15:37
	To: Harrison,N,Neil,DKQ7 R; [email-masked];
[email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] MPLS-TP Sections vs PSTs

	Hi Neil,

	Thanks for sharing this.

	One simple question. You say: "-    not use any TTL....this is
obviously quite unnecessary as the CP/MP can check for no looping before
placing a connection"...........if this is a valid claim, so why do we
need to support a CV function? 

	Best regards,

	Nurit

On Behalf Of ext [email-masked]

	My goodness how can we make such a simple issue so complex?
Perhaps you missed all my posts of the last few years?  

	MPLS as-is is unfortunately an architectural mess when
considered as a stand-alone co-ps mode transport network....and in a
nutshell, a proper co-ps mode transport network should:

	-    be fully transparent......ignoring the full description of
what transparency requires here, please simply note that multiple QoS
classes per connection are a no-no in a transport network since this
MUST preserve client information ordering (noting that the server
transport layer must not make any judgment on urgency or, in particular,
importance of client symbols)

	-    not use any TTL....this is obviously quite unnecessary as
the CP/MP can check for no looping before placing a connection

	-    not use any sublayering (this is the S bit in MPLS
as-is)....not only is this unnecessary but it is downright technically
wrong/dangerous...see Note

	-    for sure not generate another PW co-ps mode layer network
above it!!!!!

	-    be able to map a binary path layer signal to a section
layer physical q'ary signal..in other words be able to 'put bits on the
wire' like SDH, OTN and Ethernet can

	So, to cut to the chase, S bit sublayering and PWs should not
exist in MPLS-TP...so why do they still exist?  Can someone (eg the Area
Directors) please explain why IETF continue to make this rather obvious
technical error?  

	Aside=> If you need a technical (political?) way-out then simply
say 'MPLS-TP is NOT a transport network (which is obviously true anyway
IMO) but is a type of MPLS as-is where we have taken the CP/MP OOB and
banned merging'....this is at least some very useful technical progress.

	regards, Neil

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Greg Mirsky
		Sent: 05 May 2010 22:00
		To: Lavanya Srivatsa
		Cc: MPLS TP
		Subject: Re: [mpls-tp] MPLS-TP Sections vs PSTs

		Dear Lavaya,
		thank you for your questions as you've prompted me to
clear my understanding of the subject.
		Since a PST is an LSP in itself, it might be seen by n+1
layer of MPLS-TP as a Section. that might be either in Segment
protection or OAM cases.
		To your second  question, if PST is viewed as a Section,
the GAL will be BoS though the appropriate LSEs of the PST will be
applied as well.
		
		Regards,
		Greg

		John, Sasha,

		

		- Lavanya

		Cc: MPLS TP
		
the somewhat messy
		
		JD:  Yes indeed

		

		>      Sasha
[[email-masked]] On Behalf Of
as given in draft-
same or am I

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 6 May 2010 17:14:58 +0200

In principle, CC check breaks. I thought misconnectivity can be avoided
as you claims by CP or MP means, before the connection is placed.  

But as you say it is needed for all of which can happen at any time
after a connection has been placed.............this is correct and I
agree........so why TTL is not needed as well? It can be used as
additional mechanism to prevent endless loops, and other cases as well,
also when CV is not used!

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 06, 2010 6:00 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Sections vs PSTs

-    breaks

-    mismerging

-    misconnectivity

regards, neil

	Hi Neil,

	Thanks for sharing this.

	Best regards,

	Nurit

	regards, Neil

		Dear Lavaya,
		
		Regards,
		Greg

		John, Sasha,

		

		- Lavanya

		Cc: MPLS TP
		
the somewhat messy
		
		JD:  Yes indeed

		

as given in draft-
same or am I

---

From: Lavanya Srivatsa <[email-masked]>
Date: Fri, 7 May 2010 00:56:26 +0530

All,

While we have been discussing and debating the difference between a Section and a PST/SPME, a newer version of the mpls-tp-framework-12 seems to have come out, that now states this -

"The SPME forms an MPLS-TP Section [I-D.ietf-mpls-tp-data-plane] that carries the original LSP over this portion of a network as a client."

What I get from this is that an SPME is indeed and does form an MPLS-TP section (that is an underlying server LSP). However additionally an MPLS-TP Section can also be a datalink (at the datalink level so to say).

If so, now a different question crops up in my mind - What is the need for the SPME when we have a Section? A Section, as an architectural element/construct seems to be what an SPME is and beyond. Since it is possible to do OAM/PS etc at the Section level, why have another architectural element/construct that is, in one way, if I may call it, a "subset" of another architectural element?

- Lavanya

________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Thursday, May 06, 2010 8:44 PM
To: [email-masked]; [email-masked]; Lavanya Srivatsa
Cc: MPLS TP
Subject: RE: [mpls-tp] MPLS-TP Sections vs PSTs

In principle, CC check breaks. I thought misconnectivity can be avoided as you claims by CP or MP means, before the connection is placed.
But as you say it is needed for all of which can happen at any time after a connection has been placed………….this is correct and I agree……..so why TTL is not needed as well? It can be used as additional mechanism to prevent endless loops, and other cases as well, also when CV is not used!

From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 06, 2010 6:00 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Sections vs PSTs

Is this a serious question Nurit?  A CV checks for:
-    breaks
-    mismerging
-    misconnectivity
....all of which can happern at any time after a connection has been initially placed
and it can also detect looping (at least I catered for it when I wrote Y.1711 a long time ago).

regards, neil

________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]]
Sent: 06 May 2010 15:37
To: Harrison,N,Neil,DKQ7 R; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP Sections vs PSTs
Hi Neil,
Thanks for sharing this.
One simple question. You say: “-    not use any TTL....this is obviously quite unnecessary as the CP/MP can check for no looping before placing a connection”………..if this is a valid claim, so why do we need to support a CV function?
Best regards,
Nurit

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Thursday, May 06, 2010 1:12 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Sections vs PSTs

My goodness how can we make such a simple issue so complex?  Perhaps you missed all my posts of the last few years?

MPLS as-is is unfortunately an architectural mess when considered as a stand-alone co-ps mode transport network....and in a nutshell, a proper co-ps mode transport network should:
-    be fully transparent......ignoring the full description of what transparency requires here, please simply note that multiple QoS classes per connection are a no-no in a transport network since this MUST preserve client information ordering (noting that the server transport layer must not make any judgment on urgency or, in particular, importance of client symbols)
-    only have p2p and p2mp connections
-    not use any TTL....this is obviously quite unnecessary as the CP/MP can check for no looping before placing a connection
-    not use any sublayering (this is the S bit in MPLS as-is)....not only is this unnecessary but it is downright technically wrong/dangerous...see Note
-    for sure not generate another PW co-ps mode layer network above it!!!!!
-    be able to map a binary path layer signal to a section layer physical q'ary signal..in other words be able to 'put bits on the wire' like SDH, OTN and Ethernet can

Note - There is a *very big* difference between sublayering and layering.  In the former we have a single/common layer network...in particular note this has a set of common access points (ie addressable access points of THIS singular layer network) and usually a common routing process for this layer network graph.  In the case of true layering (as indeed we need in a transport network) however none of that applies.  Each LSP in a nested set of LSPs would belong to a different layer network....so each LSP exists in a functionally disjoint DP/CP/MP network sense to other nested LSPs.  So this is not like traditional MPLS sublayering (S bit) at all.  And yet, if we are supposed to be building a transport network we MUST have layering and not sublayering...this is THE key raison d'etre for doing this.

So, to cut to the chase, S bit sublayering and PWs should not exist in MPLS-TP...so why do they still exist?  Can someone (eg the Area Directors) please explain why IETF continue to make this rather obvious technical error?

Aside=> If you need a technical (political?) way-out then simply say 'MPLS-TP is NOT a transport network (which is obviously true anyway IMO) but is a type of MPLS as-is where we have taken the CP/MP OOB and banned merging'....this is at least some very useful technical progress.

regards, Neil

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 05 May 2010 22:00
To: Lavanya Srivatsa
Cc: MPLS TP
Subject: Re: [mpls-tp] MPLS-TP Sections vs PSTs
Dear Lavaya,
thank you for your questions as you've prompted me to clear my understanding of the subject.
Since a PST is an LSP in itself, it might be seen by n+1 layer of MPLS-TP as a Section. that might be either in Segment protection or OAM cases.
To your second  question, if PST is viewed as a Section, the GAL will be BoS though the appropriate LSEs of the PST will be applied as well.

Regards,
Greg
On Wed, May 5, 2010 at 12:48 PM, Lavanya Srivatsa <[email-masked]<mailto:[email-masked]>> wrote:
John, Sasha,

- Lavanya
From: John E Drake [[email-masked]<mailto:[email-masked]>]

> From: Alexander Vainshtein [mailto:[email-masked]<mailto:[email-masked]>]

JD:  Yes indeed

> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of
> Lavanya Srivatsa [[email-masked]<mailto:[email-masked]>]
> wherein it was stated as follows in section 4.2.1.2<http://4.2.1.2>: "With regard to the
> From: John E Drake [[email-masked]<mailto:[email-masked]>]
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf
> > Of Lavanya Srivatsa
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Dan Frost <[email-masked]>
Date: Thu, 6 May 2010 21:59:03 +0100

Hi Lavanya,

On Fri, May 07, 2010 at 12:56:26AM +0530, Lavanya Srivatsa wrote:
> [...]
> If so, now a different question crops up in my mind - What is the need
> for the SPME when we have a Section? A Section, as an architectural
> element/construct seems to be what an SPME is and beyond. Since it is
> possible to do OAM/PS etc at the Section level, why have another
> architectural element/construct that is, in one way, if I may call it,
> a "subset" of another architectural element?

To prevent confusion, forget SPMEs for a moment and just think about
LSPs, which you already understand.  Now bring in the definition of
"section" from draft-ietf-mpls-tp-data-plane, which put very simply is
either a data-link or an LSP.  (An LSP is considered a section relative
to a higher-layer LSP that uses it as a link.)  Pretty simple, right?

These (along with pseudowires) are the basic data plane constructs in
MPLS-TP, and even sections are really just data-links or LSPs.

Now, an SPME is nothing more nor less than an LSP instantiated for a
particular purpose: if, per Section 3.13 of the Framework, you
instantiate an LSP in order to "monitor, protect or manage" a portion of
another LSP, you can call it an SPME.  Or, if you prefer, you can just
call it an LSP.  The only reason for introducing the term at all is that
some people wanted to have a special name for LSPs that are used for
this specific purpose.

Cheers,

-d

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 21:51:04 -0400

Sasha,

The concepts are not new.  In IP/MPLS we have long recognized physical
links where each end is an interface.  In IP/MPLS the term virtual
interface (VIF) is widely recognized and can be each end of an LSP or
a channel on a channelized interface, or ATM VC, etc.  The transport
world prefers to call the "link" a section.

This yields the notion that a section in one layer may be a trail in a
layer below it.  Section implies that some layer below provides what
looks like a physical link whether it is a physical link or not.

John's statement "a section is just a link" doesn't quire resonate
because while in IP/MPLS a VIF is widely recongized, an LSP is never
referred to as a virtual link.  RFC3209 does use trunk in that sense
but that term never really caught on and tunnel is almost right but
tunnel isn't used in TDM to describe a channel or ATM to describe a
VC.

We'll all manage to communicate at some point.  The terms aren't all
that messy.

As to GAL and G-ACh, it work if the underlying section was an LSP
rather than a physical link and still works for a physical link.  It
is link layer independent.

Curtis

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

--===============1892339439==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_A3C5DF08D38B6049839A6F553B331C76C109E5E448ILPTMAIL02eci_"

--_000_A3C5DF08D38B6049839A6F553B331C76C109E5E448ILPTMAIL02eci_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Lavania, John and all,
This thread  looks to me like one more indicator of the somewhat messy noti=
ons we try to use in MPLS-TP.

For the reasons beyond my understanding, the transport people want to treat=
 a regular data link as an LSP with stack depth 0. IMO this results in gene=
ral confusion.

The Editors of the MPLS-TP data plane draft have promised to add a clarific=
ation that would explain the data links are different from "real LSP" Secti=
ons, because data links have their own methods for identifying "network lay=
er" protocols. (In particular, MPLS-TP packets are identified as labeled pa=
ckets using these methods:-).

Do we really need to carry Management and Control plane traffic over data l=
ink sections using GAL and G-ACh, or could we go on carrying them directly =
over the data links as it is done today?
My 2c,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lava=
nya Srivatsa [[email-masked]]
Sent: Tuesday, May 04, 2010 10:21 PM
To: John E Drake; MPLS TP
Subject: Re: [mpls-tp] MPLS-TP Sections vs PSTs

John,

Thanks.

I got the same impression that an MPLS-TP Section referred to a link, based=
 on what I read in the draft-ietf-mpls-tp-identifiers-01 draft, wherein it =
was stated as follows in section 4.2.1.2: "With regard to the MPLS Section,=
 a G-ACh exists between A and Z. Only A and Z can insert, extract, or proce=
ss packets on this G-ACh. The following figure (Figure 8) depicts the forma=
t of a G-ACh packet when used for an MPLS Section.  The GAL MAY provide the=
 exception mechanism for a control channel in its own right without being  =
  associated with a specific LSP, thus providing maintenance-related commun=
ications across a specific link interconnecting two LSRs.  In this case, th=
e GAL is the only label in the stack."

However, what confused me and led me to think that an MPLS-TP Section seeme=
d to be the same as a PST is the definition of an MPLS-TP Section that I fo=
und in the draft-ietf-mpls-tp-data-plane-02 draft (which is referred to by =
the MPLS-TP framework draft for the definition of the Section). This states=
 as follows in section 3.2:

"Two MPLS-TP LSRs are considered to be topologically adjacent at a particul=
ar layer n >=3D 0 of the MPLS-TP LSP hierarchy if there exists connectivity=
 between them at the next lowest network layer.  Such connectivity, if it e=
xists, will be either an MPLS-TP LSP (if n > 0) or a data-link provided by =
the underlying server layer network (if n =3D 0), and is referred to as an =
MPLS-TP Section at layer n of the MPLS-TP LSP hierarchy.  Thus, the links t=
raversed by a layer n+1 MPLS-TP LSP are layer n MPLS-TP sections.  Such an =
LSP is referred to as a client of the section layer, and the section layer =
as the server layer with respect to its clients."

I think there is an inconsistency in the above paragraph with respect to wh=
at the "layer n" refers to (which I have raised in a separate mail to the g=
roup). But that apart, from the above, I get the feeling that only the "dat=
a-link provided by the underlying server layer network (if n=3D0)" case see=
ms to refer to a link. However the n>0 case seems to refer to a Section as =
an underlying LSP (server layer), which to me, in one sense, seems similar =
to the definition of a Path Segment Tunnel (hierarchical LSP) and is not in=
 sync with the definition of a Section as simply a link.

Relevant Draft Authors,

- Lavanya

Lavanya,

A section is what anyone in the IETF would term a link.  For some reason it=
 was deemed necessary to have another term.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]] On Behal=
f
> Reading through the definition of MPLS-TP Sections as given in draft-ietf=
-
> definition to that of a Path Segment Tunnel construct given in draft-ietf=
-
> architecture or behaviour/functionality?

--_000_A3C5DF08D38B6049839A6F553B331C76C109E5E448ILPTMAIL02eci_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style title=3D"owaParaStyle"><!--P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
<meta content=3D"MSHTML 6.00.6000.17023" name=3D"GENERATOR">
<style id=3D"owaTempEditStyle"></style>
</head>
<body ocsi=3D"x">
<div style=3D"FONT-SIZE: 16px; COLOR: #000000; DIRECTION: ltr; FONT-FAMILY:=
 Times New Roman">
<div><a></a>Lavania<a></a>, John and all,</div>
<div><font face=3D"times new roman">This thread&nbsp; looks to me like one =
more indicator of the somewhat messy&nbsp;notions<a></a> we try to use in M=
PLS-TP.</font></div>
<div><font face=3D"times new roman"></font>&nbsp;</div>
<div><font face=3D"times new roman">For the reasons&nbsp;beyond<a></a> my u=
nderstanding, the transport people want to treat a regular data link as an =
LSP with stack depth 0.&nbsp;IMO this results in&nbsp;general confusion.</f=
ont></div>
<div>&nbsp;</div>
<div><font face=3D"times new roman">The Editors of the MPLS-TP data plane d=
raft have promised to add a clarification that would explain the data links=
 are different from &quot;real LSP&quot;&nbsp;Sections, because data links =
have their own methods for identifying &quot;network layer&quot;
 protocols. (In particular, MPLS-TP packets are identified as labeled&nbsp;=
packets<a></a> using these methods:-).</font></div>
<div>&nbsp;</div>
<div>One &nbsp;question that IMO is worth asking is the following: </div>
<div><font face=3D"times new roman"></font>&nbsp;</div>
<blockquote dir=3D"ltr" style=3D"MARGIN-RIGHT: 0px">
<div>Do we really need to carry&nbsp;Management<a></a> and&nbsp;Control<a><=
/a> plane traffic over data link sections using GAL and G-ACh<a></a><a></a>=
, or could we go on carrying them directly over the data links as it is don=
e today?</div>
</blockquote>
<div><font face=3D"times new roman">My 2c,</font></div>
<div><font face=3D"times new roman">&nbsp;&nbsp;&nbsp;&nbsp; Sasha</font></=
div>
<div><font face=3D"times new roman"></font>&nbsp;</div>
<div dir=3D"ltr"><font face=3D"Times New Roman" color=3D"#000000" size=3D"3=
"></font>&nbsp;</div>
<div id=3D"divRpF854133" style=3D"DIRECTION: ltr">
<hr tabindex=3D"-1">
<font face=3D"Tahoma" color=3D"#000000" size=3D"2"><b>From:</b> mpls-tp-bou=
[email-masked] [[email-masked]] On Behalf Of Lavanya Srivatsa [lav=
[email-masked]]<br>
<b>Sent:</b> Tuesday, May 04, 2010 10:21 PM<br>
<b>To:</b> John E Drake; MPLS TP<br>
<b>Subject:</b> Re: [mpls-tp] MPLS-TP Sections vs PSTs<br>
</font><br>
</div>
<div></div>
<div>
<p>John,</p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><font face=3D"times new roman">Thanks.</font></p>
<p><font face=3D"times new roman"></font><br>
I got the same impression that an MPLS-TP Section referred to a link, based=
 on what I read in the draft-ietf-mpls-tp-identifiers-01 draft, wherein it =
was stated as follows in section 4.2.1.2: &quot;<strong>With regard to the =
MPLS Section</strong>, a G-ACh exists
 between A and Z. Only A and Z can insert, extract, or process packets on t=
his G-ACh. The following figure (Figure 8) depicts the format of a G-ACh pa=
cket when used for an MPLS Section.&nbsp; The GAL MAY provide the exception=
 mechanism for a control channel in its
 own right without being&nbsp;&nbsp;&nbsp; associated with a specific LSP, =
thus providing maintenance-related communications
<strong>across a specific link interconnecting two LSRs</strong>.&nbsp; In =
this case, the GAL is the only label in the stack.&quot;</p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><font face=3D"times new roman">However, what confused me and led me to t=
hink that an MPLS-TP Section seemed to be the same as a PST is the definiti=
on of an MPLS-TP Section that I found in the draft-ietf-mpls-tp-data-plane-=
02 draft (which is referred to by
 the MPLS-TP framework draft for the definition of the Section). This state=
s as follows in section 3.2:
</font></p>
<p><font face=3D"times new roman">&quot;Two MPLS-TP LSRs are considered to =
be topologically adjacent at a&nbsp;particular layer n &gt;=3D 0 of the MPL=
S-TP LSP hierarchy if there exists&nbsp;connectivity between them at the ne=
xt lowest network layer.&nbsp; Such&nbsp;connectivity, if it exists,
 will be <strong>either an MPLS-TP LSP (if n &gt; 0)</strong>&nbsp;or a <st=
rong>data-link provided by the underlying server layer network (if n&nbsp;=
=3D 0)</strong>, and is referred to as an
<strong>MPLS-TP Section</strong> at layer n of the&nbsp;MPLS-TP LSP hierarc=
hy.&nbsp; Thus, the links traversed by a layer n&#43;1&nbsp;MPLS-TP LSP are=
 layer n MPLS-TP sections.&nbsp; Such an LSP is referred to as a client of =
the section layer, and the section layer as the server&nbsp;layer
 with respect to its clients.&quot;</font></p>
<p>&nbsp;</p>
<p><font face=3D"times new roman">I think there is an inconsistency in the =
above paragraph with respect to what the &quot;layer n&quot; refers to (whi=
ch I have raised in a separate mail to the group). But that apart, from the=
 above, I get the feeling that only the &quot;data-link
 provided by the underlying server layer network (if n=3D0)&quot; case seem=
s to refer to a link. However
<strong>the n&gt;0 case seems to refer to a Section as an underlying LSP (s=
erver layer)</strong>, which to me, in one sense, seems similar to the defi=
nition of a Path Segment Tunnel (hierarchical LSP) and is not in sync with =
the definition of a Section as simply
 a link.</font><br>
<br>
Would appreciate thoughts/comments on this.</p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><font face=3D"times new roman">Relevant Draft Authors,</font></p>
<p><font face=3D"times new roman">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Could you help with some clarificatio=
ns on the above?</font></p>
<p><font face=3D"times new roman"></font>&nbsp;</p>
<p><font face=3D"times new roman">- Lavanya</font></p>
<p><br>
________________________________________<br>
From: John E Drake [[email-masked]]<br>
Sent: Monday, May 03, 2010 9:15 PM<br>
To: Lavanya Srivatsa; MPLS TP<br>
Subject: RE: MPLS-TP Sections vs PSTs<br>
<br>
Lavanya,<br>
<br>
A section is what anyone in the IETF would term a link.&nbsp; For some reas=
on it was deemed necessary to have another term.<br>
<br>
Thanks,<br>
<br>
John<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: [email-masked] [mailto:[email-masked]] On Be=
half<br>
&gt; Of Lavanya Srivatsa<br>
&gt; Sent: Monday, May 03, 2010 8:25 AM<br>
&gt; To: MPLS TP<br>
&gt; Subject: [mpls-tp] MPLS-TP Sections vs PSTs<br>
&gt;<br>
&gt; Hello TP-group,<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Reading through the definition of MPLS-TP Sections as given in draft-i=
etf-<br>
&gt; mpls-tp-data-plan-01 (Section 3.2), this seems to refer to the lower<b=
r>
&gt; layer/level of a hierarchical LSP. This looks to be very similar in<br=
&gt; definition to that of a Path Segment Tunnel construct given in draft-i=
etf-<br>
&gt; mpls-tp-framework-11 (Section 3.13).<br>
&gt;<br>
&gt; So are MPLS-TP Sections and Path Segment Tunnels the same or am I miss=
ing<br>
&gt; something here? If so, what is the difference between the two in their=
<br>
&gt; architecture or behaviour/functionality?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; - Lavanya</p>
</div>
</div>
</body>
</html>

--_000_A3C5DF08D38B6049839A6F553B331C76C109E5E448ILPTMAIL02eci_--

--===============1892339439==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============1892339439==--

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 22:21:53 -0400

The confusion may be due to the fact that a segment does not have a
label of its own but the protection for that segment adds a label to
the stack.  This can confuse people who think that layer N in the
dataplane framework always has N labels on the stack.  Segement
protection in this sense is a lot like FRR where the protect path has
one more label, except that FRR is usually used with PHP so at the
merge point in FRR the exact same number of labels appears.  Of course
if you did PHP then you would not have counters at the egress of the
protect LSP.  That is the nature of segment protection.

I was sort of joking in defining a segment as a single hop unsignaled
LSP where PHP is used.  It is the only case where PHP is used in
MPLS-TP and that is where the difference in stack depth results.

Curtis

In message <[email-masked]>
John E Drake writes:

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 22:30:48 -0400

In message <003f01caeceb$7c28d180$0601a8c0@allison>
"tom.petch" writes:

Tunnels such as MPLS and GRE are allowed for in the IAB definition.
By that definition IETF link and ITU segment are synonumous.

IETF just doesn't make such a fuss about it (until ITU people show up
and mess up the clear and simple terminology and add lots of TLAs).
:-)

Curtis

----- Original Message -----
From: "John E Drake" <[email-masked]>
To: "Lavanya Srivatsa" <[email-masked]>; "MPLS TP"
<[email-masked]>

John

Tom Petch.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 22:48:25 -0400

Neil,

Fascinating how badly we've messed up layering (in your view).
Completely pointless, but still fascinating.

:-)

OK so (link == segment) where link or segment can be a physical link
but also could be any form of tunnel (GRE, LSP, ATM VC, TDM, etc).  In
this case MPLS tunnel (ther thing identified by a Tunnel ID in the
Session LSP_Tunnel Object) fits this use of tunnel (but not quite when
we consider protection and define a "protected link").

Lets move on.

Curtis

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

This is a multi-part message in MIME format.

--===============0568121615==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CAEC9F.EFBB0A5D"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAEC9F.EFBB0A5D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

missed all my posts of the last few years? =20
=20
=20
=20
technical error? =20
=20
Aside=3D> If you need a technical (political?) way-out then simply say
=20
regards, Neil

=09
=09
=09
=09
=09
=09

		John, Sasha,
	=09
	=09
	=09
	=09
	=09

		- Lavanya
	=09
	=09
	=09
the somewhat messy
		> treat a regular data link as an LSP with stack depth
0. IMO this results
	=09
		JD:  Yes indeed
	=09
		> as labeled packets using these methods:-).
	=09
	=09
		> directly over the data links as it is done today?
	=09
	=09
		> particular layer n >=3D 0 of the MPLS-TP LSP hierarchy
if there exists
		> data-link provided by the underlying server layer
network (if n =3D 0), and
		> the "data-link provided by the underlying server layer
network (if n=3D0)"
as given in draft-
same or am I
	=09

------_=_NextPart_001_01CAEC9F.EFBB0A5D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3660" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D126203221-05052010><FONT=20
face=3D"Comic Sans MS" color=3D#800000>My goodness how can we make such =
a simple=20
issue so complex?&nbsp; Perhaps you missed all my posts of the last few=20
years?&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D126203221-05052010><FONT=20
face=3D"Comic Sans MS" color=3D#800000></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans =
MS"=20
color=3D#800000>MPLS&nbsp;as-is&nbsp;is&nbsp;<SPAN=20
class=3D126203221-05052010>unfortunately&nbsp;an architectural=20
</SPAN>mess&nbsp;when&nbsp;considered&nbsp;as&nbsp;a&nbsp;stand-a<SPAN=20
class=3D126203221-05052010>lone </SPAN>co-<SPAN=20
class=3D126203221-05052010>ps</SPAN>&nbsp;mode&nbsp;transport&nbsp;networ=
k....<SPAN=20
class=3D126203221-05052010>and=20
</SPAN>in&nbsp;a&nbsp;nutshell,&nbsp;a&nbsp;proper&nbsp;co-ps&nbsp;mode&n=
bsp;tra<SPAN=20
class=3D126203221-05052010>n</SPAN>sport&nbsp;network&nbsp;should:</FONT>=
</DIV>
<DIV><SPAN class=3D126203221-05052010></SPAN><SPAN=20
class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans MS"><FONT=20
color=3D#800000>-<SPAN class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; be =
fully=20
transparent......ignoring the full description of what transparency =
requires=20
here, please simply note that multiple QoS classes per connection are a =
no-no in=20
a transport network since this MUST preserve client information ordering =
(noting=20
that the server transport layer must not make any judgment on urgency =
or, in=20
particular, importance of client symbols)</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D126203221-05052010></SPAN><SPAN=20
class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans MS"><FONT=20
color=3D#800000>-<SPAN class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; =
only have p2p=20
and p2mp connections</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D126203221-05052010></SPAN><SPAN=20
class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans MS"><FONT=20
color=3D#800000>-<SPAN class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; not =
use any=20
TTL....this is obviously quite unnecessary as the CP/MP can check for no =
looping=20
before placing a connection</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D126203221-05052010></SPAN><SPAN=20
class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans MS"><FONT=20
color=3D#800000>-<SPAN class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; not =
use any=20
sublayering (this is the S bit in MPLS as-is)....not only is this =
unnecessary=20
but it is downright technically wrong/dangerous...see=20
Note</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D126203221-05052010></SPAN><SPAN=20
class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans MS"><FONT=20
color=3D#800000>-<SPAN class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; for =
sure not=20
generate another PW co-ps mode layer network above=20
it!!!!!</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D126203221-05052010></SPAN><SPAN=20
class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans MS"><FONT=20
color=3D#800000>-<SPAN class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; be =
able to map=20
a binary path layer signal to a section layer physical q'ary signal..in =
other=20
words be able to 'put bits on the wire' like SDH, OTN and Ethernet=20
can</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010>Note - There is a *very big* difference =
between=20
sublayering and layering.&nbsp; In the former we have a single/common =
layer=20
network...in particular note this has a set of common access points (ie=20
addressable access points of THIS singular layer network) and usually a =
common=20
routing process for this layer network graph.&nbsp; In the case of true =
layering=20
(as&nbsp;indeed we need in a transport network) however none of that=20
applies.&nbsp; Each LSP in a nested set of LSPs would belong to a =
different=20
layer network....so each LSP exists in a functionally disjoint DP/CP/MP =
network=20
sense to other nested LSPs.&nbsp; So this is not like traditional MPLS=20
sublayering (S bit) at all.&nbsp; And yet,&nbsp;if we are supposed to be =

building a transport network we MUST have layering and not =
sublayering...this is=20
THE key raison d'etre for doing this.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010>So, to cut to the chase, S bit sublayering =
and PWs=20
should not exist in MPLS-TP...so why&nbsp;do they still exist?&nbsp; Can =
someone=20
(eg the Area Directors) please explain why IETF continue to make this =
rather=20
obvious technical error?&nbsp; </SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010>Aside=3D&gt; If you need a technical =
(political?) way-out=20
then simply say 'MPLS-TP is NOT a transport network (which is obviously =
true=20
anyway IMO) but is&nbsp;a type of MPLS as-is where we have taken the =
CP/MP OOB=20
and banned merging'....this is at least some very useful technical=20
progress.</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20
class=3D126203221-05052010>regards, Neil</SPAN></FONT></FONT></DIV>
<DIV><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Greg=20
  Mirsky<BR><B>Sent:</B> 05 May 2010 22:00<BR><B>To:</B> Lavanya=20
  Srivatsa<BR><B>Cc:</B> MPLS TP<BR><B>Subject:</B> Re: [mpls-tp] =
MPLS-TP=20
  Sections vs PSTs<BR></FONT><BR></DIV>
  <DIV></DIV>Dear Lavaya,<BR>thank you for your questions as you've =
prompted me=20
  to clear my understanding of the subject.<BR>Since a PST is an LSP in =
itself,=20
  it might be seen by n+1 layer of MPLS-TP as a Section. that might be =
either in=20
  Segment protection or OAM cases.<BR>To your second&nbsp; question, if =
PST is=20
  viewed as a Section, the GAL will be BoS though the appropriate LSEs =
of the=20
  PST will be applied as well.<BR><BR>Regards,<BR>Greg<BR><BR>
  <DIV class=3Dgmail_quote>On Wed, May 5, 2010 at 12:48 PM, Lavanya =
Srivatsa <SPAN=20
  dir=3Dltr>&lt;<A=20
  =
href=3D"mailto:[email-masked]">[email-masked]=
</A>&gt;</SPAN>=20
  wrote:<BR>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">John,=20
    Sasha,<BR><BR>Based on Sasha's comment about "real LSP" Sections and =

    Stewart's response/clarification in the other mail thread about the=20
    confusing definition/text in the data-plane draft for an MPLS-TP =
Section, it=20
    seems clear that a Section could be a data link OR an (underlying) =
LSP for a=20
    client LSP above it.<BR><BR>So I am repeating my question here - =
what then,=20
    is the difference between a Section and a PST (now termed SPME)? =
Both=20
    are/can be, in one sense, lower layer/LSP in a hierarchical LSPs=20
    setup.<BR><BR>Also, when RFC 5654 (sorry I had misquoted at the=20
    tp-identifiers draft in my earlier mail) states only a GAL would be=20
    sufficient for a packet carried on a Section, how would this be =
correct if=20
    the Section were an (underlying) LSP and not a data link?<BR><BR>Can =
you=20
    confirm what is correct here?<BR>
    <DIV class=3Dim><BR>-=20
    Lavanya<BR>________________________________________<BR>From: John E =
Drake=20
    [<A =
href=3D"mailto:[email-masked]">[email-masked]</A>]<BR></DIV>Sent:=
=20
    Wednesday, May 05, 2010 3:26 AM<BR>To: Alexander Vainshtein; Lavanya =

    Srivatsa<BR>
    <DIV>
    <DIV></DIV>
    <DIV class=3Dh5>Cc: MPLS TP<BR>Subject: RE: MPLS-TP Sections vs=20
    PSTs<BR><BR>&gt; -----Original Message-----<BR>&gt; From: Alexander=20
    Vainshtein [mailto:<A=20
    =
href=3D"mailto:[email-masked]">Alexander.Vainshtein@eci=
tele.com</A>]<BR>&gt;=20
    Sent: Tuesday, May 04, 2010 2:14 PM<BR>&gt; To: Lavanya Srivatsa; =
John E=20
    Drake<BR>&gt; Cc: MPLS TP<BR>&gt; Subject: RE: MPLS-TP Sections vs=20
    PSTs<BR>&gt;<BR>&gt; Lavania, John and all,<BR>&gt; This thread =
&nbsp;looks=20
    to me like one more indicator of the somewhat messy<BR>&gt; notions =
we try=20
    to use in MPLS-TP.<BR>&gt;<BR>&gt; For the reasons beyond my =
understanding,=20
    the transport people want to<BR>&gt; treat a regular data link as an =
LSP=20
    with stack depth 0. IMO this results<BR>&gt; in general=20
    confusion.<BR><BR>JD: &nbsp;Yes indeed<BR><BR>&gt;<BR>&gt; The =
Editors of=20
    the MPLS-TP data plane draft have promised to add a<BR>&gt; =
clarification=20
    that would explain the data links are different from "real<BR>&gt; =
LSP"=20
    Sections, because data links have their own methods for =
identifying<BR>&gt;=20
    "network layer" protocols. (In particular, MPLS-TP packets are=20
    identified<BR>&gt; as labeled packets using these =
methods:-).<BR><BR>JD:=20
    &nbsp;Does this mean we will be eliminating 'section' as a synonym =
for=20
    'link'?<BR><BR>&gt;<BR>&gt; One &nbsp;question that IMO is worth =
asking is=20
    the following:<BR>&gt;<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; Do we =
really=20
    need to carry Management and Control plane traffic over<BR>&gt; data =
link=20
    sections using GAL and G-ACh, or could we go on carrying =
them<BR>&gt;=20
    directly over the data links as it is done today?<BR><BR>JD: &nbsp;A =
good=20
    question. &nbsp;Another good question: &nbsp;is RFC 5718 really=20
    needed?<BR><BR>&gt;<BR>&gt; My 2c,<BR>&gt; &nbsp; &nbsp;=20
    &nbsp;Sasha<BR>&gt;<BR>&gt;<BR>&gt;=20
    ________________________________<BR>&gt;<BR>&gt; From: <A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A> =
[<A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A>] =
On=20
    Behalf Of<BR>&gt; Lavanya Srivatsa [<A=20
    =
href=3D"mailto:[email-masked]">[email-masked]=
</A>]<BR>&gt;=20
    Sent: Tuesday, May 04, 2010 10:21 PM<BR>&gt; To: John E Drake; MPLS=20
    TP<BR>&gt; Subject: Re: [mpls-tp] MPLS-TP Sections vs=20
    PSTs<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; =
John,<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;=20
    Thanks.<BR>&gt;<BR>&gt;<BR>&gt; I got the same impression that an =
MPLS-TP=20
    Section referred to a link,<BR>&gt; based on what I read in the=20
    draft-ietf-mpls-tp-identifiers-01 draft,<BR>&gt; wherein it was =
stated as=20
    follows in section <A href=3D"http://4.2.1.2" =
target=3D_blank>4.2.1.2</A>: "With=20
    regard to the<BR>&gt; MPLS Section, a G-ACh exists between A and Z. =
Only A=20
    and Z can insert,<BR>&gt; extract, or process packets on this G-ACh. =
The=20
    following figure (Figure 8)<BR>&gt; depicts the format of a G-ACh =
packet=20
    when used for an MPLS Section. &nbsp;The<BR>&gt; GAL MAY provide the =

    exception mechanism for a control channel in its own<BR>&gt; right =
without=20
    being &nbsp; &nbsp;associated with a specific LSP, thus =
providing<BR>&gt;=20
    maintenance-related communications across a specific link=20
    interconnecting<BR>&gt; two LSRs. &nbsp;In this case, the GAL is the =
only=20
    label in the stack."<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; However, what =
confused=20
    me and led me to think that an MPLS-TP Section<BR>&gt; seemed to be =
the same=20
    as a PST is the definition of an MPLS-TP Section<BR>&gt; that I =
found in the=20
    draft-ietf-mpls-tp-data-plane-02 draft (which is<BR>&gt; referred to =
by the=20
    MPLS-TP framework draft for the definition of the<BR>&gt; Section). =
This=20
    states as follows in section 3.2:<BR>&gt;<BR>&gt; "Two MPLS-TP LSRs =
are=20
    considered to be topologically adjacent at a<BR>&gt; particular =
layer n=20
    &gt;=3D 0 of the MPLS-TP LSP hierarchy if there exists<BR>&gt; =
connectivity=20
    between them at the next lowest network layer. &nbsp;Such<BR>&gt;=20
    connectivity, if it exists, will be either an MPLS-TP LSP (if n &gt; =
0) or=20
    a<BR>&gt; data-link provided by the underlying server layer network =
(if n =3D=20
    0), and<BR>&gt; is referred to as an MPLS-TP Section at layer n of =
the=20
    MPLS-TP LSP<BR>&gt; hierarchy. &nbsp;Thus, the links traversed by a =
layer=20
    n+1 MPLS-TP LSP are layer<BR>&gt; n MPLS-TP sections. &nbsp;Such an =
LSP is=20
    referred to as a client of the section<BR>&gt; layer, and the =
section layer=20
    as the server layer with respect to its<BR>&gt;=20
    clients."<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; I think there is an =
inconsistency=20
    in the above paragraph with respect to<BR>&gt; what the "layer n" =
refers to=20
    (which I have raised in a separate mail to<BR>&gt; the group). But =
that=20
    apart, from the above, I get the feeling that only<BR>&gt; the =
"data-link=20
    provided by the underlying server layer network (if n=3D0)"<BR>&gt; =
case seems=20
    to refer to a link. However the n&gt;0 case seems to refer to =
a<BR>&gt;=20
    Section as an underlying LSP (server layer), which to me, in one=20
    sense,<BR>&gt; seems similar to the definition of a Path Segment =
Tunnel=20
    (hierarchical<BR>&gt; LSP) and is not in sync with the definition of =
a=20
    Section as simply a link.<BR>&gt;<BR>&gt; Would appreciate =
thoughts/comments=20
    on this.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; Relevant Draft=20
    Authors,<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;=20
    Could you help with some clarifications on the=20
    above?<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; - =
Lavanya<BR>&gt;<BR>&gt;<BR>&gt;=20
    ________________________________________<BR>&gt; From: John E Drake =
[<A=20
    href=3D"mailto:[email-masked]">[email-masked]</A>]<BR>&gt; =
Sent:=20
    Monday, May 03, 2010 9:15 PM<BR>&gt; To: Lavanya Srivatsa; MPLS =
TP<BR>&gt;=20
    Subject: RE: MPLS-TP Sections vs PSTs<BR>&gt;<BR>&gt;=20
    Lavanya,<BR>&gt;<BR>&gt; A section is what anyone in the IETF would =
term a=20
    link. &nbsp;For some reason<BR>&gt; it was deemed necessary to have =
another=20
    term.<BR>&gt;<BR>&gt; Thanks,<BR>&gt;<BR>&gt; John<BR>&gt;<BR>&gt; =
&gt;=20
    -----Original Message-----<BR>&gt; &gt; From: <A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A>=20
    [mailto:<A=20
    =
href=3D"mailto:[email-masked]">[email-masked]</A>]=20
    On<BR>&gt; Behalf<BR>&gt; &gt; Of Lavanya Srivatsa<BR>&gt; &gt; =
Sent:=20
    Monday, May 03, 2010 8:25 AM<BR>&gt; &gt; To: MPLS TP<BR>&gt; &gt; =
Subject:=20
    [mpls-tp] MPLS-TP Sections vs PSTs<BR>&gt; &gt;<BR>&gt; &gt; Hello=20
    TP-group,<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt; =
Reading=20
    through the definition of MPLS-TP Sections as given in =
draft-<BR>&gt;=20
    ietf-<BR>&gt; &gt; mpls-tp-data-plan-01 (Section 3.2), this seems to =
refer=20
    to the lower<BR>&gt; &gt; layer/level of a hierarchical LSP. This =
looks to=20
    be very similar in<BR>&gt; &gt; definition to that of a Path Segment =
Tunnel=20
    construct given in draft-<BR>&gt; ietf-<BR>&gt; &gt; =
mpls-tp-framework-11=20
    (Section 3.13).<BR>&gt; &gt;<BR>&gt; &gt; So are MPLS-TP Sections =
and Path=20
    Segment Tunnels the same or am I<BR>&gt; missing<BR>&gt; &gt; =
something=20
    here? If so, what is the difference between the two in their<BR>&gt; =
&gt;=20
    architecture or behaviour/functionality?<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt;=20
    &gt;<BR>&gt; &gt; -=20
    =
Lavanya<BR>_______________________________________________<BR>mpls-tp=20
    mailing list<BR><A =
href=3D"mailto:[email-masked]">[email-masked]</A><BR><A=20
    href=3D"https://www.ietf.org/mailman/listinfo/mpls-tp"=20
    =
target=3D_blank>https://www.ietf.org/mailman/listinfo/mpls-tp</A><BR></DI=
V></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01CAEC9F.EFBB0A5D--

--===============0568121615==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0568121615==--

---

From: <[email-masked]>
Date: Fri, 7 May 2010 09:07:29 +0100

Quite frankly I cannot follow any of this stuff, eg the chameleon-like
definition of a what a tunnel is or what an MPLS section is.  The only
good repository of information wrt the functional modelling of networks
I know is what is in G.800.  I know the folks who wrote this stuff and I
can vouch for the effort that has gone into this in order to be as
accurate as possible.
 
One can really see just how poor/flawed the understanding of some folks
is when they talk of L1/2/3 notions that harp back to the OSI RM.  Many
of the problems that continue dog MPLS-TP came from this.
 
(Snipped after mail below because of prior warning of mail size.)
 
regards, Neil

	From: Lavanya Srivatsa [mailto:[email-masked]] 
	Sent: 06 May 2010 20:26
	To: MPLS TP; Sprecher, Nurit (NSN - IL/Hod HaSharon);
Harrison,N,Neil,DKQ7 R; [email-masked]
	Subject: RE: [mpls-tp] MPLS-TP Sections vs PSTs

	All, 
	 
	While we have been discussing and debating the difference
between a Section and a PST/SPME, a newer version of the
mpls-tp-framework-12 seems to have come out, that now states this -
	 
	"The SPME forms an MPLS-TP Section [I-D.ietf-mpls-tp-data-plane]
that carries the original LSP over this portion of a network as a
client."
	 
	What I get from this is that an SPME is indeed and does form an
MPLS-TP section (that is an underlying server LSP). However additionally
an MPLS-TP Section can also be a datalink (at the datalink level so to
say).
	 
	If so, now a different question crops up in my mind - What is
the need for the SPME when we have a Section? A Section, as an
architectural element/construct seems to be what an SPME is and beyond.
Since it is possible to do OAM/PS etc at the Section level, why have
another architectural element/construct that is, in one way, if I may
call it, a "subset" of another architectural element? 
	 
	- Lavanya

---

From: <[email-masked]>
Date: Fri, 7 May 2010 09:27:23 +0100

Hmmm...two questions for you Curtis:

1	why are we bothering with MPLS-TP....what is *technically* wrong
with MPLS as-is that requires this effort? 

2	why have we technically never managed to achieve the common CP
running IP to Optics that was touted a decade ago?

The answers lie in a proper understanding of networks that you clearly
dismiss as unimportant (ie 'let's move on')
 
regards, neil

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 07 May 2010 03:48
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> OK so (link == segment) where link or segment can be a 
> physical link but also could be any form of tunnel (GRE, LSP, 
> ATM VC, TDM, etc).  In this case MPLS tunnel (ther thing 
> identified by a Tunnel ID in the Session LSP_Tunnel Object) 
> fits this use of tunnel (but not quite when we consider 
> protection and define a "protected link").
> 
> Lets move on.
> 
> Curtis
> 
> 
> In message 
> <[email-masked]
> .systemhost.net>
> Perhaps you missed all my posts of the last few years? =20 
> =20 MPLS as-is is unfortunately an architectural mess when 
> considered as a stand-alone co-ps mode transport 
> network....and in a nutshell, a proper co-ps mode transport 
> network should:
> transparency requires here, please simply note that multiple 
> QoS classes per connection are a no-no in a transport network 
> since this MUST preserve client information ordering (noting 
> that the server transport layer must not make any judgment on 
> urgency or, in particular, importance of client symbols)
> Note - There is a *very big* difference between sublayering 
> and layering.  In the former we have a single/common layer 
> network...in particular note this has a set of common access 
> points (ie addressable access points of THIS singular layer 
> network) and usually a common routing process for this layer 
> network graph.  In the case of true layering (as indeed we 
> need in a transport network) however none of that applies.  
> Each LSP in a nested set of LSPs would belong to a different 
> layer network....so each LSP exists in a functionally 
> disjoint DP/CP/MP network sense to other nested LSPs.  So 
> this is not like traditional MPLS sublayering (S bit) at all. 
>  And yet, if we are supposed to be building a transport 
> network we MUST have layering and not sublayering...this is 
> THE key raison d'etre for doing this.
> =20
> Directors) please explain why IETF continue to make this 
> rather obvious technical error? =20 =20 Aside=3D> If you need 
> a technical (political?) way-out then simply say 'MPLS-TP is 
> NOT a transport network (which is obviously true anyway IMO) 
> but is a type of MPLS as-is where we have taken the CP/MP OOB 
> and banned merging'....this is at least some very useful 
> technical progress.
> =20
> regards, Neil
> 
> 
> 	Since a PST is an LSP in itself, it might be seen by 
> n+1 layer of MPLS-TP as a Section. that might be either in 
> Segment protection or OAM cases.
> 	To your second  question, if PST is viewed as a 
> Section, the GAL will be BoS though the appropriate LSEs of 
> the PST will be applied as well.
> =09
> 	Regards,
> 	Greg
> =09
> =09
> 		Based on Sasha's comment about "real LSP" 
> Sections and Stewart's response/clarification in the other 
> mail thread about the confusing definition/text in the 
> data-plane draft for an MPLS-TP Section, it seems clear that 
> a Section could be a data link OR an
> 		So I am repeating my question here - what then, 
> is the difference between a Section and a PST (now termed 
> SPME)? Both are/can be, in one sense, lower layer/LSP in a 
> hierarchical LSPs setup.
> 	=09
> 		Also, when RFC 5654 (sorry I had misquoted at 
> the tp-identifiers draft in my earlier mail) states only a 
> GAL would be sufficient for a packet carried on a Section, 
> how would this be correct if the Section were an (underlying) 
> LSP and not a data link?
> 	=09
> 		> This thread  looks to me like one more 
> indicator of the somewhat messy
> 		> that I found in the 
> draft-ietf-mpls-tp-data-plane-02 draft (which is
> 		> particular layer n >=3D 0 of the MPLS-TP LSP 
> hierarchy if there exists
> 		> data-link provided by the underlying server 
> layer network (if n =3D 0), and
> 		> the "data-link provided by the underlying 
> server layer network (if n=3D0)"
> 		> > Reading through the definition of MPLS-TP 
> Sections as given in draft-
> 		> ietf-
> 		> > So are MPLS-TP Sections and Path Segment 
> Tunnels the same or am I
> 		> missing
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 
> Transitional//EN"> <HTML><HEAD> <META 
> http-equiv=3DContent-Type content=3D"text/html; = 
> charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3660" 
> name=3DGENERATOR></HEAD> <BODY> <DIV dir=3Dltr 
> align=3Dleft><SPAN class=3D126203221-05052010><FONT=20
> face=3D"Comic Sans MS" color=3D#800000>My goodness how can we 
> make such = a simple=20 issue so complex?&nbsp; Perhaps you 
> missed all my posts of the last few=20 
> <DIV><SPAN class=3D126203221-05052010></SPAN><FONT 
> face=3D"Comic Sans = MS"=20 
> class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans 
> MS"><FONT=20 color=3D#800000>-<SPAN 
> class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; be = fully=20 
> transparent......ignoring the full description of what 
> transparency = requires=20 here, please simply note that 
> multiple QoS classes per connection are a = no-no in=20 a 
> transport network since this MUST preserve client information 
> ordering = (noting=20 that the server transport layer must 
> not make any judgment on urgency = or, in=20 particular, 
> importance of client symbols)</SPAN></FONT></FONT></DIV>
> class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans 
> MS"><FONT=20 color=3D#800000>-<SPAN 
> class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; = only have 
> p2p=20 and p2mp connections</SPAN></FONT></FONT></DIV>
> class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans 
> MS"><FONT=20 color=3D#800000>-<SPAN 
> class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; not = use 
> any=20 TTL....this is obviously quite unnecessary as the 
> CP/MP can check for no = looping=20 before placing a 
> connection</SPAN></FONT></FONT></DIV>
> class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans 
> MS"><FONT=20 color=3D#800000>-<SPAN 
> class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; not = use 
> any=20 sublayering (this is the S bit in MPLS as-is)....not 
> only is this = unnecessary=20 but it is downright technically 
> wrong/dangerous...see=20 Note</SPAN></FONT></FONT></DIV> 
> class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans 
> MS"><FONT=20 color=3D#800000>-<SPAN 
> class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; for = sure 
> not=20 generate another PW co-ps mode layer network above=20 
> class=3D126203221-05052010></SPAN><FONT face=3D"Comic Sans 
> MS"><FONT=20 color=3D#800000>-<SPAN 
> class=3D126203221-05052010>&nbsp;&nbsp;&nbsp; be = able to 
> map=20 a binary path layer signal to a section layer physical 
> q'ary signal..in = other=20 words be able to 'put bits on the 
> wire' like SDH, OTN and Ethernet=20 
> can</SPAN></FONT></FONT></DIV> <DIV><FONT face=3D"Comic Sans 
> MS"><FONT color=3D#800000><SPAN=20 
> <DIV><FONT face=3D"Comic Sans MS"><FONT 
> color=3D#800000><SPAN=20 class=3D126203221-05052010>Note - 
> There is a *very big* difference = between=20 sublayering and 
> layering.&nbsp; In the former we have a single/common = 
> layer=20 network...in particular note this has a set of 
> common access points (ie=20 addressable access points of THIS 
> singular layer network) and usually a = common=20 routing 
> process for this layer network graph.&nbsp; In the case of 
> true = layering=20 (as&nbsp;indeed we need in a transport 
> network) however none of that=20 applies.&nbsp; Each LSP in a 
> nested set of LSPs would belong to a = different=20 layer 
> network....so each LSP exists in a functionally disjoint 
> DP/CP/MP = network=20 sense to other nested LSPs.&nbsp; So 
> this is not like traditional MPLS=20 sublayering (S bit) at 
> all.&nbsp; And yet,&nbsp;if we are supposed to be =
> 
> sublayering...this is=20 THE key raison d'etre for doing 
> this.</SPAN></FONT></FONT></DIV> <DIV><FONT face=3D"Comic 
> Sans MS"><FONT color=3D#800000><SPAN=20 
> <DIV><FONT face=3D"Comic Sans MS"><FONT 
> color=3D#800000><SPAN=20 class=3D126203221-05052010>So, to 
> cut to the chase, S bit sublayering = and PWs=20 should not 
> exist in MPLS-TP...so why&nbsp;do they still exist?&nbsp; Can 
> = someone=20 (eg the Area Directors) please explain why IETF 
> continue to make this = rather=20 obvious technical 
> error?&nbsp; </SPAN></FONT></FONT></DIV> <DIV><FONT 
> face=3D"Comic Sans MS"><FONT color=3D#800000><SPAN=20 
> then simply say 'MPLS-TP is NOT a transport network (which is 
> obviously = true=20 anyway IMO) but is&nbsp;a type of MPLS 
> as-is where we have taken the = CP/MP OOB=20 and banned 
> merging'....this is at least some very useful technical=20 
> <DIV><FONT face=3D"Comic Sans MS"><FONT 
> color=3D#800000><SPAN=20 class=3D126203221-05052010>regards, 
> Neil</SPAN></FONT></FONT></DIV> <DIV><BR></DIV> <BLOCKQUOTE=20
> style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: 
> #800000 2px = solid; MARGIN-RIGHT: 0px">
>   Srivatsa<BR><B>Cc:</B> MPLS TP<BR><B>Subject:</B> Re: 
> [mpls-tp] = MPLS-TP=20
>   <DIV></DIV>Dear Lavaya,<BR>thank you for your questions as 
> you've = prompted me=20
>   to clear my understanding of the subject.<BR>Since a PST is 
> an LSP in = itself,=20
>   it might be seen by n+1 layer of MPLS-TP as a Section. that 
> might be = either in=20
>   Segment protection or OAM cases.<BR>To your second&nbsp; 
> question, if = PST is=20
>   viewed as a Section, the GAL will be BoS though the 
> appropriate LSEs = of the=20
>   <DIV class=3Dgmail_quote>On Wed, May 5, 2010 at 12:48 PM, 
> Lavanya = Srivatsa <SPAN=20
>   dir=3Dltr>&lt;<A=20
>   =
>     confusing definition/text in the data-plane draft for an 
> MPLS-TP = Section, it=20
>     seems clear that a Section could be a data link OR an 
> (underlying) = LSP for a=20
>     client LSP above it.<BR><BR>So I am repeating my question 
> here - = what then,=20
>     is the difference between a Section and a PST (now termed 
> SPME)? = Both=20
>     sufficient for a packet carried on a Section, how would 
> this be = correct if=20
>     the Section were an (underlying) LSP and not a data 
> link?<BR><BR>Can = you=20
> Lavanya<BR>________________________________________<BR>From: 
> John E = Drake=20
>     [<A =
>     Sent: Tuesday, May 04, 2010 2:14 PM<BR>&gt; To: Lavanya 
> Srivatsa; = John E=20
>     PSTs<BR>&gt;<BR>&gt; Lavania, John and all,<BR>&gt; This 
> thread = &nbsp;looks=20
>     to me like one more indicator of the somewhat 
> messy<BR>&gt; notions = we try=20
>     to use in MPLS-TP.<BR>&gt;<BR>&gt; For the reasons beyond 
> my = understanding,=20
>     the transport people want to<BR>&gt; treat a regular data 
> link as an = LSP=20
>     confusion.<BR><BR>JD: &nbsp;Yes 
> indeed<BR><BR>&gt;<BR>&gt; The = Editors of=20
>     the MPLS-TP data plane draft have promised to add 
> a<BR>&gt; = clarification=20
>     that would explain the data links are different from 
> "real<BR>&gt; = LSP"=20
>     &nbsp;Does this mean we will be eliminating 'section' as 
> a synonym = for=20
>     'link'?<BR><BR>&gt;<BR>&gt; One &nbsp;question that IMO 
> is worth = asking is=20
>     the following:<BR>&gt;<BR>&gt;<BR>&gt; &nbsp; &nbsp; 
> &nbsp; Do we = really=20
>     need to carry Management and Control plane traffic 
> over<BR>&gt; data = link=20
>     sections using GAL and G-ACh, or could we go on carrying 
> = them<BR>&gt;=20
>     directly over the data links as it is done 
> today?<BR><BR>JD: &nbsp;A = good=20
> href=3D"mailto:[email-masked]">mpls-tp-bounces@ietf.
> org</A> = [<A=20
>     =
> href=3D"mailto:[email-masked]">mpls-tp-bounces@ietf.
> org</A>] = On=20
>     Thanks.<BR>&gt;<BR>&gt;<BR>&gt; I got the same impression 
> that an = MPLS-TP=20
>     draft-ietf-mpls-tp-identifiers-01 draft,<BR>&gt; wherein 
> it was = stated as=20
>     regard to the<BR>&gt; MPLS Section, a G-ACh exists 
> between A and Z. = Only A=20
>     and Z can insert,<BR>&gt; extract, or process packets on 
> this G-ACh. = The=20
>     following figure (Figure 8)<BR>&gt; depicts the format of 
> a G-ACh = packet=20
>     exception mechanism for a control channel in its 
> own<BR>&gt; right = without=20
>     interconnecting<BR>&gt; two LSRs. &nbsp;In this case, the 
> GAL is the = only=20
>     label in the stack."<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; 
> However, what = confused=20
>     me and led me to think that an MPLS-TP Section<BR>&gt; 
> seemed to be = the same=20
>     as a PST is the definition of an MPLS-TP Section<BR>&gt; 
> that I = found in the=20
>     draft-ietf-mpls-tp-data-plane-02 draft (which is<BR>&gt; 
> referred to = by the=20
>     MPLS-TP framework draft for the definition of the<BR>&gt; 
> Section). = This=20
>     states as follows in section 3.2:<BR>&gt;<BR>&gt; "Two 
> MPLS-TP LSRs = are=20
>     considered to be topologically adjacent at a<BR>&gt; 
> particular = layer n=20
>     &gt;=3D 0 of the MPLS-TP LSP hierarchy if there 
> exists<BR>&gt; = connectivity=20
>     a<BR>&gt; data-link provided by the underlying server 
> layer network = (if n =3D=20
>     0), and<BR>&gt; is referred to as an MPLS-TP Section at 
> layer n of = the=20
>     MPLS-TP LSP<BR>&gt; hierarchy. &nbsp;Thus, the links 
> traversed by a = layer=20
>     n+1 MPLS-TP LSP are layer<BR>&gt; n MPLS-TP sections. 
> &nbsp;Such an = LSP is=20
>     referred to as a client of the section<BR>&gt; layer, and 
> the = section layer=20
>     clients."<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt; I think there 
> is an = inconsistency=20
>     in the above paragraph with respect to<BR>&gt; what the 
> "layer n" = refers to=20
>     (which I have raised in a separate mail to<BR>&gt; the 
> group). But = that=20
>     apart, from the above, I get the feeling that 
> only<BR>&gt; the = "data-link=20
>     provided by the underlying server layer network (if 
> n=3D0)"<BR>&gt; = case seems=20
>     to refer to a link. However the n&gt;0 case seems to 
> refer to = a<BR>&gt;=20
>     sense,<BR>&gt; seems similar to the definition of a Path 
> Segment = Tunnel=20
>     (hierarchical<BR>&gt; LSP) and is not in sync with the 
> definition of = a=20
>     Section as simply a link.<BR>&gt;<BR>&gt; Would 
> appreciate = thoughts/comments=20
>     Authors,<BR>&gt;<BR>&gt; &nbsp; &nbsp; &nbsp; &nbsp; 
> &nbsp; &nbsp; = &nbsp;=20
>     ________________________________________<BR>&gt; From: 
> John E Drake = [<A=20
>     
> href=3D"mailto:[email-masked]">[email-masked]</A>]<BR>
> &gt; = Sent:=20
>     Monday, May 03, 2010 9:15 PM<BR>&gt; To: Lavanya 
> Srivatsa; MPLS = TP<BR>&gt;=20
>     Lavanya,<BR>&gt;<BR>&gt; A section is what anyone in the 
> IETF would = term a=20
>     link. &nbsp;For some reason<BR>&gt; it was deemed 
> necessary to have = another=20
>     term.<BR>&gt;<BR>&gt; Thanks,<BR>&gt;<BR>&gt; 
> John<BR>&gt;<BR>&gt; = &gt;=20
>     On<BR>&gt; Behalf<BR>&gt; &gt; Of Lavanya 
> Srivatsa<BR>&gt; &gt; = Sent:=20
>     Monday, May 03, 2010 8:25 AM<BR>&gt; &gt; To: MPLS 
> TP<BR>&gt; &gt; = Subject:=20
>     TP-group,<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; 
> &gt; = Reading=20
>     ietf-<BR>&gt; &gt; mpls-tp-data-plan-01 (Section 3.2), 
> this seems to = refer=20
>     to the lower<BR>&gt; &gt; layer/level of a hierarchical 
> LSP. This = looks to=20
>     be very similar in<BR>&gt; &gt; definition to that of a 
> Path Segment = Tunnel=20
>     (Section 3.13).<BR>&gt; &gt;<BR>&gt; &gt; So are MPLS-TP 
> Sections = and Path=20
>     Segment Tunnels the same or am I<BR>&gt; missing<BR>&gt; 
> &gt; = something=20
>     here? If so, what is the difference between the two in 
> their<BR>&gt; = &gt;=20
>     architecture or behaviour/functionality?<BR>&gt; 
> &gt;<BR>&gt; = &gt;<BR>&gt;=20
>     &gt;<BR>&gt; &gt; -=20
>     =

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 7 May 2010 11:24:55 +0200

Hi,

Thanks for your response.

>>>CC is not a good idea.  It comes from ATM I.610 OAM....and there is
more than simply CC >>>wrong with this OAM standard. 

                Note that CC is a function that is required in the
MPLS-TP OAM requirements. 

>>>A break is one thing but a misconnectivity event (ie connection A and
B swapped) or >>>mismerging event (eg unintended replication of
connection A traffic units into connection >>>B....connection A may see
no effect) is a much more serious thing for the affected client.

                I agree

>>>I coined the term CV because I wanted to differentiate it from the
flawed CC.  I have no >>>idea why some folks still talk about CC.

                Did you comment on this to the OAM requirement document?

	>>>NH=> You have clearly not understood what is going on
here.....the CP/MP checking for DP >>>loops before placing a connection
is a very different thing to the *DP* itself checking it >>>has correct
connectivity *after* the connection is instantiated.  I am surprised you
>>>confuse these.  If you consider the 2 exmaples I mentioned above
about swapped and >>>mismerged connections you should see that the DP/CP
will *not* see any looping at all but >>>once the DP OAM is established
(and this MUST be sync'd to connection set-up/tear->>>down please note)
then the *DP* will detect the serious misconnectivity/mismerging
>>>defects.

	Actually I do understand the functionality. MY point was just
made because you try to negate the need for TTL. 

	>>>NH=> You cannot substitute TTL for CV.  I am a little worried
you don't seem to >>>understand this.  TTL is important in cl-ps
technologies that use directed routing (as >>>opposed to brute force
topology pruning to connectivity=1, eg original Ethernet) because >>>we
don't have a parent connection.  TTL is not required at all in co-cs and
co-ps mode >>>technologies.....which is why it has never been specified
for such.  Please do not confuse >>>MPLS with properly specified co-ps
mode technologies....though to be strictly accurate it >>>is only the
LDP form of MPLS that creates this (and other) problems here.

	            I agree that we need the CV function and I
definitely do not try to substitute it. I just say that TTL is another
mechanism to ensure that if for example misconnectivity is not detected
(from some reason), the packet will not "wander " in the network
forever.

---

From: <[email-masked]>
Date: Fri, 7 May 2010 10:55:33 +0100

Thanks Nurit...additional remarks in-line where needed - the last point
is critical:

	Sent: 07 May 2010 10:25

	Hi,

	>>>CC is not a good idea.  It comes from ATM I.610 OAM....and
there is more than simply CC >>>wrong with this OAM standard. 

	                Note that CC is a function that is required in
the MPLS-TP OAM requirements.  

	NH=> Why? 

	>>>A break is one thing but a misconnectivity event (ie
connection A and B swapped) or >>>mismerging event (eg unintended
replication of connection A traffic units into connection
>>>B....connection A may see no effect) is a much more serious thing for
the affected client.

	                I agree

	>>>I coined the term CV because I wanted to differentiate it
from the flawed CC.  I have no >>>idea why some folks still talk about
CC.

	                Did you comment on this to the OAM requirement
document?  

	NH=> No.....but I assumed it was common knowledge amongst OAM
experts that CC alone is not a good idea.

>>>defects.

		Actually I do understand the functionality. MY point was
just made because you try to negate the need for TTL.  

		NH=> Well, it is just a fact.  The reason we have TTL in
the traffic unit of MPLS-TP is because with have TTL in the traffic unit
of MPLS, and we have it here because of the LDP spin of MPLS which does
NOT create connections...simple as that.  *Functionally* however TTL is
not required in co networks because we have this object called a
connection.....and see last point below for why.

		>>>NH=> You cannot substitute TTL for CV.  I am a little
worried you don't seem to >>>understand this.  TTL is important in cl-ps

		NH=>  Please remember we are dealing with a co-ps mode
network here which has proper connections.  A parent connection is a
*constraining construct* for the child traffic units it carries.  Child
traffic units cannot go walk-about in the middle of a co-ps mode network
outside of a parent connection.....this is not like a cl-ps mode
network.  And in the case of mismerging we have traffic units of one
parent connection being misdirected into another/different parent
connection...the traffic units cannot exist outside of such a parent
connection as you seem to imply. 

		 If TTL had been important for the co-ps mode we would
have seen it introduced in other co-ps mode technologies
previously....the fact it was never deemed necessary speaks volumes IMO.

		regards, Neil

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 May 2010 10:09:29 -0400

Neil,

Been away from IETF email for a while.  Sorry for the very delayed
response.  See inline.

Curtis

> with MPLS as-is that requires this effort? 

Very little but too much.  :-)  What follows is opinion but in
response to being asked.

There seem to three perspectives on MPLS-TP (not technical issues with
MPLS yet, mostly insights into motivations here):

  1.  Those who have been working with PBB/PBT and/or MPLS-TP want to
      see something that extends the reach of metro Ethernet towards
      the core.

  2.  Those that have either TDM or Ethernet or a mix in the metro and
      SONET or OTN (which are also flavors of TDM) and use traditional
      (perhaps legacy) OSS to set up "trails" (ITU speak) rather than
      use a control plain and routing protocols (which have been
      proven over and over to be more rodust).

  3.  Those with both a very substantial IP or IP/MPLS infrastructure
      and a substantial SONET/OTN infrastructure who would like to
      provide business units within their overall organization what
      they need to migrate their end user services from the SONET/OTN
      infrastructure to a IP/MPLS infrastructure.

People with the first perspective tends focused exclusively on making
MPLS-TP work with Ethernet and look like what they are used to (and
need to be occassionally reminded that MPLS-TP is more than that).
People with the second and third perspective tend to differ mostly in
the emphasis on OAM and their view on whether a control plane will be
deployed.

I don't mean to pigeon hole anyone in particular and acknowledge that
many people are able to understand and consider all of these
perspectives though they may lean more strongly toward one.

In any case, the technical issues are:

  1.  A need for an OAM that satisfies the operators needs for PM and
      CCV that they currently rely on.

  2.  The ability to optionally run without a control protocol and use
      that OAM as the mechanism to trigger protection.

That in a nutshell is it.  The OAM requirement has led to the
requirement to be able to turn off PHP and count at the egress on each
POP in addition to counting on the label that does a swap or
terminates an LSP.  The OAM requirement also requires fate sharing.

> running IP to Optics that was touted a decade ago?

Partially a layer-8 problem (carrier politics).  Partially due to
limited capability of transport equipment GMPLS implementations.

I do know of providers that run a GMPLS implementation within their
transport domain and a IP/MPLS implementation over that but I do not
know of any that are peering among the two.

That said, for the purpose of identification, I'm currently with
Infinera who offers an OTN/DWDM GMPLS implementation which is deploy
in many customer networks.

> dismiss as unimportant (ie 'let's move on')

Thanks for calling me ignorant.  Coming from you I don't mind.

> regards, neil

So lets move on.  :-)

Curtis

> > color=3D#800000><SPAN=20 
> > color=3D#800000><SPAN=20 
> > </DIV>Sent:=
> > org</A>=20
> > org</A>]=20