Subject: Re: [Mpls-interop] Who will be in Geneva?

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 01 Dec 2008 22:16:50 +0000

Adrian,

On 27/11/2008 22:27, "Adrian Farrel" <[email-masked]> wrote:
> I ended up with a modest list of MPLS-TP design team folk willing to
> squander their evenings in Geneva working on drafts. Must be that the Swiss
> night life is too exciting!

Or that there is no Q.Whisky in SG15 ;-)

> Lastly, I would like to see if I can understand the issues with the OAM
> techniques proposed. Can we continue to use TTL? Does the idea of using
> nesting for all OAM segments really hold up? Is the OAM cart in danger of
> driving the protection hobbyhorse (pardon my mixed metaphore).

I'm no OAM expert (I leave that to Tom :-) ) but I am yet to be convinced by
nesting all OAM segments for the reason that it sounds complicated and that
means to me that it will be expensive to run and to scale.  It also sounds
like I'd have to have my network constructed in a particular way to be able
to use OAM which means even in the best run network I will at some point not
be able to run OAM when I need it (and the customer is screaming at me)
because the network wasn't constructed correctly (either by design or actual
configuration != design).

Ben

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

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 00:46:20 +0100

Hi Ben
Scalability of TC (or whatever we call it) is basically if you have 1:1
mapping between TC and LSP. But if you have 1:n mapping TC and many LSPs
the main concern can be solved. 
If you define TC in reasonable areas (e.g. across a domain in a
multi-domain network) and the TC aggregate multiple LSPs then IMO the
construction of TC is the cleanest one and works well with OAM and with
protection.
Best regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Ben
Niven-Jenkins
Sent: Tuesday, December 02, 2008 00:17
To: Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Adrian,

> driving the protection hobbyhorse (pardon my mixed metaphore).

I'm no OAM expert (I leave that to Tom :-) ) but I am yet to be
convinced by
nesting all OAM segments for the reason that it sounds complicated and
that
means to me that it will be expensive to run and to scale.  It also
sounds
like I'd have to have my network constructed in a particular way to be
able
to use OAM which means even in the best run network I will at some point
not
be able to run OAM when I need it (and the customer is screaming at me)
because the network wasn't constructed correctly (either by design or
actual
configuration != design).

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 00:59:14 +0100

BTW, isn't it (TC/lsp-hierarchy) the same principle as we have in GMPLS
segment protection?

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
Sent: Tuesday, December 02, 2008 01:46
To: ext Ben Niven-Jenkins; Adrian Farrel; [email-masked]
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] Who will be in Geneva?

Hi Ben

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

Adrian,

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 08:28:42 -0000

As I may have said before, we must be very careful with the term "segment".
It has a completely different meaning almost.

RFC 4873 segment protection does not use hierarchy. This is for the 
"obvious" reason that you cannot do hierarchy in most/many switching 
technologies.

RFC 4090 protection does use hierarchy and protects what many might call a 
segment.

A
----- Original Message ----- 
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>; "ext 
Ben Niven-Jenkins" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; <[email-masked]>
Sent: Monday, December 01, 2008 11:59 PM
Subject: RE: [Mpls-interop] Who will be in Geneva?

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Tuesday, December 02, 2008 01:46
To: ext Ben Niven-Jenkins; Adrian Farrel; [email-masked]
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: RE: [Mpls-interop] Who will be in Geneva?

Hi Ben

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

Adrian,

Ben

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 02 Dec 2008 10:15:46 +0100

Hi Ben and Nurit,

We definitly have to have a f-2-f discussion about TC, I think
there is still some confusion.

> the main concern can be solved. 

TC is 1:1 related to a single LSP, this is how TC is defined
in the Transport environment. A TC can be created either by
stacking or by using the MEG level methodology (also used in
the transport ethernet)

> construction of TC is the cleanest one and works well with OAM and with

The TC aggregate is not a TC anymore, it should IMHO be referred
to as a tunnel.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 09:20:12 -0000

Hi Huub.

> The TC aggregate is not a TC anymore, it should IMHO be referred

Yes!

Which is not to say that it is not a useful construct for reducing OAM 
overhead.

I think (OK, I know) that I suggested we avoid using the TC language as I 
thought we would find it unhelpful. Perhaps when we meet to go through this, 
we can draw pictures and work out the language later?

A

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 10:32:00 +0100

I agree with you that currently TC is 1:1, but I can see no reason why
we can not extend it to scale better and use it for multiple LSPs that
cross the same part of physical path (i.e. segment) and have the same
constraints........
I agree that we should think also about a better name......
F2F meeting can really help 

-----Original Message-----
From: ext Huub van Helvoort [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 11:16
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi Ben and Nurit,

Cheers, Huub.

>> nesting for all OAM segments really hold up? Is the OAM cart in
danger
> of

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 02 Dec 2008 10:34:50 +0100

Hi Adrian,

>> The TC aggregate is not a TC anymore, it should IMHO be referred

OK.

> Which is not to say that it is not a useful construct for reducing OAM 

I agree.

> I think (OK, I know) that I suggested we avoid using the TC language as 
> I thought we would find it unhelpful. Perhaps when we meet to go through 
> this, we can draw pictures and work out the language later?

And document it in draft Rosetta.

Cheers, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 10:36:59 +0100

Hi,
I agree that we need to find a better name......
What about the figure in the second slide of the attached?
If multiple LSPs transmit via the same physical path in the first domain
and have the same constraints, why cannot we aggregate them and run OAM
per the aggregated in the first domain?
Best regards,
Nurit

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 11:20
To: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi Huub.

Yes!

I think (OK, I know) that I suggested we avoid using the TC language as
I 
thought we would find it unhelpful. Perhaps when we meet to go through
this, 
we can draw pictures and work out the language later?

A

---

From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
Date: Tue, 2 Dec 2008 10:45:24 +0100

All,
So this is for the "protection LSP" or is this for the working TCtunnels?
In any case, assume that there is only a single TCTunnel between the two clouds (in the picture Nurit provided -thanks for the pics) how is the head-end informed about any malfunctioning detected via OAM of the intermediated TCTunnel?
There should then be an OAM interworking between the S-PEs and the head-end?
Assume that the intermediate TCTunnel has multiple different LSPs that termiate at different PEs? How are they informed of any failures?
In the both cases that could work via AIS but then we would need potentially need more information in the AIS.

./
Lieven

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 02 December 2008 10:37
To: Adrian Farrel; [email-masked]
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi,
I agree that we need to find a better name......
What about the figure in the second slide of the attached?
If multiple LSPs transmit via the same physical path in the first domain and have the same constraints, why cannot we aggregate them and run OAM per the aggregated in the first domain?
Best regards,
Nurit

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, December 02, 2008 11:20
To: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi Huub.

> The TC aggregate is not a TC anymore, it should IMHO be referred to as 
> a tunnel.

Yes!

Which is not to say that it is not a useful construct for reducing OAM overhead.

I think (OK, I know) that I suggested we avoid using the TC language as I thought we would find it unhelpful. Perhaps when we meet to go through this, we can draw pictures and work out the language later?

A

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 09:47:19 -0000

Right.
Picture looks good.
As we all seem to be agreeing, let's find a new name for TC to avoid 
confusing it with (or being limited by) the previous definition within the 
ITU. (We certainly don't want to try to change the definition of TC because 
we will really have fun if we do that :-)

The discussion we need to have face-to-face next week when Loa is in 
Switzerland will relate to how TTL methods of OAM are 
improved/unchanged/made worse by the use of hierarchical LSPs in the event 
of protection activities.

A
----- Original Message ----- 
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Cc: "ext Ben Niven-Jenkins" <[email-masked]>; 
<[email-masked]>; "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" 
<[email-masked]>
Sent: Tuesday, December 02, 2008 9:36 AM
Subject: RE: [Mpls-interop] Who will be in Geneva?

Hi,

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]]
Sent: Tuesday, December 02, 2008 11:20
To: [email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi Huub.

Yes!

A

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 11:35:57 +0100

Hi,
We are talking about TC and not TCM :-)
TC (until we have a better name) is used for OAM as well as for protection. 
Best regards,
Nurit

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 12:34
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Nurit, all

as stated in Minneapolis, I believe, at least for clarity, that we
should not directly link TC to P&R.
TCM is an OAM related concept not a resiliency one.

-m

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 11:39:27 +0100

Somehow I find my self in a circle (I need ring protection :-))
We have been in this discussion many times...........
To protect a part of a path we need to define a TC for the working and the protection part (two TCs . If we want we can run OAM over the TC and use it as a trigger for a protection switching. OAM will need to run over each of the TC (TCM :-)). These TCs will be used also for sending the PSC (APS) messages....

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 12:34
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Nurit, all

-m

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 12:02:06 +0100

First, protection switching in MPLS-TP is independent of the control plane...we can have protection switching even in the absence of a CP. 
Second, GMPLS segment protection really uses LSP hierarchy for protecting a segment......
TC (or what ever name you select) provides you a clean architectural way to initiate and terminate messages for a part of a path (segment). This can be used for OAM, protection and maybe other purposes in the future as well.
Nurit

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 12:51
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Well, that is exactly what I am saying ...
the TCs you mention are for doing OAM
In GMPLS one does not need any TC to do segment recovery.

-m

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 11:29:40 -0000

> First, protection switching in MPLS-TP is independent of the control
> plane...we can have protection switching even in the absence of a CP.

Yes

> protecting a segment......

No!

There are many solutions.
I have warned about using the term "segment protection".
I will warn again.

GMPLS "Segment protection" (RFC 4873) does NOT (that is, not, not, not) use 
hierarchy.
(Did I say "not"?)

> TC (or what ever name you select) provides you a clean architectural
> way to initiate and terminate messages for a part of a path (segment).
> This can be used for OAM, protection and maybe other purposes in
> the future as well.

I also wish you would stop using the term TC because it is just confusing 
things.

If what you want to say is that hierarchcial agregation is useful, then we 
will agree.
It can be used to provide OAM for a part of an LSP path.
It can be used to aggregate OAM for a set of LSPs that are parallel for part 
of their paths.
It can be used to aggregate protection for a set of LSPs that are parallel 
for part of their paths.

This is LSP hierarchy. No need for other terms.

Adrian

---

From: "BOCCI Matthew" <[email-masked]>
Date: Tue, 2 Dec 2008 12:37:14 +0100

Now I find myself going in a circle! :)

I can accept that TCM is monitoring of a tandem connection, which has been defined to protect part of a path. But what if I want to monitor some part of a path of an LSP or MS-PW independently of end-to-end OAM, but not provision an explicit tandem connection to provide protection.

Is that still TCM, or is it something else?

Thanks

Matthew

> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 02 December 2008 10:39
> To: VIGOUREUX MARTIN
> Cc: [email-masked]
> Somehow I find my self in a circle (I need ring protection 
> :-)) We have been in this discussion many times...........
> To protect a part of a path we need to define a TC for the 
> working and the protection part (two TCs . If we want we can 
> run OAM over the TC and use it as a trigger for a protection 
> switching. OAM will need to run over each of the TC (TCM 
> :-)). These TCs will be used also for sending the PSC (APS) 
> messages....
> 
> From: ext Martin Vigoureux 
> [mailto:[email-masked]]
> as stated in Minneapolis, I believe, at least for clarity, 
> that we should not directly link TC to P&R.
> > BTW, isn't it (TC/lsp-hierarchy) the same principle as we have in 
> > GMPLS segment protection?
> > 
> > Scalability of TC (or whatever we call it) is basically if you have 
> > 1:1 mapping between TC and LSP. But if you have 1:n mapping TC and 
> > many LSPs the main concern can be solved.
> > construction of TC is the cleanest one and works well with OAM and 
> > with protection.
> > Best regards,
> > Nurit
> > 
> >> squander their evenings in Geneva working on drafts. Must 
> be that the
> > Swiss
> > convinced by nesting all OAM segments for the reason that it sounds 
> > complicated and that means to me that it will be expensive 
> to run and 
> > to scale.  It also sounds like I'd have to have my network 
> constructed 
> > in a particular way to be able to use OAM which means even 
> in the best 
> > run network I will at some point not be able to run OAM 
> when I need it 
> > (and the customer is screaming at me) because the network wasn't 
> > constructed correctly (either by design or actual configuration != 
> > design).
> > 
> > Ben
> >

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 12:37:59 +0100

The main issue with "LSP Hierarchy" is that it is strange to use it for
a part of MS-PW (one or more segments of a PW). 

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 13:30
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Martin Vigoureux
Cc: ext Ben Niven-Jenkins; [email-masked]
Subject: Re: [Mpls-interop] Who will be in Geneva?

Yes

No!

GMPLS "Segment protection" (RFC 4873) does NOT (that is, not, not, not)
use 
hierarchy.
(Did I say "not"?)

> This can be used for OAM, protection and maybe other purposes in

I also wish you would stop using the term TC because it is just
confusing 
things.

If what you want to say is that hierarchcial agregation is useful, then
we 
will agree.
It can be used to provide OAM for a part of an LSP path.
It can be used to aggregate OAM for a set of LSPs that are parallel for
part 
of their paths.
It can be used to aggregate protection for a set of LSPs that are
parallel 
for part of their paths.

Adrian

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 2 Dec 2008 07:13:29 -0800

If we say that the OAM channel is associated with the containing LSP,
then we could have a tandem connection as currently defined (1:1 with an
LSP) while having the benefits of 1 OAM channel for N contained LSPs.  

>From: Huub van Helvoort [mailto:[email-masked]] 
>Sent: Tuesday, December 02, 2008 1:16 AM
>The TC aggregate is not a TC anymore, it should IMHO be 
>referred to as a tunnel.
>
>Cheers, Huub.
>
>> run network I will at some point not be able to run OAM when 
>I need it

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 15:22:10 -0000

The term that is crystallizing is "path segment tunnel" (PST)

Does that do the job?

Adrian

----- Original Message ----- 
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 02, 2008 3:13 PM
Subject: Re: [Mpls-interop] Who will be in Geneva?

---

From: <[email-masked]>
Date: Tue, 2 Dec 2008 16:36:18 +0100

Hello.

And a node terminating a PST would be a PSTN? ;-)

All the same, it seems much more intuitive than TC for an IETF reader.

Julien

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel

Does that do the job?

Adrian

---

From: Loa Andersson <[email-masked]>
Date: Tue, 02 Dec 2008 16:37:22 +0100

> And a node terminating a PST would be a PSTN? ;-)

that is actually true isn't it :)

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Redback Networks                      phone: +46 8 632 77 14
An Ericsson Company
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 2 Dec 2008 07:41:00 -0800

Adrian,

Upon reflection, do we really need either the term 'tandem connection'
or the term 'path segment tunnel'?  We have the terms 'hierarchical
LSP', 'containing LSP', and 'contained LSP'.  All we are talking about
is adding an OAM channel to an LSP.

That said, how about 'path segment LSP (PSL)' which is defined to be a
containing hierarchical LSP with an associated inband OAM channel?

Thanks,

John

>From: Adrian Farrel [mailto:[email-masked]] 
>Sent: Tuesday, December 02, 2008 7:22 AM
>To: Drake, John E; [email-masked]; Sprecher, Nurit (NSN - 
>IL/Hod HaSharon)
>>>>> Lastly, I would like to see if I can understand the 
>issues with the
>>>> OAM

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 2 Dec 2008 16:43:28 +0100

And then will we have 'path segment PW (psp)?
We need a general term that identifies a segment of a path (either of
LSP or of a MS-PW)..........
BR,
Nurit

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 17:41
To: Adrian Farrel; [email-masked]; Sprecher, Nurit (NSN - IL/Hod
HaSharon)

Adrian,

Thanks,

John

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 15:56:29 -0000

I suggested "tunnel" to convey the hierarchical business.

PSL does not clearly show whether it is a segment of an LSP, or an LSP that 
contains a segment of an LSP. I believe that PST helps resolve that.

Further, Nurit's question is answered by PST.

A

----- Original Message ----- 
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Drake, John E" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 02, 2008 3:43 PM
Subject: RE: [Mpls-interop] Who will be in Geneva?

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]]
Sent: Tuesday, December 02, 2008 17:41
To: Adrian Farrel; [email-masked]; Sprecher, Nurit (NSN - IL/Hod
HaSharon)

Adrian,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 2 Dec 2008 08:06:05 -0800

Okay, that's fine. 

>Sent: Tuesday, December 02, 2008 7:56 AM
>To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Drake, John E; 
>[email-masked]
>PSL does not clearly show whether it is a segment of an LSP, 
>or an LSP that contains a segment of an LSP. I believe that 
>PST helps resolve that.
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 3 Dec 2008 13:13:49 +0100

Adrian,

I partially agree with you.

LSP hierarchy can be used to:
A) aggregate OAM for a set of LSPs that are parallel for part of their
paths
B) aggregate protection for a set of LSPs that are parallel 
for part of their paths.

TC (or whatever name you wish to give it) can be used to:
A) provide OAM for a part of an LSP path
B) provide protection for a part of an LSP pat

Italo

> Sent: Tuesday, December 02, 2008 12:30 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); VIGOUREUX MARTIN

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 3 Dec 2008 13:13:46 +0100

I agree 100% with Huub.

I think we need to clarify the concept (irrespectively from the name)
first, the we can understand the solution and finally we can give an
appropriate name.

The concept is the following: if I have a connection from A to Z, I
would like to monitor (from fault and performance management) that
connection (and only that one) between two intermediate points (let us
call them I and J).

There are many potential solutions to this problem. One solution is to
rely on the MEG Level, like in Ethernet, but it has some impacts on the
forwarding plane. In fact it is required that J is able to distinguish
the OAM packets monitoring the TC (that it has to terminate) and the OAM
packets monitoring the e2e connections that have to be forwarded like
user data packets.

In MPLS-TP, there is a clear requirement that the MPLS forwarding
paradigm, as defined in RFC 3031, MUST not be changed. As a consequence
the only mechanism I can imagine to solve the TC requirement is the one
based on label stacking.

Given the definition of TC, there is a 1:1 mapping between the TC and
the end-to-end connection the TC refers to.

The fact that the same mechanism used for tunneling (i.e. label
stacking) is also used for TCM is just by chance and should not create
confusion between them. Tunneling and TC are different architectural
concepts and managed differently.

Italo

> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: Tuesday, December 02, 2008 10:16 AM
> >> nesting for all OAM segments really hold up? Is the OAM 
> cart in danger
> > of

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 3 Dec 2008 13:13:51 +0100

Nurit,

Thanks for the figure. If I understand it correctly I think we need to
updated some terminology.

In my understanding there is only one LSP from the left to the right
node and therefore we are in the SS-PW scenario.

The nodes at the boundary of the two clouds are not swapping any PW
label and therefore they are not S-PE but LSR.

Am I missing something?

Thanks, Italo

> Sent: Tuesday, December 02, 2008 10:37 AM

---

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Dec 2008 13:20:42 +0100

Renaming the thread - a little late but anyway ...

at risk asking the obvious, since I'm still reading through the
thread?

Nurit,

In your figure will the S-PEs label swap the label on
E2E tunnels LSP? Or is the same label showing up at the
second T-PE?

/Loa

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> ------------------------------------------------------------------------
> 

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Dec 2008 12:46:45 -0000

Yes, Italo, you are right.

> connection (and only that one) between two intermediate points (let us

Good.

I think 1:1 is a special case of 1:n.
There is nothing in the proposal that precludes 1:1 association of 
connection with monitoring entitity (i.e. end-to-end LSP with PST).
But we want to make sure that we have a generic solution defined so that one 
technique (the PST) can be applied to:
- aggregation
- 1:n monitoring
- 1:1 monitoring

> the only mechanism I can imagine to solve the TC requirement is the one

That is why we suggest PST (which is just a label stack) and is available to 
satisfy other requirements as well.

> the end-to-end connection the TC refers to.

Yes. That is the definition of a TC that exists in the ITU and I think it 
would be unwise to try to change it.

That is why we suggest to not use the term at all. If we really want to 
continue to refer to a TC, we might add text to say that "operating a PST in 
a 1:1 relationship with the end-to-end LSP achieves the same function as 
that of a TC as specified by the ITU-T"

> concepts and managed differently.

Agreed completely.
But it is nice to leverage the "just by chance" to make:
- simple implementations
- re-use of toolkit
- harmonized architecture

Have we converged (not merged, because merging is not allowed)?

Adrian