Subject: [Mpls-interop] ttl-expiration question

From: Loa Andersson <[email-masked]>
Date: Tue, 21 Oct 2008 23:10:59 +0200

All,

I've a question about how will ttl-expiration work with for
Label 13 in the case of segement protection.

In the following scenario Label 13 will end up on top if
the TTL is set correctly at F.

     +---+     +---+     +---+     +---+     +---+     +---+
-----| A |-----| B |-----| C |-----| D |-----| E |-----| F |-----
     +---+     +---+     +---+     +---+     +---+     +---+

     ttl=6     ttl=5     ttl=4     ttl=3     ttl=2     ttl=expired

So an packet with a Label 13 will reach F and treated as an
OAM packet :) !

Now assume that we sprotect the segment from B to E by a path
like this:

     +---+     +---+     +---+     +---+     +---+     +---+
-----| A |-----| B |--x--| C |-----| D |-----| E |-----| F |-----
     +---+     +---+     +---+     +---+     +---+     +---+
                 |                             |
     ttl=6     ttl=5                           |
                 |                             |
                 |                             |
               +---+                         +---+
               | G |                         | L |
               +---+                         +---+
                 |                             |
               ttl=4                           |
                 |                             |
               +---+     +---+     +---+     +---+
               | H |-----| I |-----| J |-----| K |
               +---+     +---+     +---+     +---+

               ttl=3     ttl=2     ttl=expired

The packet don't reach F :( !

What is the cure? Do we bump the ttl up?

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Oct 2008 14:30:16 +0100

Yes, Loa, a real problem.

Not just in segment protection as you describe, but also in fast re-route.

There is a very ugly solution that says every ME must be mapped to a tunnel 
and that every protectable LSP segment must also be mapped to a tunnel. 
Administratively, this would be impossible to operate.

The alternative is, as you suggest, that the TTL must be massaged. For FRR, 
this could happen at the PLR or the MP, but for your example of segment 
protection, it has to be performed at the PLR. The question here is for 
hardware manufacturers since this would required:
- the ability to make other than unit modifications to the TTL
- the ability to make positive changes to the TTL
- the ability to programme the hardware per-LSP to
  have different TTL modification characteristics

Failing this, maybe we need to look at a non-TTL mechanism for OAM delivery.

A

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 22 Oct 2008 16:05:37 +0200

Hi Adrian,

You wrote:

> There is a very ugly solution that says every ME must be mapped to a 
> tunnel and that every protectable LSP segment must also be mapped to a 
> tunnel. Administratively, this would be impossible to operate.

It is also possible to change the level of the ME at the ingress of
a protection entity and change it back to the original level at egress,
the TTL will then only be decremented in nodes within the same level
of ME.

Regards, Huub.

> The alternative is, as you suggest, that the TTL must be massaged. For 
> FRR, this could happen at the PLR or the MP, but for your example of 
> segment protection, it has to be performed at the PLR. The question here 
> is for hardware manufacturers since this would required:
> ----- Original Message ----- From: "Loa Andersson" <[email-masked]>

-- 
================================================================
                   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: "Shah, Himanshu" <[email-masked]>
Date: Wed, 22 Oct 2008 13:43:42 -0400

I think this is a real problem too, I am surprised that not many people
are jumping into the discussions ??

/himanshu
P.s. would have been nice if we were able to use one of those 'exp' (but
now cos)
value as OAM pkt indicator...:-)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, October 22, 2008 9:30 AM
To: Loa Andersson; MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Not just in segment protection as you describe, but also in fast
re-route.

tunnel. 

Failing this, maybe we need to look at a non-TTL mechanism for OAM
delivery.

A

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 19:51:49 +0200

Hi,
I think the answer is pretty clear. That is why we need to define the
protected segment as a Tandem Connection (TC), with 1:1 mapping to the
end-to-end LSP. The TC should be monitored using TCME and protected
accordingly.
With TC, we use the MPLS construct of hierarchical LSPs, and each level
the TTL is setup accordingly. 
That is why I issued the e-mail a few weeks ago (attached) asking to
include the new architectural functional element 'Tandem Connection' in
the MPLS framework. OAM should handle the TCME, i.e. the maintenance
domain that is used to monitor the TC. TC should be used for OAM,
protection switching and maybe for other functions as well.
Best regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Loa Andersson
Sent: Tuesday, October 21, 2008 23:11
To: MEAD team
Subject: [Mpls-interop] ttl-expiration question

All,

               ttl=3     ttl=2     ttl=expired

/Loa

-- 
Loa Andersson

Subject: RE: [Mpls-interop] Tandem Connection
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Loa Andersson" <[email-masked]>
Cc: "MEAD team" <[email-masked]>, "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 3 Oct 2008 13:19:23 +0200

Hi,

Thinking more about this, I think we need to define TC as a new
architectural element in the MPLS-TP architecture document. Note that it
makes use of LSP hierarchies but this is a specific case of 1:1
relationship between TC and LSP/PW. 

MPLS-TP OAM framework should refer to it and extend it with TCME.
MPLS-TP survivability should refer to it as well (especially for the
case of Peer State Coordination (PSC) /  APS)  messages.  Maybe we'll
find some other uses for TC. 

In addition, I think that MPLS-TP OAM requirements should not refer to
TC. It should provide a requirement to manage and monitor the network in
different nested levels. TC is the architectural element that is used to
address this requirement. This should be described in the OAM framework
document. 

Best regards,

Nurit

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Sprecher, Nurit
(NSN - IL/Hod HaSharon)
Sent: Thursday, October 02, 2008 21:33
To: ext Loa Andersson
Cc: MEAD team; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: [Mpls-interop] Tandem Connection

Hi Loa,

In all documents (basically in OAM, survivability, etc.) we refer to
Tandem Connection (LSP segment or one or more PW segments)...

It is true that an LSP segment uses the MPLS construct of hierarchical,
nested LSP and an MS-PW segment uses the construct defined in PWE3 (MPLS
PW switching). Still don't we need to describe how to have 1:1 mapping
between an LSP and its TC, how to define a TC on an existing LSP without
disruption to the service, etc. 

Which document is supposed to define all TC related topics? Where is it
covered?

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]>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 19:53:06 +0200

I think Adrian you are referring to the protection domain where the TTL
must be set appropriately and we need a TC to handle this correctly.
Please see my other e-mail on this.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Adrian Farrel
Sent: Wednesday, October 22, 2008 15:30
To: Loa Andersson; MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

tunnel 

FRR, 

A

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 19:53:44 +0200

Changing the ME level is actually having a TC. Isn't it?

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Huub van
Helvoort
Sent: Wednesday, October 22, 2008 16:06
To: Adrian Farrel
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Hi Adrian,

re-route.

Regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 19:54:53 +0200

I am surprised from the question. I thought that this is one of the
purposes of TC (in addition to the monitoring function).

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Shah, Himanshu
Sent: Wednesday, October 22, 2008 19:44
To: Adrian Farrel; Loa Andersson; MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

/himanshu

-----Original Message-----

A

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 22 Oct 2008 11:10:47 -0700

I have several questions:

1) Why would we would introduce a non-evocative term 'tandem
connection', when we have a perfectly good term, 'hierarchical LSP'?

2) Why would you use a 1:1 mapping when you get LSP multiplexing for
free? 

>From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
>[mailto:[email-masked]] 
>Sent: Wednesday, October 22, 2008 10:52 AM
>To: ext Loa Andersson; Adrian Farrel
>Cc: MEAD team; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>I think the answer is pretty clear. That is why we need to 
>define the protected segment as a Tandem Connection (TC), with 
>1:1 mapping to the end-to-end LSP. The TC should be monitored 
>using TCME and protected accordingly.
>With TC, we use the MPLS construct of hierarchical LSPs, and 
>each level the TTL is setup accordingly. 
>That is why I issued the e-mail a few weeks ago (attached) 
>asking to include the new architectural functional element 
>'Tandem Connection' in the MPLS framework. OAM should handle 
>the TCME, i.e. the maintenance domain that is used to monitor 
>the TC. TC should be used for OAM, protection switching and 
>maybe for other functions as well.
>Best regards,
>Nurit
>
>In the following scenario Label 13 will end up on top if the 
>TTL is set correctly at F.
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 20:16:40 +0200

HI,
(1) I am open for new terminologies although how would you call it when
you are referring to a part of a PW (one or more PW segments)?
2. TC was the element to which we referred in all of most of the
documents and is pretty much aligned with TCME. 
3. this was discussed in the JWT.
4. 1:1 mapping (for which TC is perfectly matched) is essential when you
want to monitor a LSP and not an aggregation of LSPs and when you want
to protect a LSP and not an aggregation of LSPs. 
5. We do not preclude LSP hierarchies to have TE links and aggregation
of LSps. But this is something else. With TC we just use the construct
of LSP hierarchies.  
Best regards,
Nurit

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 20:11
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson; Adrian
Farrel
Cc: MEAD team; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] ttl-expiration question

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 22 Oct 2008 13:20:15 -0500

Himanshu,

	Since you brought an unrelated topic into the discussion,
it is no longer officially referred to as the EXP field (or EXP
bits [field]), but neither is it officially "CoS" or "COS" [bits]
[field].

	It will be called the "TC Field" (at least officially).

	See the announcement mail attached...

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, October 22, 2008 1:44 PM

Subject: [mpls] I-D Action:draft-ietf-mpls-cosfield-def-05.txt
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 17 Oct 2008 09:15:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : "EXP field" renamed to "Traffic Class field"
	Author(s)       : L. Andersson, R. Asati
	Filename        : draft-ietf-mpls-cosfield-def-05.txt
	Pages           : 18
	Date            : 2008-10-17

The early MPLS documents defined the form of the MPLS Label Stack
entry.  This include a three bit field called the "EXP field".  The
exact use of this field was not defined by these documents, except to
state that it was to be "reserved for experimental use".

Although the intended use of the EXP field was as a "Class of
Service" field, it was not named the "Class of Service" (CoS) field
by these early documents because the use of such a CoS field was not
considered to be sufficiently defined.  Today a number of standards
documents define its usage as a CoS field. .

To avoid misunderstanding about how this field may be used, it has
become increasingly necessary to rename this field.  This document
changes the name of the field to the "Traffic Class field" ("TC
field".)  In doing so it also updates documents that define the
current use of the EXP this field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-cosfield-def-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Oct 2008 21:35:22 +0200

> the TTL is setup accordingly.

exactly how? I assume that no magic is used :)

/Loa

-- 
Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Oct 2008 21:38:14 +0200

Nurit,

if we don't understand exactly how the mechanism I'm supposed to
implement works, I'm supposed to ask - ain't I?

You say I TC solves the problem - exactly how?

/Loa

-- 
Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 21:41:04 +0200

The same way as it is done with OAM (TCME), what is the difference? 
I think in the JWT it was discussed how a TC can be set up for a LSP and
how it is handled, using label stacking at the edges of a TC. It was
even indicated how a TC can be defined on active LSP without disruption
to the service, using make-before-break. It was indicated that unlimited
of nesting can be supported.
I am a little bit surprised, what was the use of TC in OAM if we do not
use it also for protection switching? 

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 21:35
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

/Loa

-- 
Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 21:47:26 +0200

Hi John,
Please see inline.
Best regards,
Nurit

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 21:12
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson; Adrian
Farrel

Nurit,

The operation of an LSP 'tandem connection' and the operation of a PW
'tandem connection' are different.  The former can be established
between any two nodes along the path of an LSP.  The latter can only be
established between the endpoints of a PW segment (or E2E PW).  So, in
reality we have two terms.
<NS> we still need to prove it but I believe we can use the same way to
handle both. The principle is that you can define a segment between
nodes that can handle that layer. I.e. in LSP (in level N) you can
create a TC between two LSRs that handles the LSP in layer N. In PW, you
can do it at the PEs (either T or S). <NS>

We need to provide a mapping between the terms used in the ITU and the
terms used in the IETF, but we don't necessarily need to use the ITU's
terms.
<NS> we already used it in most of the documents but we can think about
anther name Although TC really reflects the meaning. <NS> 
What you  seem to be saying that an LSP 'tandem connection' is a
hierarchical LSP that *only* contains one LSP.  You further seem to be
saying that if, in the future, we perform OAM monitoring of multiple
LSPs, the we will have to invent yet another new term for that
construct. 
<NS> As I indicated in my other e-mail, it was agreed in the JWT that
Unlimited number of nesting TCs can be supported. So there is no need to
define new mechanisms or terminology. <NS>

If we really have to use 'tandem connection', I think it makes more
sense to use it to refer to the inband OAM monitoring of one or more
LSPs or PWs either between the endpoints or between select intermediate
points.
<NS> please see above the principles of between which nodes a TC (for
both LSPs and PWs) can be defined. 

Thanks,

John 

>Sent: Wednesday, October 22, 2008 11:17 AM
>To: Drake, John E; ext Loa Andersson; Adrian Farrel
>(1) I am open for new terminologies although how would you 
>call it when you are referring to a part of a PW (one or more 
>PW segments)?
>2. TC was the element to which we referred in all of most of 
>the documents and is pretty much aligned with TCME. 
>4. 1:1 mapping (for which TC is perfectly matched) is 
>essential when you want to monitor a LSP and not an 
>aggregation of LSPs and when you want to protect a LSP and not 
>an aggregation of LSPs. 
>5. We do not preclude LSP hierarchies to have TE links and 
>aggregation of LSps. But this is something else. With TC we 
>just use the construct of LSP hierarchies.  
>Best regards,
>Nurit
>
>To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa 
>Andersson; Adrian Farrel
>2) Why would you use a 1:1 mapping when you get LSP 
>multiplexing for free? 
>
>>protected segment as a Tandem Connection (TC), with
>>1:1 mapping to the end-to-end LSP. The TC should be monitored using 
>>TCME and protected accordingly.
>OAM packet 
>>:) !
>>Now assume that we sprotect the segment from B to E by a path like 
>>this:
>>
>>

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 22 Oct 2008 12:11:43 -0700

Nurit,

Thanks,

John

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 21:52:08 +0200

Hi Loa,
Sure. My comment was just in response to the surprise of Himansu :-)
I would like to refer you to the JWT V22, slides 49-69. 
I'll be more than happy to provide (but not before the first week of
November) some slides on how it can be implemented. Please advise if
this is needed.
Best regards,
Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 21:38
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Nurit,

/Loa

-- 
Loa Andersson

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 22 Oct 2008 16:19:11 -0400

You seem to be suggesting that what Loa, adrian and I were
acknowledging about the problem, that I should not even be wondering why
others
don't think that as a problem because obviously it is not even a problem
and if anybody, I should have known that.

Thanks Nurit!!

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)
Sent: Wednesday, October 22, 2008 3:52 PM
To: ext Loa Andersson
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Hi Loa,
Sure. My comment was just in response to the surprise of Himansu :-) I
would like to refer you to the JWT V22, slides 49-69. 
I'll be more than happy to provide (but not before the first week of
November) some slides on how it can be implemented. Please advise if
this is needed.
Best regards,
Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Wednesday, October 22, 2008 21:38
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Nurit,

/Loa

>> I've a question about how will ttl-expiration work with for Label 13 
>> in the case of segement protection.
>>
>> In the following scenario Label 13 will end up on top if the TTL is 
>> set correctly at F.
>>
>> So an packet with a Label 13 will reach F and treated as an OAM 
>> packet :) !
>>

--
Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Oct 2008 22:26:20 +0200

Nurit,

> the TTL is setup accordingly. 

does this "TTL is setup accordingly" ever have a higher outgoing
TTL than the invoming?

/Loa

-- 
Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 22:32:17 +0200

Too complicated for me. Sorry.
I apologize if someone was heart. It was not my intention. 

-----Original Message-----
From: ext Shah, Himanshu [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 22:19
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson
Cc: MEAD team
Subject: RE: [Mpls-interop] ttl-expiration question

Thanks Nurit!!

-----Original Message-----

Hi Loa,

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Wednesday, October 22, 2008 21:38
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Nurit,

/Loa

--
Loa Andersson

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2008 16:38:01 -0400

Nurit,

I must be missing something.  I don't see how TCs (with or w/o 
hierarchy) help without either playing some TTL games at one of the 
TC's endpoints, or moving to a non-TTL dependent OAM approach.

Can you elaborate on the (obvious?) solution?

Thanks,
Lou

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 22 Oct 2008 13:42:03 -0700

>Nurit,
>
>The operation of an LSP 'tandem connection' and the operation 
>of a PW 'tandem connection' are different.  The former can be 
>established between any two nodes along the path of an LSP.  
>The latter can only be established between the endpoints of a 
>PW segment (or E2E PW).  So, in reality we have two terms.
><NS> we still need to prove it but I believe we can use the 
>same way to handle both. The principle is that you can define 
>a segment between nodes that can handle that layer. I.e. in 
>LSP (in level N) you can create a TC between two LSRs that 
>handles the LSP in layer N. In PW, you can do it at the PEs 
>(either T or S). <NS>

JD:  I think you misunderstood me.  Will it be possible to set up a PW
'tandem connection' between *any* two xPEs along the path of a
multisegment PW, or only between adjacent xPEs?

>
>We need to provide a mapping between the terms used in the ITU 
>and the terms used in the IETF, but we don't necessarily need 
>to use the ITU's terms.
><NS> we already used it in most of the documents but we can 
>think about anther name Although TC really reflects the 
>meaning.<NS>

JD:  I think it was understood that there was going to be a terminology
cleanup.

>What you  seem to be saying that an LSP 'tandem 
>connection' is a hierarchical LSP that *only* contains one 
>LSP.  You further seem to be saying that if, in the future, we 
>perform OAM monitoring of multiple LSPs, the we will have to 
>invent yet another new term for that construct. 
><NS> As I indicated in my other e-mail, it was agreed in the 
>JWT that Unlimited number of nesting TCs can be supported. So 
>there is no need to define new mechanisms or terminology. <NS>

JD: Again, I think you misunderstood me.  I was talking about multiple
LSPs within a single containing hierarchical LSP.  Your original
statement was that this was not a tandem connection.I.e., "We do not
preclude LSP hierarchies to have TE links and aggregation of LSPs. But
this is something else."

>
>If we really have to use 'tandem connection', I think it makes 
>more sense to use it to refer to the inband OAM monitoring of 
>one or more LSPs or PWs either between the endpoints or 
>between select intermediate points.
><NS> please see above the principles of between which nodes a 
>TC (for both LSPs and PWs) can be defined. 
>
>Thanks,
>
>John 
>
>call it when 
>>4. 1:1 mapping (for which TC is perfectly matched) is essential when 
>>you want to monitor a LSP and not an aggregation of LSPs and when you 
>>want to protect a LSP and not an aggregation of LSPs.
>aggregation 
>Andersson; Adrian 
>define the

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 22:43:45 +0200

Hi Loa,
Yes, it may happen for traffic that goes through the TC (e.g.
end-to-end) and is not originated at the edge of the TC. 
Best regards,
Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 22:26
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Adrian Farrel; Weingarten, Yaacov (NSN - IL/Hod HaSharon); MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Nurit,

/Loa

-- 
Loa Andersson

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 22 Oct 2008 13:48:34 -0700

Lou,

Effectively, the channel that the inband OAM is running on is another
LSP within the containing hierachical LSP.  I.e., a 'tandem connection',
nee hierarchical LSP, contains two LSPs, the LSP being monitored and the
inband OAM channel monitoring it.  If one held one's head just right, I
guess you might be able to see where 'tandem connection' came from.  

This means that at the endpoints of the hierarchical LSP, the label
associated with the channel the the inband OAM is running on, rather
than TTL expiry, is used to identify the OAM packets.

Thanks,

John    

>From: Lou Berger [mailto:[email-masked]] 
>Sent: Wednesday, October 22, 2008 1:38 PM
>hierarchy) help without either playing some TTL games at one 
>of the TC's endpoints, or moving to a non-TTL dependent OAM approach.
>
>> > tunnel and that every protectable LSP segment must also be 
>mapped to 
>> > a tunnel.
>> > The alternative is, as you suggest, that the TTL must be massaged. 
>> > For FRR, this could happen at the PLR or the MP, but for your 
>> > example of segment protection, it has to be performed at the PLR. 
>> > The question
>>here
>> >> I've a question about how will ttl-expiration work with for Label 
>> >> 13 in the case of segement protection.
>> >>

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 22 Oct 2008 13:48:34 -0700

Lou,

Thanks,

John

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 22:50:32 +0200

This is true for OAM messages between MEPs, but we need the TTL to
direct messages for MIPs. 

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 22:49
To: Lou Berger; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: MEAD team
Subject: RE: [Mpls-interop] ttl-expiration question

Lou,

Thanks,

John

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 22:52:46 +0200

Inline :-) [Nurit]

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 22:42
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson; Adrian
Farrel

JD:  I think you misunderstood me.  Will it be possible to set up a PW
'tandem connection' between *any* two xPEs along the path of a
multisegment PW, or only between adjacent xPEs?
[Nurit] sorry for this. It is possible to set up a PW TC between any two
xPEs along the paths (as we said one or more PW segments). 

JD:  I think it was understood that there was going to be a terminology
cleanup.
[Nurit] I think we are referring to a LSP segment or 'one or more PW
segments', but this is implemented using TC as was proposed by the JWT.
TC has the construct of hierarchies using label stacking at the edges of
the TC. This is a new architectural functional element that needs to be
defined IMO in the MPLS-TP framework. Please refer to my mail on this
from a few weeks ago. TCME is used to monitor the TC and the protection
domain is used to protect the TC.

JD: Again, I think you misunderstood me.  I was talking about multiple
LSPs within a single containing hierarchical LSP.  Your original
statement was that this was not a tandem connection.I.e., "We do not
preclude LSP hierarchies to have TE links and aggregation of LSPs. But
this is something else."
[Nurit] There is probably misunderstanding. In TC we have 1:1 mapping in
order to monitor and protect the LSP (in a specific level)

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 22:54:13 +0200

Hi Lou,
We need TTL games for traffic that span a wider path than the segment.
(either a nested TC or end-to-end traffic).
We need TTL games for OAM messages that need to be directed to MIPs. 
Best regards,
Nurit

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 22:38
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Loa Andersson; MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Nurit,

Thanks,
Lou

> > The alternative is, as you suggest, that the TTL must be massaged.
For

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2008 16:58:38 -0400

John,
         I thought TTL was used to direct the OAM to a transit 
LSR.  I don't see how what you're describing works covers this case 
(which is the problem stated in Loa's mail)...

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2008 16:59:45 -0400

So this means we're back to my question.  What happens to the TTL 
when a protection path is in use?

Lou

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Oct 2008 23:08:03 +0200

I guess that we established that the is one case that don't
if you try to do ttl-expiration

put the GAL on top and the swapped label below, when you receive
the GAL, go to slow path, look at the label below and perform the
actions you would have if it were a fast path LSP

I will on on airplane for the next 16 hours, so if you need to kill
for this please hold of a bit

/Loa

Lou Berger wrote:
> John,
>         I thought TTL was used to direct the OAM to a transit LSR.  I
> don't see how what you're describing works covers this case (which is
> the problem stated in Loa's mail)...
> 
> Lou
> 

-- 
Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:08:38 +0200

Hi Lou,
Irrespectively if it is the working or the protection TC, when the
end-to-end traffic reaches the TC it is label stacked. The TTL of the
stacked label should be set to any value which is higher than the number
of hops in the TC. The easy way is to set it with the max value (255).  
Please note that the protection segment should also be implemented as a
TC. We need to monitor its healthy, we may need to coordinate the
protection state between the edges of the segment, etc. 
Best regards,
Nurit

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 23:00
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Drake, John E; Lou Berger; MEAD team; Weingarten, Yaacov (NSN -
IL/Hod HaSharon)

Lou

At 04:50 PM 10/22/2008, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> >> > P.s. would have been nice if we were able to use one of those
'exp'
> >>(but
Label

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2008 17:17:46 -0400

Nurit,
         This sounds to me like MEP behavior.  What about MIP?

Lou

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:20:36 +0200

How MIPs relate to protection switching?
In protection, we are protecting the entire segment (TC) against any
failure across the segment. This may be detected by CC&CV between the
MEPs of the segment.

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 23:18
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Lou Berger; ext Drake, John E; MEAD team; Weingarten, Yaacov
(NSN - IL/Hod HaSharon)

Nurit,

Lou

At 05:08 PM 10/22/2008, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> > >> > I think this is a real problem too, I am surprised that not
many
> > >>people
OAM

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:29:04 +0200

If you want to send an OAM message to a MIP, set the TTL as the number
of hops you need to transmit. This information should be provisioned to
the MEP. 
But this does not relate to protection switching. 

-----Original Message-----
Sent: Wednesday, October 22, 2008 23:21
To: ext Lou Berger

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 23:18
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Lou Berger; ext Drake, John E; MEAD team; Weingarten, Yaacov
(NSN - IL/Hod HaSharon)

Nurit,

Lou

many
OAM

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Oct 2008 17:31:01 -0400

As I read Loa's original mail, F could be a MEP or a MIP.  Are you 
saying it can only be a MEP?  If so, why does TTL come into play at all???

Lou

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:34:19 +0200

TTL plays a game for OAM messages directed to MIPs and for end-to-end
traffic.
Loa's original mail (at least as I understood it) referred to a
protection of a segment.! Protection is handled by the edge nodes of the
segment. 
OAM (dependent on the specific message) can be directed to MEPs or MIPs.

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 23:31
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Lou Berger; ext Drake, John E; MEAD team; Weingarten, Yaacov
(NSN - IL/Hod HaSharon)

As I read Loa's original mail, F could be a MEP or a MIP.  Are you 
saying it can only be a MEP?  If so, why does TTL come into play at
all???

Lou

At 05:20 PM 10/22/2008, Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> > >nee hierarchical LSP, contains two LSPs, the LSP being monitored
and
> >the
> > >inband OAM channel monitoring it.  If one held one's head just
right,
>I
> > > >>I'll be more than happy to provide (but not before the first
week
>of
> > > >>November) some slides on how it can be implemented. Please
advise
>if
> > > >> > Failing this, maybe we need to look at a non-TTL mechanism
for

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 22 Oct 2008 17:44:35 -0400

As I understood Loa's email, it was protection based on fast-reroute.
If we are not deprecating fast-reroute based protection, accessing to
MIPs for OAM using
the ttl is an issue.

/himanshu

-----Original Message-----
Sent: Wednesday, October 22, 2008 5:34 PM

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]]
Sent: Wednesday, October 22, 2008 23:31
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Lou Berger; ext Drake, John E; MEAD team; Weingarten, Yaacov
(NSN - IL/Hod HaSharon)

Lou

and
right,

> > > >hierarchy) help without either playing some TTL games at one of 
> > > >the TC's endpoints, or moving to a non-TTL dependent OAM
>approach.
> > > >
week
advise

> > > >> > [mailto:[email-masked]] On Behalf Of ext Shah,

> > > >> > Himanshu

for

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:54:23 +0200

As I understood it was for segment based protection. It was Adrian that
extended this for FRR. Loa says: " I've a question about how will
ttl-expiration work with for Label 13 in the case of segement
protection."

Again, the proposal was to have TC to implement OAM in different nested
levels and segment based protection. With TC, the construct of LSP
hierarchies is used with 1:1 mapping between the LSP and TC.
For OAM messages on a TC between MEPs, label 13 is enough. For OAM
messages on a TC between MEP and MIP, we need the combination of Label
13 and the right TTL setting.
Protection of a segment is performed by the edges of the TC. Protection
switching does not relate to MIPs. It can be triggered by the absence of
3 consecutive CC&CV messages (between MEPs), by a RSVP-TE error
notification message, by PSC (APS), by physical layer detection,
administrative request. 
For PSC, label 13 is enough. For end-to-end traffic we need to label
stack the traffic when going through a TC with setting the TTL values to
a value bigger than the number of hops in the segment. 

Please let me know if you need further clarification. 

-----Original Message-----
From: ext Shah, Himanshu [mailto:[email-masked]] 
Sent: Wednesday, October 22, 2008 23:45
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Lou Berger
Cc: MEAD team; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] ttl-expiration question

/himanshu

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]]
Sent: Wednesday, October 22, 2008 23:31
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Lou Berger; ext Drake, John E; MEAD team; Weingarten, Yaacov
(NSN - IL/Hod HaSharon)

Lou

and
right,

week
advise

for

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 23 Oct 2008 00:56:14 +0200

Nurit,

> ttl-expiration work with for Label 13 in the case of segement

It is at the end of your reply email (and also this one).

See further comments in-line [hvh]

> levels and segment based protection.

[hvh] the original intent of TC was to monitor a section of an LSP
that falls under the responsability of different operator or
operator domain.
In addition TC can be used for SNC protection..

> With TC, the construct of LSP

[hvh] that is a possible solution.

> For OAM messages on a TC between MEPs, label 13 is enough.

[hvh which MEPs do you refer to: the MEPs of the original LSP or
the MEPs of the TC (which have to be used in case of TC stacking).

> For OAM messages on a TC between MEP and MIP, we need the
 > combination of Label 13 and the right TTL setting.

[hvh] messages between MEP and MIP *always* use TTL.
(the other option is *never* but then another way has to be
found to enable a MEP to talk to a MIP).

> notification message, by PSC (APS), by physical layer detection,

[hvh] the latter (administrative request) is included in APS.

> For PSC, label 13 is enough. 

[hvh] APS == OAM == label 13 (+ ACH)

> For end-to-end traffic we need to label stack the traffic when
 > going through a TC with setting the TTL values to

[hvh] why? between the endpoints of a TC there may also be MIPs.
In case of label stacking (i.e. creating a new network layer) the
OAM frames received at the ingress will be transported as if they
are client data.
In case of changing the ME-level the OAM frames are examined only
if they are of the same ME-level.

Best regards, Huub.

Snipped to Loa's original email.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 23 Oct 2008 01:08:13 +0200

Inline

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Huub van
Helvoort
Sent: Thursday, October 23, 2008 00:56
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Nurit,

[hvh] that is a possible solution.
[Nurit] This was the proposal of the JWT and was the basis for our work.

[NUrit] MEPs of the TC.

[hvh] messages between MEP and MIP *always* use TTL.
(the other option is *never* but then another way has to be
found to enable a MEP to talk to a MIP).
[Nurit] You need Label 13 as well. It is the combination of TTL and
label 13.

[hvh] the latter (administrative request) is included in APS.
[Nurit] Not necessarily. You can have administrative request without
implementing APS or what I call PSC.

[hvh] APS == OAM == label 13 (+ ACH)
[Nurit] This is exactly the intention.

[hvh] why? between the endpoints of a TC there may also be MIPs.
[Nurit] I am talking about end-to-end traffic!
In case of label stacking (i.e. creating a new network layer) the
OAM frames received at the ingress will be transported as if they
are client data. 
[Nurit] Correct and the value of the TTL needs to be higher than the
numbers of nodes in the TC.
In case of changing the ME-level the OAM frames are examined only
if they are of the same ME-level.
[Nurit] Correct. In MPLS-TP we talked about label 13 at BoS immediately
after the label that is being monitored. 

Best regards, Huub.

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 Oct 2008 07:19:34 -0400

Yaacov,
         So what happens when the protection LSP merges at E rather than D?
Thanks,
Lou

At 03:13 AM 10/23/2008, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
>Hi all,
>
>As I understood the original question and the "obvious" solution that is
>being proposed:
>
>We have a LSP, with label 'a1', from node 'A' to node 'H' below: and we
>target an OAM message to MIP 'F' by setting the TTL=4, it reaches F with
>TTL=terminate
>
>+---+    +---+    +---+    +---+    +---+    +---+    +---+    +---+
>| A |<-->| B |<-->| C |<-->| D |<-->| E |<-->| F |<-->| G |<-->| H |
>+---+    +---+    +---+    +---+    +---+    +---+    +---+    +---+
>Lbl=a1   Lbl=a1   Lbl=a1   Lbl=a1   Lbl=a1   Lbl=a1   Lbl=a1   Lbl=a1
>TTL=4    TTL=3    TTL=2    TTL=1    TTL=T
>
>Now if the connection between node 'C' and 'D' fails and is protected by
>the protection LSP that follows from 'C' to 'W' to ...'Z' to 'D', with
>label 'b1' - then we get:
>
>+---+    +---+    +---+        +---+    +---+    +---+    +---+    +---+
>| A |<-->| B |<-->| C |        | D |<-->| E |<-->| F |<-->| G |<-->| H |
>+---+    +---+    +---+        +---+    +---+    +---+    +---+    +---+
>    Lbl=a1   Lbl=a1  |Lbl=b1,a1   | Lbl=a1   Lbl=a1
>    TTL=4    TTL=3   |TTL=255(2)  | TTL=1    TTL=T
>                     |            |
>                   +---+        +---+
>                   | W |        | Z |
>                   +---+        +---+
>                     |Lbl=b1,a1   | Lbl=b1,a1
>                     |TTL=254(2)  | TTL=252(2)
>                   +---+        +---+
>                   | X |--------| Y |
>                   +---+        +---+
>                       Lbl=b1,a1
>                       TTL=253(2)
>
>Presumably, Node 'Z' will pop the TC (hierarchial LSP) label and
>"remember" the lower level TTL and decrement it before passing the OAM
>message to 'D' on its way to MIP 'F'.
>
>Is this correct?
>
>Thanx
>Yaacov
>
>
> > Sent: Wednesday, October 22, 2008 23:54
> > To: ext Shah, Himanshu; ext Lou Berger
> > extended this for FRR. Loa says: " I've a question about how will ttl-
> > expiration work with for Label 13 in the case of segement protection."
> >
> > switching does not relate to MIPs. It can be triggered by the absence
>of 3
> > consecutive CC&CV messages (between MEPs), by a RSVP-TE error
>notification
> > message, by PSC (APS), by physical layer detection, administrative
>request.
>stack
> > the traffic when going through a TC with setting the TTL values to a
>value
> > bigger than the number of hops in the segment.
> >
> > > >Please note that the protection segment should also be implemented
>as
> > a
> > > >Cc: ext Drake, John E; Lou Berger; MEAD team; Weingarten, Yaacov
>(NSN
> > -
> > > >IL/Hod HaSharon)
> > > > > >> > example of segment protection, it has to be performed at
>the
> > >PLR.
> > > > > >> > The question
> > > > > >>here

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 23 Oct 2008 14:02:31 +0200

Hi,

I have some additional questions:

--1-- how can the MEP at node C (for the TC) communicate
       with a MIP in e.g. node Y?

--2-- if the link between nodes X and Y is again protected,
       or has another TC because it is in yet another domain
       how does this affect the TTL?

Regards, Huub.
------------------

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 23 Oct 2008 19:29:37 +0200

I think that what was misunderstood is that a protection domain which
includes a working and protecting "segments" consists of two TCs, one
for the working segment and one for the protection segment. The TCs may
be monitored, each by its own TCME.
If PSC/APS messages are exchanges between the peers they are transmitted
over the TC.
End-to-end traffic is transmitted via the active TC, i.e. it is label
stacked when the traffic reaches the TC and label popped when it exits
the TC. 
TTL value is preserved for each label at the relevant label stack entry
in the frame. 

-----Original Message-----
From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) 
Sent: Thursday, October 23, 2008 09:13
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'ext Shah, Himanshu'; 'ext
Lou Berger'
Cc: 'MEAD team'

Hi all,

Is this correct?

Thanx
Yaacov

> messages on a TC between MEP and MIP, we need the combination of Label
13
> and the right TTL setting.
of 3
notification
request.
stack
value
as
(NSN
the

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 23 Oct 2008 19:43:32 +0200

Protection domain is defined between two nodes, and it includes a
working and protecting "segments" consists of two TCs between the two
nodes, one for the working segment and one for the protection segment.
That means that they are always merge at the end of the segment. The TCs
may be monitored, each by its own TCME.
If PSC/APS messages are exchanges between the peers they are transmitted
over the TC.
End-to-end traffic is transmitted via the active TC, i.e. it is label
stacked when the traffic reaches the TC and label popped when it exits
the TC.

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Thursday, October 23, 2008 13:20
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Shah, Himanshu; ext Lou
Berger; MEAD team

Yaacov,
         So what happens when the protection LSP merges at E rather than
D?
Thanks,
Lou

At 03:13 AM 10/23/2008, Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>target an OAM message to MIP 'F' by setting the TTL=4, it reaches F
with
ttl-
of
> > > > > >At 03:52 PM 10/22/2008, Sprecher, Nurit (NSN - IL/Hod
HaSharon)
> > > >wrote:
> > > > > >>if we don't understand exactly how the mechanism I'm
supposed
>to
> > > > > >> > [mailto:[email-masked]] On Behalf Of
Adrian
> > > > > >> > Not just in segment protection as you describe, but also
in
> > >fast
> > > > > >> > - the ability to make other than unit modifications to
the
> > TTL
> > > > > >> >> -----| A |-----| B |-----| C |-----| D |-----| E |-----|
F
> > > >|-----
> > > > > >> >> -----| A |-----| B |--x--| C |-----| D |-----| E |-----|
F
> > > >|-----

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 23 Oct 2008 20:11:29 +0200

Hi,
1. By originating an OAM message in C at the layer of the TC between C
and D, including label 13 and TTL 3. 
2. A TC is considered as one hop for traffic (including OAM traffic)
that was generated prior to the edge of the TC (i.e. is not originated
at the edge of the TC but in one of the previous nodes). This is based
on the construct of LSP hierarchies (with a specific case of 1:1 mapping
and not aggregation of many LSPs). In LSP hierarchy this is considered a
TE link. One hop. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Huub van
Helvoort
Sent: Thursday, October 23, 2008 14:03
To: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Hi,

Regards, Huub.
------------------

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 Oct 2008 16:36:27 -0400

The requirement for the *working* path to hierarchy (i.e., a pushed 
label) between the PLR and merge node is news to me.  Am I the only 
one surprised by this?

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 23 Oct 2008 23:10:40 +0200

1. we are not talking about requirements but on architectural solution.
2. Are you referring to FRR? I am referring to segment based protection.
You need to define a TC on the segment in order to monitor it and to
synchronize the protection state between the edges of the segment. 
3. Regarding FRR, I issued the question about bi-directional protection
switching. 

-----Original Message-----
From: ext Lou Berger [mailto:[email-masked]] 
Sent: Thursday, October 23, 2008 22:36
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext Shah, Himanshu; ext
Lou Berger; MEAD team

ttl-
of
HaSharon)
supposed
Adrian
in
the
F
F

---

From: Loa Andersson <[email-masked]>
Date: Tue, 28 Oct 2008 10:55:29 +0100

Lou,

I thinkl it is clear that it won't work, in the included txt-file I
redrawn the pictures some.

But the conclusion is that we have case(s>) where ttl-expiration
won-t work, so we need to drop it and find something else.

/Loa

-- 
Loa Andersson

comments inline ... 

> target an OAM message to MIP 'F' by setting the TTL=4, it reaches F with

this one is almost ok, but I think the practice is that in managing ttl's 
is that if the will become zero in the next node and that node is not the
termination point you don't forwd the packet, also the label is not the 

  A:       B:       C:       D:       E:       F:       G:       H:
> Lbl=a1   Lbl=a2   Lbl=a3   Lbl=a4   Lbl=a5   Lbl=a6   Lbl=a7   Lbl=a8
> TTL=6    TTL=5    TTL=4    TTL=3    TTL=2    tt=T

however the changes is cosmetic (the "A:" decribes the label stack coming 
out from node A).

> label 'b1' - then we get:

with the same changes - we'll get this:

                                 D:
                                 lbl=b5 (pop)
                                 lbl=a3 swap to a4
                                 ttl=3 
> | A |<-->| B |<-->| C |        | D |<------->| E |<-->| F |<-->| G |<-->| H |
  A:       B:         |C:          |           E:       F:
> Lbl=a1   Lbl=a2     |Lbl=b1,a3   |Z:         Lbl=a5   lbl=no op
> TTL=6    TTL=5      |TTL=255(4)  |lbl=b5,a3  TTL=2    ttl=T
>                     |            |ttl=251(4)
>                   +---+        +---+
>                   | W |        | Z |
>                   +---+        +---+
                      |W:          | Y:
>                     |Lbl=b2,a3   | Lbl=b4,a3
>                     |TTL=254(4)  | TTL=252(4)
                       X:
>                      Lbl=b3,a3
>                      TTL=253(4)
works just fine :) , but actually it why mpls link protection (local 
repair) always works.

Some of the statements on this thread indicates that segment protection
"just" re-invents link protection as it has been used in MPLS for 
long time is that right, if so where is still the case of node protection
(which also works with MPLS) 

                                          E:
                                          lbl=b1 (pop)
                                          lbl=a3 swap to a4
                                          ttl=3 
> | A |<-->| B |<-->| C |        | D |<-->| E |<-->| F |<----->| G |<-->| H |
  A:       B:         |C:                   |           F:     G:
> Lbl=a1   Lbl=a2     |Lbl=b1,a3            |Z:         Lbl=a4 lbl=no op
> TTL=6    TTL=5      |TTL=255(4)           |lbl=b1,a3  TTL=2  ttl=T
>                     |                     |ttl=251(4)
>                   +---+                 +---+
>                   | W |                 | Z |
>                   +---+                 +---+
                      |W:                   | Y:
>                     |Lbl=b2,a3            | Lbl=b1,a3
>                     |TTL=254(4)           | TTL=252(4)
>                   +---+                 +---+
>                   | X |-----------------| Y |
>                   +---+                 +---+
                       X:
>                      Lbl=b2,a3
>                      TTL=253(4)

So in this case the ttl-expiry method over-shoots with one node

please note that there another quirk here, how does E know that
it is supposed to swap a3 for a5? That should require some protocol.

>                       TTL=253(3)

yes - but it is not the generic case

can't we just agree to drop a non-functional construct and go find
something that works

/Loa

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 29 Oct 2008 13:27:03 +0100

Hi Loa,

You  wrote:

> Lou,
> 
> I think it is clear that it won't work, in the included txt-file I

It can be solved by using the level mechanism in the Maintenance
Entity: MEL

At the ingress of the protected <section> the MEL is decremented
and at the egress it is incremented.
OAM frames will only be considered and processed if they are at
the same MEL.
If they are at a higher MEL they are passed transparently (including
the TTL) this makes it independent of the number of nodes between
the ingress and egress of the protected <section>.
It does not matter whether the working path is used or the protecting
path.

Cheers, Huub.

==========================

snipped to keep the email short.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 29 Oct 2008 15:35:17 +0100

Huub,

yet another counter :), installed to mend something that was
not broken from the start.

where does the MEL-counter ride, in the GAL?

/Loa

-- 
Loa Andersson

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 29 Oct 2008 07:48:53 -0700

Huub,

In this scheme, for unidirectional P2P and P2MP, how are OAM packets
'passed transparently' from egress to ingress and how are OAM packets
from either ingress or egress delivered to intermediate nodes, which I
understood to be a requirement?

Thanks,

John 

>From: Loa Andersson [mailto:[email-masked]] 
>Sent: Wednesday, October 29, 2008 7:35 AM
>To: [email-masked]; MEAD team
>> At the ingress of the protected <section> the MEL is decremented and 
>> at the egress it is incremented.
>> OAM frames will only be considered and processed if they are at the 
>> same MEL.
>> the TTL) this makes it independent of the number of nodes 
>between the 
>> ingress and egress of the protected <section>.

---

From: Lou Berger <[email-masked]>
Date: Wed, 29 Oct 2008 10:51:04 -0400

Also, this assumes the *working* path is also using LSP hierarchy 
from the PLR to merge point.  Yes, we can make this work with GMPLS 
segment recovery with some very minor additional definition. *but* it 
is incompatible with FRR!

Lou

---

From: George Swallow <[email-masked]>
Date: Wed, 29 Oct 2008 12:01:59 -0400

I think I mostly agree with Nurit here....

> use it also for protection switching?

I won't use the term tandem-connection since I am not completely sure of
what people mean by that.  I'll use Hierarchical LSP instead.

When we did the JWT work, nesting LSPs in a hierarchy was both assumed and
was used as a corner-stone of how the TTL expiration would work for MPLS-TP.
It was never stated that the mechanism would translate over to the rest of
MPLS without some alterations.

I do not recall anyone saying that LSPs would be mapped 1-1 to LSPs further
down the hierarchy.  Such an idea goes against all notions of scalability.
If someone wants to place that restriction in their product, please go ahead
(as long as you don't work for my company :-).

For MPLS-TP (other than path protection) we can have only link repair.  That
is a repair always goes between two nodes that were originally adjacent in
the LSP.  If they are adjacent at the physical link level, the link can be
repaired via another physical link between those two nodes or via nesting
within another LSP that also goes between those two nodes.  This preserves
the TTL count.

The same is true for LSP hops are nested in the original configuration.  The
connection over which they are nested will have a working and protect LSP.
Note that the number of hops in the working and protect LSPs need not be the
same.

I see no reason to change the OAM mechanisms that were agreed.  The fact
that they do not apply to bypass node-repair or to detour lsps with
different numbers of hops is something that we just deal with.  We already
have mechanisms that work.  If the new mechanisms cannot be applied here, so
be it.

...George

---

From: Loa Andersson <[email-masked]>
Date: Wed, 29 Oct 2008 17:09:59 +0100

George,

> within another LSP that also goes between those two nodes.  This preserves

so you are saying that an attempt to reach a MIP using the
ttl-expiration method will fail if we have a node failure (immediate
adjacent node) even if the MIP is further down the path?

/Loa

-- 
Loa Andersson

---

From: David Ward <[email-masked]>
Date: Wed, 29 Oct 2008 11:13:01 -0500

George -

If we use the OAM to pass the message that  the service is in a  
bypass node repair or detour'ing situation, an endpoint can calculate  
the proper TTL that will be expired at the proper point. It doesn't  
seem correct that if you don't know where the fault occurred and how  
many new hops were introduced that one would expect the original TTL  
expiration "count" to work properly.

Clearly, we could get fancier and precalculate all possible bypass  
scenarios and given the "in bypass/detour mode" and the location of  
the fault, we'd know the proper TTL to use but, that makes my head  
explode and I find it easier to simply use a traceroute or the moral  
equivalent to figure it out dynamically.

I strongly prefer that we don't go back to the original T-MPLS idea  
where we have to inspect every packet....

-DWard

---

From: George Swallow <[email-masked]>
Date: Wed, 29 Oct 2008 12:51:32 -0400

Loa -

> adjacent node) even if the MIP is further down the path?

In MPLS-TP, node failures are protected via Path protection.  This
protection can be applied end-to-end or to any segment routed over a
hierarchical connection where the working LSP goes through the node in
question and the protect does not.

What you are asking for is something that was not in the requirements as
communicated to the JWT.

Note that for the rest of MPLS, where a control plane is assumed, there are
many solutions to the problem.

...George

---

From: George Swallow <[email-masked]>
Date: Wed, 29 Oct 2008 12:56:29 -0400

Dave -

On 10/29/08 12:13 PM, "David Ward" <[email-masked]> wrote:

<snip>

> where we have to inspect every packet....

IIRC, in the JWT, that was called option B.

...George

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 29 Oct 2008 18:44:35 +0000

> the TTL is set correctly at F.
Loa

I looked through the thread and maybe I needed some context from the
MEAD meeting, but I don't understand what you are trying to achieve
here.

Why are we using ttl exp to deliver the packet OAM pkt to F rather than
it's address?

What sort of OAM pkt is this and what sort of service are you trying
to achieve?

Stewart

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 29 Oct 2008 21:19:38 +0100

Hi Loa,

> not broken from the start.

Using ME levels is not new, it is used in Carrier class
Ethernet, see Y.1731, to provide TCM.

> where does the MEL-counter ride, in the GAL?

If you still have a copy of G.8114 it was proposed to use
the EXP bits for that purpose.
Since we know that the purpose of the EXP bits was misunderstood
another field has to be allocated in the OAM frame (next to the
TTL field?).

Using the ME levels for TCM saves a label on the stack
for each TCM layer.

Regards, Huub.

===============================

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 29 Oct 2008 22:34:01 +0100

Hi Loa,
I think it could be very beneficial to have a technical (non-official)
discussion in general and specificically on this topic.
Can we arrange such a meeting during the Minneapolis meeting (before
Thursday)? That can be very helpful to make some progress after the
discussions.
Best regards,
Nurit

-----Original Message-----
Sent: Wednesday, October 29, 2008 16:35

Huub,

/Loa

-- 
Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Thu, 30 Oct 2008 16:08:30 +0100

> Ethernet, see Y.1731, to provide TCM.

did not mean it was new in itself, just new as a construct to
sort out ttl-expiration
> another field has to be allocated in the OAM frame (next to the

are you saying that each time a packet enters a new MEL the node has
to dig into the label stack of every packet to find out *if* there is
a GAL and if so decrement or increment the MEL? remember the
pop-inspect-push discussion?

/Loa

-- 
Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 30 Oct 2008 18:23:08 +0100

Hi,

1.    I think it is a better to use a name that can be generalized also
for the case of one-or-more PW segement(s).

2.    Unfortunately I could not participate in the JWT, but most of you
are the ones that generated the slides. In slide 55 (V.22) it is
explicitly written " TCM LSP label does not represent a true LSP, No LSP
Mux (1:1 mapping)". For me every thing that is written in the slides,
look as it was agreed by the JWT.  

If we want to make it more efficient (in terms of scalability), it may
be useful to re-think about it and have the generalize case of an
aggregation. It looks to me that indeed it can work well and enhance the
behavior but still I need to think about this further. 

3.    I agree that the number of hops in the working and protect LSPs
need not be the same. But both the working and the protection entities
are terminated at the same nodes (where the TC/path-hierarchy is
terminated) so we have no issue with the TTL of the end-to-end path.

Best regards,

Nurit

-----Original Message-----
From: ext George Swallow [mailto:[email-masked]] 
Sent: Wednesday, October 29, 2008 18:02
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson
Cc: MEAD team; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] ttl-expiration question

 

When we did the JWT work, nesting LSPs in a hierarchy was both assumed
and

was used as a corner-stone of how the TTL expiration would work for
MPLS-TP.

It was never stated that the mechanism would translate over to the rest
of

I do not recall anyone saying that LSPs would be mapped 1-1 to LSPs
further

down the hierarchy.  Such an idea goes against all notions of
scalability.

If someone wants to place that restriction in their product, please go
ahead

For MPLS-TP (other than path protection) we can have only link repair.
That

is a repair always goes between two nodes that were originally adjacent
in

the LSP.  If they are adjacent at the physical link level, the link can
be

repaired via another physical link between those two nodes or via
nesting

within another LSP that also goes between those two nodes.  This
preserves

the TTL count.

The same is true for LSP hops are nested in the original configuration.
The

connection over which they are nested will have a working and protect
LSP.

Note that the number of hops in the working and protect LSPs need not be
the

same.

different numbers of hops is something that we just deal with.  We
already

have mechanisms that work.  If the new mechanisms cannot be applied
here, so

be it.

...George

>> With TC, we use the MPLS construct of hierarchical LSPs, and each

> level

>> include the new architectural functional element 'Tandem Connection'

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 30 Oct 2008 20:08:23 +0100

Hej Loa,

> did not mean it was new in itself, just new as a construct to

OK, I understand and can explain more if necessary.

> pop-inspect-push discussion?

No, within an ME (or path layer) the OAM frames are at the same level
in the stack, the differentiation is in the MEL field of the OAM
frames of the same ME. The MEL determines how they are processed.

OAM frames outside the ME (client layers) are further down the stack
but are not inspected inside the ME because they are transported as
user frames.

Cheers, Huub.

---

From: George Swallow <[email-masked]>
Date: Thu, 30 Oct 2008 15:59:38 -0400

Huub -

I'm getting a bit lost in terminology.

What does ME stand for?  I'm familiar with G.802.1ag terms.  They have
things call a MD (Management Domain) and MD Level.  Are these the same as
what you call ME and MEL?

...George

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 30 Oct 2008 21:07:33 +0100

Hi,

I hope it is OK that I jump into the discussion......

As far as I recall we did not refer to MEL at all in our OAM documents.

We defined a ME (Maintenance Entity) which bounds the OAM
responsibilities and represents a network or sub-network in a specific
network layer that is being monitored and maintained, and in which OAM
messages are exchanged. 

A ME includes a set of two or more Maintenance End Points (MEPs) which
reside at the boundaries of an ME, and a set of zero or more Maintenance
Intermediate Points (MIPs) which reside within the Maintenance Entity.
Please note that the case of more than two MEPs refer to a P2MP path.

Best regards,

Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext George Swallow
Sent: Thursday, October 30, 2008 22:00
To: [email-masked]; Loa Andersson
Cc: MEAD team
Subject: Re: [Mpls-interop] ttl-expiration question

Huub -

things call a MD (Management Domain) and MD Level.  Are these the same
as

...George

[email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 30 Oct 2008 22:53:16 +0100

Hi George,

You wrote:

> What does ME stand for?

Maintenance Entity.

It is defined in draft-busi-mpls-tp-oam-framework
and will be included in the Rosetta Stone draft I an preparing.
(maybe I have to include IEEE terminology as well)

> I'm familiar with G.802.1ag terms.  They have

MD == ME Group, a group of ME.
MD level == MEL

Kind regards, Huub.

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Thu, 30 Oct 2008 20:59:55 -0500

Hi,

To be more precise and also consistent with the terminologies in draft
G.8114 and Y.1731 (carrier class Ethernet OAM),

ME = Maintenance Entity

MEG = ME Group

MEP = MEG End Point 

MIP = MEG Intermediate Point

Regards,

Kam

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)
Sent: Thursday, October 30, 2008 4:08 PM
To: ext George Swallow; [email-masked]; Loa Andersson
Cc: MEAD team; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] ttl-expiration question

Hi,

Best regards,

Nurit

-----Original Message-----

Huub -

...George

[email-masked]

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 31 Oct 2008 11:43:28 -0700

Snipped, comments inline 

>>> 
>>> I won't use the term tandem-connection since I am not 
>completely sure 
>>> of what people mean by that.  I'll use Hierarchical LSP instead.
>>> 
>>> When we did the JWT work, nesting LSPs in a hierarchy was both 
>>> assumed and was used as a corner-stone of how the TTL 
>expiration would work for MPLS-TP.

JD:  Within an Hierarchical LSP, TTL expiration is unnecessary.  The
Generic ACH label itself is sufficient to identify the packet as an OAM
packet at the LSP's endpoints.  To reach the ingress for the cases of
unidirectional P2P and P2MP, as well as to reach intermediate nodes
along the LSP's path, I thought that we had agreed in the interim
meeting that routing the OAM packets was required. 

>>> It was never stated that the mechanism would translate over to the 
>>> rest of MPLS without some alterations.
>>> 
>>> further down the hierarchy.  Such an idea goes against all 
>notions of scalability.
>>> If someone wants to place that restriction in their product, please 
>>> go ahead (as long as you don't work for my company :-).

JD:  Amen.  This is what I have been saying all along.

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 31 Oct 2008 23:09:10 +0100

Hi John,

FYI draft-busi-mpls-tp-oam-framework explains the MEP and MIP
and the use of TTL to reach a MIP from a MEP.

Regards, Huub.
=========================