Subject: [Mpls-interop] Monitoring Section Level

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 26 Aug 2008 13:46:31 +0200

Hi,

We are currently updating the MPLS-TP OAM analysis document and intend
to submit soon an updated version.

We have got a comment that there is a need to monitor also Sections
(i.e. Spans). I could not find such a requirement in the MPLS-TP  OAM
requirements draft and thinking further on this I am not really sure
that section/span level is in the scope of the MPLS-TP work. I think
MPLS-TP deals with the LSP/LSP-segments and (SS/MS ) PW/PW-segment
levels. Apparently it seems that the section level is out-of-scope.

Please advice whether it is in scope or not. If in scope, the MPLS-TP
OAM requirements draft should be updated to include it. 

Best regards,

Nurit

----------------------------------------- 
Best regards, 

Nurit Sprecher

Nokia Siemens Networks GmbH & Co. KG 
Industry Environment

Senior Specialist, Carrier Ethernet Transport

3 Hanagar St. Neve Ne'eman B

45241 Hod Hasharon, Israel

Tel. +972 9 7751229

Mobile +972 54 2200954 
Email: [email-masked] <BLOCKED::mailto:[email-masked]> 

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

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 26 Aug 2008 13:54:48 +0200

Dear Nurit,

MPLS-TP work also deals with Sections as there is at least the need
to be able to run SCC/MCC over Sections and currently SCC/MCC form
part of the global OAM topic.
In tp-oam-reqs is stated:
"OAM functions MUST be able to be used for PWs and LSPs and Section."

regards,

-m

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> ------------------------------------------------------------------------
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 26 Aug 2008 14:59:48 +0200

Hi martin,
Good point. 
We'll update the document accordingly.
Best regards,
Nurit

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Tuesday, August 26, 2008 14:55
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Monitoring Section Level

Dear Nurit,

regards,

-m

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 26 Aug 2008 08:14:25 -0700

Out of scope - I think your formulation, LSP/LSP segments and an PW/PW
segments, is correct.  

>From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
>[mailto:[email-masked]] 
>Sent: Tuesday, August 26, 2008 4:47 AM
>To: MEAD team
>Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>Subject: [Mpls-interop] Monitoring Section Level
>
>Hi,
>
>We are currently updating the MPLS-TP OAM analysis document 
>and intend to submit soon an updated version.
>
>We have got a comment that there is a need to monitor also 
>Sections (i.e. Spans). I could not find such a requirement in 
>the MPLS-TP  OAM requirements draft and thinking further on 
>this I am not really sure that section/span level is in the 
>scope of the MPLS-TP work. I think MPLS-TP deals with the 
>LSP/LSP-segments and (SS/MS ) PW/PW-segment levels. Apparently 
>it seems that the section level is out-of-scope.
>
>Please advice whether it is in scope or not. If in scope, the 
>MPLS-TP OAM requirements draft should be updated to include it. 
>
>Best regards,
>
>Nurit
>
> 
>

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 26 Aug 2008 08:17:48 -0700

Martin,

Wouldn't a section be represented/instantiated in MPLS-TP as an LSP/LSP segment, as that is what MPLS understands?

Thanks,

John   

>From: Martin Vigoureux [mailto:[email-masked]] 
>Sent: Tuesday, August 26, 2008 4:55 AM
>Cc: MEAD team; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>MPLS-TP work also deals with Sections as there is at least the 
>need to be able to run SCC/MCC over Sections and currently 
>SCC/MCC form part of the global OAM topic.

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 26 Aug 2008 17:58:20 +0200

John, all

in some tp drafts we can find something like:
a MPLS Section is a network segment between two LSRs that are
immediately adjacent at the MPLS layer

George once gave this definition:
A "MPLS Section" is nothing other than the logical link between two
LSRs.

In the JWT slides a Section is represented as a link between
two adjacent LSRs.

Yet, I feel that these still leave room for various understandings.
But my understanding is that a Section is not a lsp segment.
Thoughts?

-m

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 26 Aug 2008 09:26:07 -0700

It sounds a lot like a hierarchical LSP 

>Sent: Tuesday, August 26, 2008 8:58 AM
>To: Drake, John E
>Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); MEAD team; 
>Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>A "MPLS Section" is nothing other than the logical link 
>between two LSRs.
>
>> Wouldn't a section be represented/instantiated in MPLS-TP as 
>an LSP/LSP segment, as that is what MPLS understands?
>> 
>> Thanks,
>> 
>> John   
>> 
>Sections 
>>>> Nokia Siemens Networks GmbH & Co. KG Industry Environment
>>>>
>---------------------------------------------------------------------
>>> -
>>>> --
>>>>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 26 Aug 2008 13:06:00 -0400

I've not kept up with the whole thread but in ITU, a segment is associated as a 1:1 relationship to an end to end trail. "Section" is used in SDH and OTN for a multiplexing layer (different layer) so it can have a 1:N relationship (12 STS-1/OC-12) or 1:1 (STS-12c/OC-12). As it seems not to refer to a segment, then it does sound like it's a hierarchical LSP.

Deborah

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 26 Aug 2008 19:22:57 +0200

Deborah, John,

my understanding is that it is not related to hierarchical LSPs,
at least mpls-tp ones ,otherwise why make a distinction between
E2E LSP OAM and 1-hop LSP (i.e. Section ?) OAM?
The JWT slides do not highlight a Label for Section OAM.

-m

---

From: George Swallow <[email-masked]>
Date: Tue, 26 Aug 2008 13:51:40 -0400

Martin -

What you quote, I said.  However I did not call that a definition.  I do not
like the term "MPLS Section".  I think for most IETFer's it is confusing at
best and mis-leading for many.

Link / Logical Link are more natural terms.  At Cisco we call them MPLS
enabled links (since IP is assumed).

For our purposes I would suggest just "MPLS Link".

...George

On 8/26/08 11:58 AM, "Martin Vigoureux" <[email-masked]>
wrote:

>> Wouldn't a section be represented/instantiated in MPLS-TP as an LSP/LSP
>> segment, as that is what MPLS understands?
>> 
>> Thanks,
>> 
>> John   
>>

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 26 Aug 2008 20:27:06 +0200

Hi Deborah,

You wrote:

> I've not kept up with the whole thread but in ITU, a segment is
 > associated as a 1:1 relationship to an end to end trail.
 > "Section" is used in SDH and OTN for a multiplexing layer
 > (different layer) so it can have a 1:N relationship (12 STS-1/OC-12)
 > or 1:1 (STS-12c/OC-12). As it seems not to refer to a segment,
 > then it does sound like it's a hierarchical LSP.

I have to disagree with you (and I checked the relevant ITU-T
recommendations G.780 and G.870, and ANSI standards).

By definition a section is a trail in the section layer,
in SDH this is either the multiplex section or the regenerator
section, terminated at both ends by a termination function.

A trail can consist of 2 or more segments,
By definition a trail segment is a segment that at one end
is terminated by a trail termination function.

Kind regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 26 Aug 2008 14:35:19 -0400

I found the definition of T-MPLS section (TMS) - it's in G8110.1's Appendix (not normative). Amendment 1 (2007) provided more information on it - it was optional and it appears to be based on how label 14's use was being modeled and the TMS's 1:1 relationship with the PHY layer. But as it says:
"This appendix provides an example of a layer structure in a T-MPLS network that could be implemented using the T-MPLS technology. Alternative layer structures are not precluded."

I don't think we need to follow it exactly...
Deborah

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: Tuesday, August 26, 2008 1:23 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: Drake, John E; MEAD team; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Monitoring Section Level

Deborah, John,

-m

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 26 Aug 2008 14:45:38 -0400

Hi Huub,

Not sure that we are disagreeing;-)
I didn't say that a layer wasn't a trail or that it didn't support segments. I was only commenting on the hierarchical relationship that segments were within a layer (i.e. trail) and a "section" referred to a different layer (i.e. trail). And provided an example of a path layer and section layer relationship.

I found though the definition of T-MPLS section (see my other mail). As the appendix is more on describing a way to support it, it would help us if you can describe what it is that is needed.

Deborah 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Tuesday, August 26, 2008 2:27 PM
Cc: MEAD team
Subject: Re: [Mpls-interop] Monitoring Section Level

Hi Deborah,

Kind regards, Huub.

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 26 Aug 2008 12:35:09 -0700

Martin,

I would agree that a 'section' is not an LSP segment.

George's definition, "A 'MPLS Section' is nothing other than the logical link between two LSRs." equates to a hierarchical LSP.  The JWT definition, "a link between two adjacent LSRs" equates to either a 'link' or a 'hierarchical LSP', since a 'link' is also a 'hierarchical LSP'.

I think the problem is that in SDH/SONET networks, 'section' has a well defined meaning, but in an MPL TP context it is an unneccessary term.  I.e., the two definitions you provided equated it to terms we already have.

Thanks,

John 

>Sent: Tuesday, August 26, 2008 10:23 AM
>my understanding is that it is not related to hierarchical 
>LSPs, at least mpls-tp ones ,otherwise why make a distinction 
>between E2E LSP OAM and 1-hop LSP (i.e. Section ?) OAM?
>> I've not kept up with the whole thread but in ITU, a segment 
>is associated as a 1:1 relationship to an end to end trail. 
>(different layer) so it can have a 1:N relationship (12 
>STS-1/OC-12) or 1:1 (STS-12c/OC-12). As it seems not to refer 
>to a segment, then it does sound like it's a hierarchical LSP.
>> 
>> Deborah
>> 
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Drake, John E
>>> In the JWT slides a Section is represented as a link between two 
>>> adjacent LSRs.
>>>

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 26 Aug 2008 22:21:09 +0200

George,

I am the one having called it a definition.
I am fine with MPLS Link, what I care most about is that
we all have the same understanding of what this term represent.

-m

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 26 Aug 2008 22:42:06 +0200

Deborah,

thus a MPLS Section/Link would sit between the top most label
of the stack and the PHY?

-m

---

From: George Swallow <[email-masked]>
Date: Tue, 26 Aug 2008 17:49:23 -0400

Personally, I'm just a bit lost as to exactly what we are trying to define
here.  This thread seems to have started with a "term" and has been
searching for the "thing".  I think we need to start with the "thing" and
then agree to a term.

What I thought we were talking about is the first "thing" that does not do
MPLS (at least from the point of view of the MPLS-TP network that we are
currently talking about.  There are cases of "Carrier's carrier" where even
the thing below again contains MPLS(-TP) but that would not be visible to
the network concerned.)  So if we are in fact talking about that "thing",
then this equates to a link between two adjacent MPLS(-TP) capable nodes in
a network.

And what you say below is true.  But to be just a bit more precise, it is
logically right next to the top label.  There could be something else
between it and the phy.

...George

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 27 Aug 2008 00:44:55 +0200

Section is actually the IETF span. Isn't it?

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 26 Aug 2008 19:20:13 -0400

I completely agree. I've been reading the thread steadily and trying to
figure out the same thing myself. Where and why do we need a section layer
for MPLS?!!!  

    --Tom

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 09:58:10 +0200

Yaacov,

I do not read this in the thread.

-m

Weingarten, Yaacov (NSN - IL/Hod HaSharon) a écrit :
> Hi all,
> 
> After reading the thread - I get the feeling that there seems to be a
> tendency amongst the group to say that "Sections" are either already
> covered by LSP or PW, or a hierarchical LSP - in which case they may be
> out-of-scope.  Therefore, (going back to the original question) we
> should not include them in the considerations of the OAM Analysis
> document.  Is this acceptable?
> 
> Thanx,
> Yaacov Weingarten
> 
>> From: ext Thomas Nadeau [mailto:[email-masked]]
>> Sent: Wednesday, August 27, 2008 02:20
>> To: George Swallow; Martin Vigoureux; BRUNGARD, DEBORAH A, ATTLABS
>>     I completely agree. I've been reading the thread steadily and
> trying
>> to
>>> searching for the "thing".  I think we need to start with the
> "thing"
>> and
>>> then agree to a term.
>>>
>>> What I thought we were talking about is the first "thing" that does
> not
>> do
>>> currently talking about.  There are cases of "Carrier's carrier"
> where
>> even
>>> the thing below again contains MPLS(-TP) but that would not be
> visible
>> to
>>> then this equates to a link between two adjacent MPLS(-TP) capable
> nodes
>> in
>>> a network.
>>>
>>> And what you say below is true.  But to be just a bit more precise,
> it
>> is

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 10:51:48 +0200

Looks like we are converging.

Do we all agree on the thing and the term:

MPLS(-TP) Link (or Section) : a link between two adjacent MPLS(-TP)
capable nodes, and corresponding to the logical entity existing right
after the top most label.

-m

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 27 Aug 2008 10:54:24 +0200

Hi Tom,

> figure out the same thing myself. Where and why do we need a section layer

The section layer in MPLS-TP is the layer closest to the physical layer,
but can also be a layer in another technology.

The sections in the section layer connect adjacent MPLS-TP nodes.
The OAM in the section layer contains the MCC and SCC required to
manage the MPLS-TP nodes.

If the nodes are managed via another channel (e.g. the OCC or DCC)
the section layer is optional.

Regards, Huub.

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 10:43:41 +0200

Tom,

the need is about finding a terminology to refer unambiguously to the
logical link between two adjacent mpls-tp LSRs so as to make a 
distinction with LSPs & PWs as there is a will to be able to at least
run SCC/MCC between these two LSRs.

-m

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 27 Aug 2008 13:47:44 +0200

We are confusing here between a definition and an implementation. 
We defined a section in the MPLS-TP requirements draft as "A section is a network segment between two LSRs that are immediately adjacent at the MPLS-TP layer.". 
The existence of a logical label in the frame is an implementation.

Also, as I indicated in my previous mail, IMO a section is what we define in the IETF CCAMP recovery documents as a span.

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Wednesday, August 27, 2008 11:52
To: MEAD team
Cc: George Swallow; BRUNGARD, DEBORAH A, ATTLABS; Weingarten, Yaacov (NSN - IL/Hod HaSharon); Sprecher, Nurit (NSN - IL/Hod HaSharon); Thomas Nadeau; Drake, John E; Huub van Helvoort
Subject: Re: [Mpls-interop] Monitoring Section Level

-m

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 27 Aug 2008 07:50:42 -0400

Use of the term "link" is inappropriate here. What I think you want is a
"logical path" or something. In general, the PW (or top-most label as you
say) really is a logical path between two end points within the network
which is actually represented by the label stack and switching operations
across the network. Those points might or might not follow one LSP (the
underlying label) one-for-one, but may not of course.  However, in the case
of MPLS-TP, I think that we are constrained to follow one and only one
underlying LSP path.

    I also think you want to call what you are referring to as an "MPLS(-TP)
capable node" an MPLS-TP-capable Label Switching Router (LSR) in RFC3031
parlance.

    --Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2008 13:00:52 +0100

Hi Nurit,

> Also, as I indicated in my previous mail, IMO a section is what
> we define in the IETF CCAMP recovery documents as a span.

That is consistent with my understanding.

For those too lazy to look it up...

RFC4426 has a "span" as a "link between adjacent LSRs." It also has "LSP 
segment" as the part of an LSP between two nodes "(i.e., an SNC in the ITU-T 
terminology)."

Note that RFC4397 has
      LSP segment is a single resource or a set of cross-connected resources 
that
      constitutes a segment of an LSP.
and
      An LSP segment is an ASON serial compound link connection.

Cheers,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 27 Aug 2008 14:39:08 +0200

Hi Adrian,

> segment" as the part of an LSP between two nodes "(i.e., an SNC in the ITU-T 

If you look at figure 3 of G.805 you will see that an SNC
is the connection inside a connection function (matrix), the
connection between connection functions is a link connection.

In the ITU-T a section is a *link connection*,
a span is a *link connection* in figure 3/G.805.
The *tandem connection* or *segment* is depicted in figure 2/G.805.

So could we use this figure 3/G.805 as a reference and add the
IETF terminology to each of the functions/entities?

Cheers, Huub.

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 14:19:36 +0200

Adrian, Nurit,

I am fine with "Span" as the term. What I want to ensure
is that the "thing" the term refers to is clear to the reader
and was afraid that only saying "link between adjacent LSRs"
was not enough.
But if everyone agree, then fine, and the existing definitions
are thus ok.
Nurit, I do not recall having talked about a logical label in a frame.

-m

Adrian Farrel a écrit :
> segment" as the part of an LSP between two nodes "(i.e., an SNC in the 
> ITU-T terminology)."
> 
> Note that RFC4397 has
>      LSP segment is a single resource or a set of cross-connected 
> resources that

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 27 Aug 2008 13:55:10 +0100

Actually I think "link" is appropriate.  What is key is that it is between
two topologically adjacent MPLS-TP devices (at the MPLS-TP topology layer)
and that is precisely what a link is in IETF parlance.

I don't like section as it has all sorts of connotations and preconceptions
as to what it means (from a circuit switching background) that may not be
relevant in a packet switching environment.

So the "thing" is what connects two topologically adjacent MPLS-TP devices
(at the MPLS-TP topology layer) and the "term" I prefer for it is link (or
"MPLS-TP link" if we want to be more precise).

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 27 Aug 2008 09:05:03 -0400

> and that is precisely what a link is in IETF parlance.

    I think what is being sought is something with "layer" after it. Link
layer is not what we want here. Link also implies an interface, which is not
what this is.  The labels represent a path across the network, plain and
simple.
 
> relevant in a packet switching environment.
    
    Agreed.
 
> "MPLS-TP link" if we want to be more precise).

    Lets not get carried away and start making up our own terminology here.
"MPLS-TP link" is something new that I'd like to avoid. Lets re-use as much
as possible from the existing MPLS terminology/functionality.

    --Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2008 14:12:28 +0100

Hi Huub,

Actually, I am concerned by attempts to repeat nomenclature mapping 
exercises that have consumed massive amount of b/w in the past.

As far as I can see, the G.805 does definition of SNC (3.34) and its use in 
Figure 3, exactly match the definition I quoted.

Loosely (and for quickness and clarity, not for precision)

An ITU trail is an IETF end-to-end LSP
An ITU SNC is an LSP segment
An ITU link connection is an IETF span (but the term span is not used so 
much in the IETF any more, and "data link" or just "link" will do the job 
perfectly).

It appears from the definition of tandem connection in G.805 (3.35) that the 
word "tandem" is something of a misnomer. It is just "An arbitrary series of 
contiguous 'link connections' and/or 'subnetwork connections'." There is 
nothing "tandem" about this.

That means that a "tandem connection" is an LSP segment.

There seems to be some distinction that an SNC goes between edges of a 
subnetwork, where a tandem connection can go from any arbitrary start and 
finish points. The concept, "LSP segment" covers both of these. I do not 
believe that we need to make a finer grain distinction.

Again, please read RFC 4397 to get the picture of terminology mapping that 
was agreed between the IETF and ITU.

Thanks,
Adrian

----- Original Message ----- 
From: "Huub van Helvoort" <[email-masked]>
Cc: "MEAD team" <[email-masked]>
Sent: Wednesday, August 27, 2008 1:39 PM
Subject: Re: [Mpls-interop] Monitoring Section Level

>> ITU-T
>> resources

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 27 Aug 2008 14:29:42 +0100

Tom,

I have attached a diagram of my understanding of what the "thing" is we are
talking about here which clearly to my mind is a "link".

Also,
>     I think what is being sought is something with "layer" after it.

That is not my interpretation and also why I don't like section as it
historically has been a separate layer.  What we are talking about here does
not need to to be a separate layer IMO.

The requirement is to be able to monitor the integrity of the "path" between
two topologically adjacent MPLS-TP devices independent of monitoring the
integrity of the end to end MPLS-TP "path".

My assertation is that the end to end "path" is an LSP and the "path"
between two topologically adjacent MPLS-TP devices is a link.

Let's remove "-TP" from the equation.  What would you call the "thing" (e.g.
A wet piece of string) that connects two regular MPLS devices directly to
one another?

> Link

I'm not trying to make anything up, in fact precisely the opposite.  Link is
a well known (and IMO the appropriate) term, prepending MPLS-TP to it is
just to indicate which layer it is referring to and is analogous to
referring to an ATM link, MPLS link or IP link.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 27 Aug 2008 09:32:37 -0400

> A wet piece of string) that connects two regular MPLS devices directly to

    A LSP.

    --Tom

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 27 Aug 2008 08:32:46 -0500

Tom,

	Actually, there is a subtle difference between "a link layer" 
and the "Link Layer" - and it is probably the case that "link" - as
it might be associated with "a link layer" is an appropriate term.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> Sent: Wednesday, August 27, 2008 9:05 AM
> To: Benjamin Niven-jenkins; Martin Vigoureux; MEAD team

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 27 Aug 2008 14:38:18 +0100

>> A wet piece of string) that connects two regular MPLS devices directly to

So then what we would be saying is that there is always an LSP hierarchy
present, where there is a single hop LSP (which is the "thing" we are
discussing) between each pair of adjacent MPLS-TP devices along the end to
end path and then another end to end LSP which rides over each of the single
hop LSPs in turn?

That is at odds to my current understanding of the MPLS-TP architecture
(i.e. My understanding is that LSP hierarchy is not always present).

Ben

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 15:46:38 +0200

the arrow on Ben's slide is for me not pointing to a MPLS-TP
LSP but to a "link" which can either be
a physical link if the two LSRs are physically neighbours
or a logical link if these two LSRs are in fact connected via
other means (e.g. an underlying tunnelling technology).
Of course this techno could be an e2e mpls-tp LSP but then
we are back at effectively pointing at an lsp
but when there is no mpls-tp lsp established, what is the arrow pointing to?

-m

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Aug 2008 15:10:46 +0100

Hmmm.

My last email on this?

All this re-invention is really frustrating!

Talk about data links, TE links, LSPs, hierarchical LSPs, and LSP segments. 
Do you need any other terms?

A hierarchical LSP may be advertised and/or used as a data link or TE link. 
Doing so does create a layering function, but this is not known by the 
client layer.

A
----- Original Message ----- 
From: "Martin Vigoureux" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>; "Thomas Nadeau" 
<[email-masked]>
Cc: "MEAD team" <[email-masked]>; "Weingarten,Yaacov (NSN - IL/Hod 
HaSharon)" <[email-masked]>
Sent: Wednesday, August 27, 2008 2:46 PM
Subject: Re: [Mpls-interop] Monitoring Section Level

-m

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 07:10:13 -0700

Martin,

Why do we feel the need to define an already well understood term?  That was the question I was trying to raise in the e-mails I sent yesterday.

Thanks,

John 

>Sent: Wednesday, August 27, 2008 1:52 AM
>To: MEAD team
>Cc: George Swallow; BRUNGARD, DEBORAH A, ATTLABS; Weingarten, 
>Yaacov (NSN - IL/Hod HaSharon); Nurit Sprecher; Thomas Nadeau; 
>Drake, John E; Huub van Helvoort
>MPLS(-TP) Link (or Section) : a link between two adjacent 
>MPLS(-TP) capable nodes, and corresponding to the logical 
>entity existing right after the top most label.
>
>-m
>
>George Swallow a écrit :
>> Personally, I'm just a bit lost as to exactly what we are trying to 
>> define here.  This thread seems to have started with a 
>"term" and has 
>> been searching for the "thing".  I think we need to start with the 
>> "thing" and then agree to a term.
>> 
>> not do MPLS (at least from the point of view of the MPLS-TP network 
>> that we are currently talking about.  There are cases of "Carrier's 
>> carrier" where even the thing below again contains MPLS(-TP) 
>but that 
>> would not be visible to the network concerned.)  So if we 
>are in fact 
>> talking about that "thing", then this equates to a link between two 
>> adjacent MPLS(-TP) capable nodes in a network.
>> 
>> And what you say below is true.  But to be just a bit more 
>precise, it 
>> is logically right next to the top label.  There could be something 
>> else between it and the phy.
>> 
>> ...George
>> 
>>> thus a MPLS Section/Link would sit between the top most 
>label of the 
>>> stack and the PHY?
>>>
>>> -m
>> 
>> 
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 27 Aug 2008 10:13:08 -0400

> Do you need any other terms?

    My point precisely.  We seem to be really confusing things here
unnecessarily. 

    --Tom

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 16:19:10 +0200

John,

I personally do not feel the need to define anything
but seeing the exchanges, I wouldn't say that what we are
talking about is "well understood" or more precisely
I would say that we all have a personal good understanding
of a thing but may not be talking about the same thing.

-m

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 27 Aug 2008 15:23:38 +0100

>> All this re-invention is really frustrating!

I am not trying to reinvent anything.  Use of the term link is reuse not
reinvention IMO. If another pre-existing term is more appropriate then fine
I don't really care except I really don't like "section".

Ben

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 07:25:50 -0700

>> So the "thing" is what connects two topologically adjacent MPLS-TP 
>> devices (at the MPLS-TP topology layer) and the "term" I 
>prefer for it 
>> is link (or "MPLS-TP link" if we want to be more precise).
>
>"MPLS-TP link" is something new that I'd like to avoid. Lets 
>re-use as much as possible from the existing MPLS 
>terminology/functionality.
>
>    --Tom
>

JD:  Exactly my point.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 07:29:56 -0700

>
>It appears from the definition of tandem connection in G.805 
>(3.35) that the word "tandem" is something of a misnomer. It 
>is just "An arbitrary series of contiguous 'link connections' 
>and/or 'subnetwork connections'." There is nothing "tandem" about this.
>

JD: The term 'Tandem Connection' is a wonderful flight of fancy.  I had
thought that a 'tandem connection' was a hierarchical e2e LSP rather
than an LSP segment, because there could be multiple LSPs contained
within it.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 27 Aug 2008 16:30:54 +0200

Hi,
I propose to use the IETF terminology and define the mapping between the
ITU-T terminology and the IETF's. 
Still we need to see if span/section is in the scope of MPLS-TP. Martin
indicated that the management and the control channels are per
span/section and that is why it is in scope and we need to monitor the
span. On the other hand if we have an out-of-band management interface -
is it in scope as well? I do not think so. Please advice if section/span
is in scope. 
I am a little bit concerned from the redundant terminologies we use. For
example the use of segment and TC looks for me a little bit redundant,
unless TC is an architectural entity that is used to monitor a segment.
But if so, is it the place to define it and discuss it in the OAM
requirement draft or in the framework? The requirement should be to
allow the monitoring of (LSP/PW) segment. 
Best regards,
Nurit

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, August 27, 2008 15:01
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Martin Vigoureux; MEAD
team

Hi Nurit,

Note that RFC4397 has

Cheers,
Adrian

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 07:34:25 -0700

Ben,

One could argue that a hierarchical LSP is always present.  A link is a
hierarchical LSP whose label is implicitly that link's interface ID.
(As I mentioned yesterday, when you go below the packet layer labels
become implicit.) 

Thanks,

John  

>From: Ben Niven-Jenkins [mailto:[email-masked]] 
>Sent: Wednesday, August 27, 2008 6:38 AM
>To: Thomas Nadeau; Martin Vigoureux; MEAD team
>>> A wet piece of string) that connects two regular MPLS devices 
>>> directly to one another?
>> 
>>     A LSP.
>
>So then what we would be saying is that there is always an LSP 
>hierarchy present, where there is a single hop LSP (which is 
>the "thing" we are
>discussing) between each pair of adjacent MPLS-TP devices 
>along the end to end path and then another end to end LSP 
>which rides over each of the single hop LSPs in turn?
>
>That is at odds to my current understanding of the MPLS-TP 
>architecture (i.e. My understanding is that LSP hierarchy is 
>not always present).
>
>Ben
>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 16:42:37 +0200

Nurit,

please see in-line.

-m

> is it in scope as well? I do not think so. Please advice if section/span

in scope

> unless TC is an architectural entity that is used to monitor a segment.

the JWT slides seem to suggest that this is an architectural construct.

> requirement draft or in the framework?

as discussed, my opinion is that it better fits in the framework

> The requirement should be to allow the monitoring of (LSP/PW) segment.

the requirements should be to allow OAM for all mpls-tp related entities

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Wed, 27 Aug 2008 10:00:49 -0500

It is in scope.  We should/could not mandate there is always an
out-of-band management interface. 

Regards,
Kam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)
Sent: Wednesday, August 27, 2008 10:31 AM
To: Adrian Farrel; VIGOUREUX, MARTIN (MARTIN); MEAD team
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] Monitoring Section Level

Hi,

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, August 27, 2008 15:01
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Martin Vigoureux; MEAD
team

Hi Nurit,

Note that RFC4397 has

Cheers,
Adrian

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 16:56:20 +0200

I have a similar understanding
TC looks like an e2e LSP, spanning a segment of a longer one
which is in fact tunnelled into that TC.

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 08:05:50 -0700

Excellent, thanks.  The reserved label would then be used to transfer OAM packets between the endpoints of that e2e hierarchical LSP.

>Sent: Wednesday, August 27, 2008 7:56 AM
>To: Drake, John E
>Cc: Adrian Farrel; [email-masked]; MEAD team
>>> (3.35) that the word "tandem" is something of a misnomer. 
>It is just 
>>> "An arbitrary series of contiguous 'link connections'
>> JD: The term 'Tandem Connection' is a wonderful flight of fancy.  I 
>> had thought that a 'tandem connection' was a hierarchical e2e LSP 
>> rather than an LSP segment, because there could be multiple LSPs 
>> contained within it.
>>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 27 Aug 2008 17:33:15 +0200

that is indeed what depicts the jwt slides.

-m

---

From: George Swallow <[email-masked]>
Date: Wed, 27 Aug 2008 15:13:06 -0400

One can also argue about how many Angels can stand on the head of a pin
(occupied a bunch of monks for scores of years in the middle ages).  But if
there is no label - not even an implicit null - let us not invent one.  I'm
with Ben - link is a fine term.

...George

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 27 Aug 2008 12:39:40 -0700

George,

I already agreed 'link' was fine.

My point was not an abstract point.  Your 'link' is, by definition, also
a hierarchical LSP that could very well have been established with GMPLS
signalling across many hops in the underlying transport network.

Thanks,

John

>From: George Swallow [mailto:[email-masked]] 
>Sent: Wednesday, August 27, 2008 12:13 PM
>To: Drake, John E; Ben Niven-Jenkins; Thomas Nadeau; Martin 
>Vigoureux; MEAD team
>One can also argue about how many Angels can stand on the head 
>of a pin (occupied a bunch of monks for scores of years in the 
>middle ages).  But if there is no label - not even an implicit 
>null - let us not invent one.  I'm with Ben - link is a fine term.
>
>...George
>
>
>> One could argue that a hierarchical LSP is always present.  
>A link is 
>> a hierarchical LSP whose label is implicitly that link's 
>interface ID.
>>> hierarchy present, where there is a single hop LSP (which is the 
>>> "thing" we are
>>> discussing) between each pair of adjacent MPLS-TP devices along the 
>>> end to end path and then another end to end LSP which rides 
>over each 
>>> of the single hop LSPs in turn?
>>> 
>>> architecture (i.e. My understanding is that LSP hierarchy is not 
>>> always present).
>>> 
>>> Ben
>>>

---

From: George Swallow <[email-masked]>
Date: Wed, 27 Aug 2008 15:55:20 -0400

> I already agreed 'link' was fine.

Cool.

> signalling across many hops in the underlying transport network.

While a link can certainly serve as a TC, I believe we need a separate term
for the thing that is at the lowest level of the network currently under
reference.  There will certainly arise special issues here (such as dealing
with link bundles) that are of far less concern higher up the hierarchy.
But your point is well taken.

...George