Subject: [Mpls-interop] PST.ppt

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 3 Dec 2008 13:35:20 +0100

Oops......my mistake.......here is the updated figure......

The intention was to refer to a SS-PW. Accidentally I referred to T-PE
and S-PE. 

We can provide also another figure for the MS-PW case.

Note also that the figure is adapted with the new term - PST

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 14:21
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Adrian Farrel; [email-masked]; Weingarten, Yaacov (NSN - IL/Hod
HaSharon); [email-masked]
Subject: PST question: Was (Re: [Mpls-interop] Who will be in Geneva?)

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:

> 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 

------------------------------------------------------------------------

> _______________________________________________

> Mpls-interop mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/mpls-interop

-- 

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: Loa Andersson <[email-masked]>
Date: Wed, 03 Dec 2008 13:41:20 +0100

Nurit,

ok fine, however ...

In your figure will the  2nd and 3rd PEs label swap the label on
E2E tunnels LSP? Or is the same label showing up at the  4th PE?

/Loa

--

---

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

Loa,

Why would this be any different from normal LSR behavior?

P1 sees only the PST labels
PEs pop the PST label and see the e2e label and process it as normal.

Cheers,
Adrian
----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>; <[email-masked]>; 
"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, December 03, 2008 12:41 PM
Subject: Re: PST.ppt

---

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Dec 2008 14:39:58 +0100

Adrian,

I don't think that it should any different.

So 2nd PE from the left pops the tunnel label and swaps the inner
label and then pushes the new tunnel label. Is that what you say?

Same for the 3rd PE?

/Loa

Adrian Farrel wrote:
> ----- Original Message ----- From: "Loa Andersson" <[email-masked]>
> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
> <[email-masked]>; <[email-masked]>

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 3 Dec 2008 14:00:33 -0000

> I don't think that it should any different.

Good

> label and then pushes the new tunnel label. Is that what you say?

Yup. Normal LSR behavior.

> Same for the 3rd PE?

Why would this be any different from normal LSR behavior?   :-)

A

---

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Dec 2008 15:08:24 +0100

Adrian,

> Why would this be any different from normal LSR behavior?   :-)

I don't look for or hope for any difference ;).

Assuming there is a PST from the 3rd to the 4th PE also?

What is protected from e.g. 3rd PE to the 4th PE the entire containing
tunnel or the each separate contained tunnel?

/Loa

--

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 3 Dec 2008 15:11:00 +0100

The intention is to protect the PST....and switch over the tunneled LSPs
into a protected PST when there is a fault condition along the working
PST.

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 16:08
To: Adrian Farrel
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked]
Subject: Re: PST.ppt

Adrian,

/Loa

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

--

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 15:14:55 +0100

Nurit,

clarification question :-)
is the intent to protect the PST or to protect
to LSPs and be able to run OAM (at large) on segments of
the protecting LSPs once the switch over has been done?
thanks

-m

---

From: Loa Andersson <[email-masked]>
Date: Wed, 3 Dec 2008 06:17:44 -0800

Nurit,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Wednesday, December 03, 2008 3:11 PM
To: ext Loa Andersson; Adrian Farrel
Cc: [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] PST.ppt

The intention is to protect the PST....and switch over the tunneled

Loa > Contained LSPs is equal to tunneled LSP? Correct?

/Loa

This is
LSPs

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Wednesday, December 03, 2008 16:08
To: Adrian Farrel
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];

Adrian,

/Loa

reducing

--

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 06:30:58 -0800

I think there would be a working and a protecting PST, both with an inband OAM channel.  When the working PST is up, it will contain a set of one or more LSPs (or PWs).  When the working PST fails, the set of one or more LSPs is moved to the protecting PST.

Presumably, the inband OAM channel on the working PST is used to detect its failure and the inband OAM channel on the protecting PST is used to coordinate the movement of the LSPs (or PWs) to it.  

>From: Martin Vigoureux [mailto:[email-masked]] 
>Sent: Wednesday, December 03, 2008 6:15 AM
>Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>is the intent to protect the PST or to protect to LSPs and be 
>able to run OAM (at large) on segments of the protecting LSPs 
>once the switch over has been done?
>thanks
>
>-m
>
>> LSPs into a protected PST when there is a fault condition along the 
>> working PST.
>> 
>>>>>>> The intention was to refer to a SS-PW. Accidentally I 
>referred to
>> T-PE
>>>>>>> and S-PE.
>>>>>>>
>>>>>>> Cc: Adrian Farrel; [email-masked]; Weingarten, 
>Yaacov (NSN - 
>>>>>>> IL/Hod HaSharon); [email-masked]
>>>>>>>>> The TC aggregate is not a TC anymore, it should IMHO be 
>>>>>>>>> referred to as a tunnel.
>>>>>>>
>>>>>>>> Yes!
>>>>>>>
>>>>>>>> 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: Wed, 3 Dec 2008 14:33:14 -0000

Loa,

You can protect a tunnel or an end-to-end LSP
However, halfway down a tunnel, you can only protect the tunnel (because you 
can't see the content)

A
----- Original Message ----- 
From: "Loa Andersson" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>; 
<[email-masked]>; "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, December 03, 2008 2:08 PM
Subject: Re: PST.ppt

>>>>>>> through

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 15:42:00 +0100

John,

I understand but I do not understand the need for dual protection
(i.e. having working and protecting LSPs and in addition a working
and a protecting PST)
I think we only need working and protecting LSPs and PSTs around
them. The difference may be subtle but may be not in terms of operations.
By reading working and protecting I implicitly read
that a switch over will happen between the two and I guess we want
to swith LSPs from a PST to another one but we do not need (want)
to switch a PST to another PST. Do we?
If I am not clear enough, let me know. :-)

-m

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 06:49:46 -0800

Martin,

There is a working PST, a protecting PST, and a set of one or more LSPs (or PWs).  When the working PST is up, it contains the set of one or more LSPs (or PWs).  When the working PST is down, the protecting PST contains the set of one or more LSPs (or PWs).

Thanks,

John 

>Sent: Wednesday, December 03, 2008 6:42 AM
>To: Drake, John E
>Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); 
>[email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>I understand but I do not understand the need for dual 
>protection (i.e. having working and protecting LSPs and in 
>addition a working and a protecting PST) I think we only need 
>working and protecting LSPs and PSTs around them. The 
>difference may be subtle but may be not in terms of operations.
>By reading working and protecting I implicitly read that a 
>switch over will happen between the two and I guess we want to 
>swith LSPs from a PST to another one but we do not need (want) 
>> I think there would be a working and a protecting PST, both 
>with an inband OAM channel.  When the working PST is up, it 
>will contain a set of one or more LSPs (or PWs).  When the 
>working PST fails, the set of one or more LSPs is moved to the 
>protecting PST.
>> 
>> Presumably, the inband OAM channel on the working PST is 
>used to detect its failure and the inband OAM channel on the 
>protecting PST is used to coordinate the movement of the LSPs 
>(or PWs) to it.  
>> 
>>> is the intent to protect the PST or to protect to LSPs and 
>be able to 
>>> run OAM (at large) on segments of the protecting LSPs once 
>the switch 
>>> over has been done?
>>> thanks
>>>
>>> -m
>>>
>>>>>>>>>> and have the same constraints, why cannot we aggregate them 
>>>>>>>>>> and
>>>> run
>>>>>>>>> OAM
>>>>>>>>>
>---------------------------------------------------------------------
>>> -
>>>> --
>>>>>>>>>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 15:55:10 +0100

John,

if I read you correctly does this mean that the switch-over is performed
at the PST level and not anymore at the LSP level (and so that there are
no more working and protecting LSPs, only LSPs which are transparently 
switched when the PST that tunnels them is switched from primary to 
secondary)?

-m

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 07:38:25 -0800

Martin,

There could be working and protecting LSPs as well, but that would be completely transparent to the PSTs, and the operation of the PST protection switch would be completely transparent to the contained LSPs.  I.e., if the working PST fails and the contained LSPs are moved to the protecting PST, none of the contained LSPs would be aware of the move and none of them would initiate a protection switch to their protecting LSPs.

The PST endpoints need to be aware of the individual LSPs, so there would need to be some coordination between them as the set of contained LSPs changes.

Thanks,

John 

>Sent: Wednesday, December 03, 2008 6:55 AM
>To: Drake, John E
>if I read you correctly does this mean that the switch-over is 
>performed at the PST level and not anymore at the LSP level 
>(and so that there are no more working and protecting LSPs, 
>only LSPs which are transparently switched when the PST that 
>tunnels them is switched from primary to secondary)?
>
>-m
>
>Drake, John E a écrit :
>> Martin,
>> 
>> There is a working PST, a protecting PST, and a set of one 
>or more LSPs (or PWs).  When the working PST is up, it 
>contains the set of one or more LSPs (or PWs).  When the 
>working PST is down, the protecting PST contains the set of 
>one or more LSPs (or PWs).
>> 
>> Thanks,
>> 
>> John
>> 
>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; 
>>> Weingarten,Yaacov (NSN - IL/Hod HaSharon)
>>> and a protecting PST) I think we only need working and protecting 
>>> LSPs and PSTs around them. The difference may be subtle but may be 
>>> not in terms of operations.
>>> By reading working and protecting I implicitly read that a switch 
>>> over will happen between the two and I guess we want to swith LSPs 
>>> from a PST to another one but we do not need (want) to switch a PST 
>>> to another PST. Do we?
>>> with an inband OAM channel.  When the working PST is up, it will 
>>> contain a set of one or more LSPs (or PWs).  When the working PST 
>>> fails, the set of one or more LSPs is moved to the protecting PST.
>>> protecting PST is used to coordinate the movement of the LSPs (or 
>>> PWs) to it.
>[email-masked]; 
>>>>>>>>>>> Subject: PST question: Was (Re: [Mpls-interop] Who 
>will be in
>>>>>> Geneva?)
>>>>>>>>>>>> If multiple LSPs transmit via the same physical 
>path in the 
>>>>>>>>>>>> first
>>>>>>>>>>> domain
>>>>>>>>>>>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 16:45:27 +0100

John

ok, then what I am saying is that there should not be a notion of
working and protecting PST.
There should be working LSPs tunnelled in a PST and protecting LSPs
tunnelled in some other PST but I do not believe that this second
PST should be the protecting of the first.
Hope this clarifies.

-m

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 3 Dec 2008 16:52:57 +0100

You could say the same ting for PWs that are transmitted via LSPs. 
You do not protect the LSP, there is no protection and working LSPs but there are working tunneled PWs and protection PWs. 
I think we have working PST and protection PST to protect the LSPs that are tunneled via the PSTs......
I hope this clarifies......

-----Original Message-----
From: ext Martin Vigoureux [mailto:[email-masked]] 
Sent: Wednesday, December 03, 2008 17:45
To: Drake, John E
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] PST.ppt

John

-m

---

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Dec 2008 16:55:40 +0100

Arian,

where is "halfway down the tunnel - between PE1 and PE2 (counting from
left and between PE3 and PE4? I would agree to that, but between PE2 and
PE3 we are "out of the tunnel" - given that I understand what is said
what I can see from the picture. Right?

Adrian Farrel wrote:
> However, halfway down a tunnel, you can only protect the tunnel (because
> you can't see the content)
> 
> A

--

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 07:58:06 -0800

Martin,

The notion of protecting groups of LSPs for scalability has been part of LSP hierarchy since its inception.  We just never worked out the details of endpoint coordination before.

I was under the impression that working and protecting PSTs were required for MPLS TP, but I perhaps jumped to an incorrect conclusion.  Does the JWT have an opinion on this?

Thanks,

John
>Sent: Wednesday, December 03, 2008 7:45 AM
>To: Drake, John E
>ok, then what I am saying is that there should not be a notion 
>of working and protecting PST.
>There should be working LSPs tunnelled in a PST and protecting 
>LSPs tunnelled in some other PST but I do not believe that 
>this second PST should be the protecting of the first.
>Hope this clarifies.
>
>-m
>
>Drake, John E a écrit :
>> Martin,
>> 
>> There could be working and protecting LSPs as well, but that 
>would be completely transparent to the PSTs, and the operation 
>of the PST protection switch would be completely transparent 
>to the contained LSPs.  I.e., if the working PST fails and the 
>contained LSPs are moved to the protecting PST, none of the 
>contained LSPs would be aware of the move and none of them 
>would initiate a protection switch to their protecting LSPs.
>> 
>> The PST endpoints need to be aware of the individual LSPs, 
>so there would need to be some coordination between them as 
>the set of contained LSPs changes.
>> 
>> Thanks,
>> 
>> John
>> 
>>> performed at the PST level and not anymore at the LSP level (and so 
>>> that there are no more working and protecting LSPs, only LSPs which 
>>> are transparently switched when the PST that tunnels them 
>is switched 
>>> from primary to secondary)?
>>>
>>> -m
>>>
>>> Drake, John E a écrit :
>>>> Martin,
>>>>
>>> or more LSPs (or PWs).  When the working PST is up, it contains the 
>>> set of one or more LSPs (or PWs).  When the working PST is 
>down, the 
>>> protecting PST contains the set of one or more LSPs (or PWs).
>>>> Thanks,
>>>>
>>>> John
>>>>
>[email-masked]; 
>>>>>>> From: Martin Vigoureux 
>[mailto:[email-masked]]
>>>>>>>>>>> PEs pop the PST label and see the e2e label and 
>process it as
>>>>>>>> normal.
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Adrian
>>>>>>>>>>>>>> I think (OK, I know) that I suggested we avoid 
>using the TC
>>>>>>>> language
>>>>>>>>>>>>> as
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 17:00:18 +0100

Nurit, John,

so as to make sure I correctly understand your aim,
do you plan to use rfc4873 to establish the second PST?
thanks

-m

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 17:07:31 +0100

John,

I am aware of this ;-)

PST originates from the ITU-T concept of TC which is mostly used
to run OAM, but I may have missed something.
By saying that a PST can be a working or a protecting, I feel we
are going one step further (and I do not have a specific opinion
on that, just to clarify).
But if we are going that way, what is the new architectural concept?
This PST is a full blown lsp/tunnel, nothing else.

-m

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 08:12:14 -0800

>From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
>[mailto:[email-masked]] 
>Sent: Wednesday, December 03, 2008 7:53 AM
>To: ext Martin Vigoureux; Drake, John E
>Subject: RE: [Mpls-interop] PST.ppt
>
>You do not protect the LSP, there is no protection and working 
>LSPs but there are working tunneled PWs and protection PWs.

JD:  There could a working/protecting PW pair, each of which is bound to a working/protecting LSP pair.  An LSP protection switch underneath the working PW would be transparent to it, so the only time there would be a PW protection switch would be when both the working and protecting LSPs underneath the working PW failed.

>I think we have working PST and protection PST to protect the 
>LSPs that are tunneled via the PSTs......

JD:  This sounds like you are agreeing with me.

>[email-masked]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 07:58:06 -0800

Martin,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 07:58:06 -0800

Martin,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 08:18:02 -0800

Martin,

It will be some combination of new work, RFC 4873, the LSP hierarchy RFC, and the end to end recovery RFC.  As I indicated in a crossing e-mail, perhaps I am incorrect in saying that PST protection switching is required for MPLS TP, in which case we wouldn't work on it.

Thanks,

John
>Sent: Wednesday, December 03, 2008 8:00 AM
>Cc: Drake, John E; [email-masked]; Weingarten, Yaacov 
>(NSN - IL/Hod HaSharon)
>so as to make sure I correctly understand your aim, do you 
>plan to use rfc4873 to establish the second PST?
>thanks
>
>-m
>
>> You do not protect the LSP, there is no protection and 
>working LSPs but there are working tunneled PWs and protection PWs. 
>> I think we have working PST and protection PST to protect 
>the LSPs that are tunneled via the PSTs......
>> From: ext Martin Vigoureux 
>> Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>> tunnelled in some other PST but I do not believe that this 
>second PST 
>> should be the protecting of the first.
>> Hope this clarifies.
>> 
>> -m
>> 
>> Drake, John E a écrit :
>>> Martin,
>>>
>>> There could be working and protecting LSPs as well, but 
>that would be completely transparent to the PSTs, and the 
>operation of the PST protection switch would be completely 
>transparent to the contained LSPs.  I.e., if the working PST 
>fails and the contained LSPs are moved to the protecting PST, 
>none of the contained LSPs would be aware of the move and none 
>of them would initiate a protection switch to their protecting LSPs.
>>>
>>>> are transparently switched when the PST that tunnels them is 
>>>> switched from primary to secondary)?
>>>>
>>>> -m
>>>>
>>>> Drake, John E a écrit :
>>>>> Martin,
>>>>>
>contains the 
>protection

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 08:23:21 -0800

>Sent: Wednesday, December 03, 2008 8:08 AM
>To: Drake, John E

JD:  I suspected that you might 8->.

>
>PST originates from the ITU-T concept of TC which is mostly 
>used to run OAM, but I may have missed something.
>By saying that a PST can be a working or a protecting, I feel 
>we are going one step further (and I do not have a specific 
>opinion on that, just to clarify).

JD:  As I said, I may have jumped to an incorrect conclusion.

>This PST is a full blown lsp/tunnel, nothing else.

JD:  I think what we are adding is the notion of protecting groups of LSPs using LSP hierarchy.  These groups could be either segment protected, which is PST protection, or even end-to-end, which I haven't seen mentioned yet.

>
>-m
>
>Drake, John E a écrit :
>> Martin,
>> 
>> The notion of protecting groups of LSPs for scalability has 
>been part of LSP hierarchy since its inception.  We just never 
>worked out the details of endpoint coordination before.
>> 
>> I was under the impression that working and protecting PSTs 
>were required for MPLS TP, but I perhaps jumped to an 
>incorrect conclusion.  Does the JWT have an opinion on this?
>> 
>> Thanks,
>> 
>> John
>>> would be completely transparent to the PSTs, and the 
>operation of the 
>>> PST protection switch would be completely transparent to the 
>>> contained LSPs.  I.e., if the working PST fails and the contained 
>>> LSPs are moved to the protecting PST, none of the contained LSPs 
>>> would be aware of the move and none of them would initiate a 
>>> protection switch to their protecting LSPs.
>>> so there would need to be some coordination between them as the set 
>>> of contained LSPs changes.
>>>> Thanks,
>>>>
>>>> John
>>>>
>that a switch 
>>>>>>>>>>>>> P1 sees only the PST labels PEs pop the PST label and see 
>>>>>>>>>>>>> the e2e label and
>>> process it as
>>>>>>>>>> normal.
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Adrian
>>>>>>>>>>>>>>>> Mpls-interop mailing list [email-masked]

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 17:43:15 +0100

John,

> JD:  I suspected that you might 8->.
;-)

> JD:  As I said, I may have jumped to an incorrect conclusion.
Conversely, I may also have :-)

> JD:  I think what we are adding is the notion of protecting groups of LSPs using LSP hierarchy.  These groups could be either segment protected, which is PST protection, or even end-to-end, which I…
I see your point,
still, it more looks to me that it takes us farther from the
understanding I have of the original concept, but as emphasized
it may only be a question of understanding.
:-)

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 17:44:52 +0100

John,

I think we are indeed down to the point of having to answer the question
you raise:
Should the PSTs be protected or not?
My understanding is the following:
PSTs are entities used to monitor the liveliness and performance
of the LSPs they tunnel.
PSTs do so by in fact monitoring their own liveliness/performance.
In case a defect occurs the recovery is done at the LSP level.

As such my understanding was that PSTs need not be protected
but if my understanding is incorrect and/or we decide they should
be, I am fine :-)

-m

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 09:09:58 -0800

Very good - it's a question for the group 

>Sent: Wednesday, December 03, 2008 8:45 AM
>To: Drake, John E
>I think we are indeed down to the point of having to answer 
>the question you raise:
>PSTs are entities used to monitor the liveliness and 
>performance of the LSPs they tunnel.
>but if my understanding is incorrect and/or we decide they 
>should be, I am fine :-)
>
>-m
>
>Drake, John E a écrit :
>> Martin,
>> 
>> It will be some combination of new work, RFC 4873, the LSP 
>hierarchy RFC, and the end to end recovery RFC.  As I 
>indicated in a crossing e-mail, perhaps I am incorrect in 
>saying that PST protection switching is required for MPLS TP, 
>in which case we wouldn't work on it.
>> 
>> Thanks,
>> 
>> John
>>> Cc: Drake, John E; [email-masked]; Weingarten, Yaacov (NSN - 
>>> IL/Hod HaSharon)
>>> so as to make sure I correctly understand your aim, do you plan to 
>>> use rfc4873 to establish the second PST?
>>> thanks
>>>
>>> -m
>>>
>>> that would be completely transparent to the PSTs, and the operation 
>>> of the PST protection switch would be completely transparent to the

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 09:09:58 -0800

---

From: <[email-masked]>
Date: Wed, 3 Dec 2008 18:13:34 +0100

Hi.

Let me try to rephrase what I've understood (correct me if I'm wrong).

Your intend is to do segment recovery (RFC 4873) on a group of contained LSPs (from a PST1 to PST2) and NOT e2e recovery (RFC 4872) on PSTs, right? Would it be consistent with the procedure applying segment recovery to a piece of my PST? I fear it might be a mess in some cases, for instance when having a PST head end node (recovering at LSP level) being also a segment branching node (recovering at PST level)... 8-|

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Vigoureux

John,

-m

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 3 Dec 2008 09:27:58 -0800

Julien,

I actually think that PST protection would follow the model of RFC 4872, where the PST is an e2e LSP.  Doing segment protection of a PST hurts my head, but it would probably work.

Thanks,

John
>From: [email-masked] 
>[mailto:[email-masked]] 
>Sent: Wednesday, December 03, 2008 9:14 AM
>To: [email-masked]; Drake, John E
>Cc: [email-masked]
>Your intend is to do segment recovery (RFC 4873) on a group of 
>contained LSPs (from a PST1 to PST2) and NOT e2e recovery (RFC 
>4872) on PSTs, right? Would it be consistent with the 
>procedure applying segment recovery to a piece of my PST? I 
>fear it might be a mess in some cases, for instance when 
>having a PST head end node (recovering at LSP level) being 
>also a segment branching node (recovering at PST level)... 8-|
>
>Regards,
>
>Julien
>
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Martin Vigoureux
>
>John,
>

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 03 Dec 2008 18:34:45 +0100

if using p&r mechanisms then I agree that it should more be 4872 than
4873 (I introduced 4873 earlier and should have talked about 4872 in
place).
While talking about p&r, then I guess the bypass tunnel of the FRR
facility backup mode is a good candidate to be PST as well as. no?

-m

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 03 Dec 2008 19:09:40 +0000

My understanding is the same as Martin's - that the point of a PST(/TC) is
to monitor part of and end to end path, no more.

Although TCM has been part of ITU Recs for a long time, I'm not sure how
many operators actually implement it.  I'm pretty sure BT doesn't because it
makes the operations too complex but I don't look after our transport
networks so I could be wrong.

Ben

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 4 Dec 2008 06:33:05 -0500

TCM in SONET was never implemented (unusable), for SDH it was never used really that I know of (it had a hiccup in that it caused a service outage when writing the bytes). And there never was any protection defined based on using it.

For Ethernet 802.1ag levels (which is ITU's favored approach for MPLS-TP), there hasn't been any work yet done on defining protection based on it. I'm sitting in Geneva with an MEF/IEEE person and he says to carefully say that there is nothing precluding it, just no one is doing it yet. Most operators are looking at all the 802.1ag levels as overkill and way too complex to manage. MEF has decided to specify only needing to use 2 levels (or maybe it's 3 - we would need to check) for OAM. Again, no protection has been defined. And if ITU wants MPLS-TP based on ASON, then the protection domains can not overlap or cross domains. 802.1ag levels can. So if define protection, would need to also restrict how the levels are configured.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Wednesday, December 03, 2008 2:10 PM
To: Drake, John E; Martin Vigoureux
Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] PST.ppt

Ben

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 05 Dec 2008 14:26:35 +0100

Hi Deborah,

You wrote:

> TCM in SONET was never implemented (unusable),

Which was first: is is not documented in T1.105 hence it is not
implemented, or it was not used hence it was not necessary to
standardise it (in T1.105)?

> for SDH it was never used really that I know of

Based on my activity in a usenet newsgroup I recieved
from several different operators requests to help them
set it up.

> (it had a hiccup in that it caused a service outage when writing
 > the bytes).

That may have been a particular implementation, I have worked
on devices that did not have this problem.
I have also worked on work-arounds for those cases where the
HW did not support TCM and the service provider wanted to use
the features of TCM.

> And there never was any protection defined based on using it.

There is indeed confusion about what TCM is designed for.
It is designed for performance monitoring and fault localisation.

If you would like to protect the section you would create a
sub-network layer connection that provides the protection:
SNCP, which can be based on the same defects that are detected
by TCM, but can also use other defects hence SNC/I, SCN/N, etc.

> For Ethernet 802.1ag levels (which is ITU's favored approach for
> MPLS-TP), there hasn't been any work yet done on defining protection
> based on it. 

Because MEG levels are used for PM and FL.
If you need protection, create a SNC and protect that.

SNC protection is described in G.8031 for ethernet and G.808.1
is the generic description.

> I'm sitting in Geneva with an MEF/IEEE person and he
> says to carefully say that there is nothing precluding it, just no
> one is doing it yet. Most operators are looking at all the 802.1ag
> levels as overkill and way too complex to manage.

Isn't this dependent on which department in the operator company
one talks to?

> MEF has decided to
> specify only needing to use 2 levels (or maybe it's 3 - we would need
> to check) for OAM. Again, no protection has been defined. 

See previous comment.

> And if ITU wants MPLS-TP based on ASON, then the protection
 > domains can not overlap or cross domains.

Is it common practice to have protection switching across
domains?

> 802.1ag levels can. So if define protection, would need to also
 > restrict how the levels are configured.

That is part of the definition of the levels and their use.

Regards, Huub.

> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
>  Sent: Wednesday, December 03, 2008 2:10 PM To: Drake, John E; Martin
> Vigoureux Cc: [email-masked]; Weingarten,Yaacov (NSN - IL/Hod
> HaSharon) Subject: Re: [Mpls-interop] PST.ppt
> 
> My understanding is the same as Martin's - that the point of a
> PST(/TC) is to monitor part of and end to end path, no more.
> 
> Although TCM has been part of ITU Recs for a long time, I'm not sure
> how many operators actually implement it.  I'm pretty sure BT doesn't
> because it makes the operations too complex but I don't look after
> our transport networks so I could be wrong.
> 
> Ben
> 
> 
> 
>>> -----Original Message----- From: Martin Vigoureux
>>> [mailto:[email-masked]] Sent: Wednesday,
>>> December 03, 2008 8:45 AM To: Drake, John E Cc: Sprecher, Nurit
>>> (NSN - IL/Hod HaSharon); [email-masked]; Weingarten,
>>> Yaacov (NSN - IL/Hod HaSharon) Subject: Re: [Mpls-interop]
>>> PST.ppt
>>> 
>>> John,
>>> 
>>> I think we are indeed down to the point of having to answer the
>>> question you raise: Should the PSTs be protected or not? My
>>> understanding is the following: PSTs are entities used to monitor
>>> the liveliness and performance of the LSPs they tunnel. PSTs do
>>> so by in fact monitoring their own liveliness/performance. In
>>> case a defect occurs the recovery is done at the LSP level.
>>> 
>>> As such my understanding was that PSTs need not be protected but
>>> if my understanding is incorrect and/or we decide they should be,
>>> I am fine :-)
>>> 
>>> -m
>>> 
>>> Drake, John E a écrit :
>>>> Martin,
>>>> 
>>> hierarchy RFC, and the end to end recovery RFC.  As I indicated
>>> in a crossing e-mail, perhaps I am incorrect in saying that PST
>>> protection switching is required for MPLS TP, in which case we
>>> wouldn't work on it.
>>>> Thanks,
>>>> 
>>>> John
>>>>> -----Original Message----- From: Martin Vigoureux
>>>>> [mailto:[email-masked]] Sent: Wednesday,
>>>>> December 03, 2008 8:00 AM To: Sprecher, Nurit (NSN - IL/Hod
>>>>> HaSharon) Cc: Drake, John E; [email-masked];
>>>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon) Subject: Re:
>>>>> [Mpls-interop] PST.ppt
>>>>> 
>>>>> Nurit, John,
>>>>> 
>>>>> plan to use rfc4873 to establish the second PST? thanks
>>>>> 
>>>>> -m
>>>>> 
>>>>>> You could say the same ting for PWs that are transmitted
>>>>>> via LSPs. You do not protect the LSP, there is no
>>>>>> protection and
>>>>>> -----Original Message----- From: ext Martin Vigoureux
>>>>>> Sent: Wednesday, December 03, 2008 17:45 To: Drake, John E 
>>>>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon) Subject: Re:
>>>>>> [Mpls-interop] PST.ppt
>>>>>> 
>>>>>> John
>>>>>> 
>>>>>> ok, then what I am saying is that there should not be a
>>>>>> notion of working and protecting PST. There should be
>>>>>> working LSPs tunnelled in a PST and
>>> protecting LSPs
>>>>>> should be the protecting of the first. Hope this clarifies.
>>>>>> 
>>>>>> 
>>>>>> -m
>>>>>> 
>>>>>> Drake, John E a écrit :
>>>>>>> Martin,
>>>>>>> 
>>>>> none of the contained LSPs would be aware of the move and
>>>>> none of them would initiate a protection switch to their
>>>>> protecting LSPs.
>>>>>>>> -----Original Message----- From: Martin Vigoureux
>>>>>>>> Sent: Wednesday, December 03, 2008 6:55 AM To: Drake,
>>>>>>>> John E Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>>>> [email-masked];
>>>>>>>> Weingarten,Yaacov (NSN - IL/Hod HaSharon) Subject: Re:
>>>>>>>> [Mpls-interop] PST.ppt
>>>>>>>> 
>>>>>>>> John,
>>>>>>>> 
>>>>>>>> if I read you correctly does this mean that the
>>>>>>>> switch-over is performed at the PST level and not
>>>>>>>> anymore at the LSP
>>>>> level (and so
>>>>>>>> that there are no more working and protecting LSPs,
>>>>>>>> only
>>>>> LSPs which
>>>>>>>> are transparently switched when the PST that tunnels
>>>>>>>> them is switched from primary to secondary)?
>>>>>>>> 
>>>>>>>> -m
>>>>>>>> 
>>>>>>>> Drake, John E a écrit :
>>>>>>>>> Martin,
>>>>>>>>> 
>>>>>>>>>> -----Original Message----- From: Martin Vigoureux
>>>>>>>>>> Sent: Wednesday, December 03, 2008 6:42 AM To:
>>>>>>>>>> Drake, John E Cc: Sprecher, Nurit (NSN - IL/Hod
>>>>>>>>>> HaSharon);
>>>>> [email-masked];
>>>>>>>>>> Weingarten,Yaacov (NSN - IL/Hod HaSharon) Subject:
>>>>>>>>>> Re: [Mpls-interop] PST.ppt
>>>>>>>>>> 
>>>>>>>>>> John,
>>>>>>>>>> 
>>>>>>>>>> (i.e. having working and protecting LSPs and in
>>>>>>>>>> addition
>>>>> a working
>>>>>>>>>> and a protecting PST) I think we only need working
>>>>>>>>>> and
>>>>> protecting
>>>>>>>>>> LSPs and PSTs around them. The difference may be
>>>>>>>>>> subtle
>>>>> but may be
>>>>>>>>>> not in terms of operations. By reading working and
>>>>>>>>>> protecting I implicitly read that
>>>>> a switch
>>>>>>>>>> over will happen between the two and I guess we
>>>>>>>>>> want to
>>>>> swith LSPs
>>>>>>>>>> from a PST to another one but we do not need (want)
>>>>>>>>>> to
>>>>> switch a PST
>>>>>>>>>> to another PST. Do we? If I am not clear enough,
>>>>>>>>>> let me know. :-)
>>>>>>>>>> 
>>>>>>>>>> -m
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Drake, John E a écrit :
>>>>>>>>>> with an inband OAM channel.  When the working PST
>>>>>>>>>> is
>>> up, it will
>>>>>>>>>> contain a set of one or more LSPs (or PWs).  When
>>>>>>>>>> the
>>>>> working PST
>>>>>>>>>> used to detect its failure and the inband OAM
>>>>>>>>>> channel on the protecting PST is used to coordinate
>>>>>>>>>> the movement of the
>>>>> LSPs (or
>>>>>>>>>> PWs) to it.
>>>>>>>>>>>> -----Original Message----- From: Martin
>>>>>>>>>>>> Vigoureux
>>>>>>>>>>>> Sent: Wednesday, December 03, 2008 6:15 AM To:
>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc:
>>>>>>>>>>>> [email-masked]; Weingarten,Yaacov (NSN -
>>>>>>>>>>>> IL/Hod HaSharon) Subject: Re: [Mpls-interop]
>>>>>>>>>>>> PST.ppt
>>>>>>>>>>>> 
>>>>>>>>>>>> Nurit,
>>>>>>>>>>>> 
>>>>>>>>>>>> clarification question :-) is the intent to
>>>>>>>>>>>> protect the PST or to protect to LSPs and
>>>>>>>>>> be able to
>>>>>>>>>>>> over has been done? thanks
>>>>>>>>>>>> 
>>>>>>>>>>>> -m
>>>>>>>>>>>> 
>>>>>>>>>>>>> The intention is to protect the PST....and
>>>>>>>>>>>>> switch over the
>>>>>>>>>> tunneled
>>>>>>>>>>>>> LSPs into a protected PST when there is a
>>>>>>>>>>>>> fault condition
>>>>>>>>>> along the
>>>>>>>>>>>>> working PST.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -----Original Message----- From: ext Loa
>>>>>>>>>>>>> Andersson [mailto:[email-masked]] Sent: Wednesday,
>>>>>>>>>>>>> December 03, 2008 16:08 To: Adrian Farrel Cc:
>>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>>>>>>> [email-masked];
>>>>>>>>>>>>> Adrian Farrel wrote: I don't think that it
>>>>>>>>>>>>> should any different. Good
>>>>>>>>>>>>> 
>>>>>>>>>>>>> So 2nd PE from the left pops the tunnel label
>>>>>>>>>>>>> and swaps
>>>>>>>>>> the inner
>>>>>>>>>>>>> label and then pushes the new tunnel label.
>>>>>>>>>>>>> Is that
>>>>>>>> what you say?
>>>>>>>>>>>>> Same for the 3rd PE? Why would this be any
>>>>>>>>>>>>> different from normal LSR
>>>>> behavior?   :-)
>>>>>>>>>>>>> What is protected from e.g. 3rd PE to the 4th
>>>>>>>>>>>>> PE the entire
>>>>>>>>>>>> containing
>>>>>>>>>>>>> Adrian Farrel wrote: Loa,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> normal. Cheers, Adrian ----- Original Message
>>>>>>>>>>>>> ----- From: "Loa Andersson"
>>>>> <[email-masked]>
>>>>>>>>>>>>> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
>>>>>>>>>>>>>  <[email-masked]> Cc: "Adrian Farrel"
>>>>>>>>>>>>> <[email-masked]>;
>>>>>>>>>> <[email-masked]>;
>>>>>>>>>>>>> <[email-masked]>;
>>>>>>>>>>>>> <[email-masked]> Sent: Wednesday,
>>>>>>>>>>>>> December 03, 2008 12:41 PM Subject: Re:
>>>>>>>>>>>>> PST.ppt
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Nurit,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ok fine, however ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In your figure will the  2nd and 3rd PEs
>>>>>>>>>>>>> label swap
>>>>>>>>>> the label on
>>>>>>>>>>>>> E2E tunnels LSP? Or is the same label showing
>>>>>>>>>>>>> up at
>>>>>>>>>> the  4th PE?
>>>>>>>>>>>>> /Loa
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>>>>>>>>>>>> wrote: Oops......my mistake.......here is the
>>>>>>>>>>>>> updated
>>>>> figure......
>>>>>>>>>>>>> T-PE and S-PE.
>>>>>>>>>>>>> Note also that the figure is adapted with the
>>>>>>>>>>>>> 
>>>>> new term - PST
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -----Original Message----- From: ext Loa
>>>>>>>>>>>>> Andersson [mailto:[email-masked]] Sent: Wednesday,
>>>>>>>>>>>>> December 03, 2008 14:21 To: Sprecher, Nurit
>>>>>>>>>>>>> (NSN - IL/Hod HaSharon) Cc: Adrian Farrel;
>>>>>>>>>>>>> [email-masked]; Weingarten,
>>>>>>>>>>>> Yaacov (NSN -
>>>>>>>>>>>>> Geneva?) Renaming the thread - a little late
>>>>>>>>>>>>> but anyway ...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> at risk asking the obvious, since I'm still
>>>>>>>>>>>>> reading
>>>>>>>>>> through the
>>>>>>>>>>>>> thread?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Nurit,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi, I agree that we need to find a better
>>>>>>>>>>>>> name...... What about the figure in the
>>>>>>>>>>>>> second slide of
>>>>> the attached?
>>>>>>>>>>>>> first domain
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> Loa Andersson                         email: 
>>>>>>>>>>>>> [email-masked] Sr Strategy and
>>>>>>>>>>>>> Standards Manager            [email-masked] 
>>>>>>>>>>>>> Redback Networks                      phone:
>>>>>>>>>>>>> +46
>>>>> 8 632 77 14
>>>>>>>>>>>>> An Ericsson Company --
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 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] 
> _______________________________________________ Mpls-interop mailing
> list [email-masked] 
> _______________________________________________ Mpls-interop mailing
> list [email-masked] 

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Dec 2008 22:40:38 +0000

Colleagues,

What's the current view of how to support MPLS over MPLS-TP?

Do we put a PW in the middle (like draft-bryant) or do we just use the label
stack and have MPLS directly over MPLS-TP?

Advantage of the first is that it gives layer separation (e.g. If the two
layers are operated by different parties), advantage of the second is it's
probably a bit simpler.

Do the drafts we have say anything about the MPLS over MPLS-TP case? Same
for IP over MPLS-TP?

Thanks
Ben

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 10 Dec 2008 14:48:39 -0800

>From: Ben Niven-Jenkins [mailto:[email-masked]] 
>Sent: Wednesday, December 10, 2008 2:41 PM
>To: [email-masked]
>Subject: [Mpls-interop] MPLS over MPLS-TP
>
>Colleagues,
>
>Do we put a PW in the middle (like draft-bryant) or do we just 
>use the label stack and have MPLS directly over MPLS-TP?

JD:  I always thought this was a terrible idea.  Since MPLS-TP is a
particular MPLS profile and since we said that the MPLS dataplane
wouldn't be touched, I think we would either add entries to the stack
(MPLS), or place an IP packet after the stack (IP).

>
>Advantage of the first is that it gives layer separation (e.g. 
>If the two layers are operated by different parties), 
>advantage of the second is it's probably a bit simpler.
>
>Do the drafts we have say anything about the MPLS over MPLS-TP 
>case? Same for IP over MPLS-TP?
>
>Thanks
>Ben
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Dec 2008 10:34:41 -0000

Hi,

We have had considerable debate about this in Geneva.
(I think it is probably time to take this discussion to mpls-tp, so I will 
recreate the thread there).

Some data points for this discussion are:

1. What is the service provided by an MPLS-TP network?
Is it (as described in some documents) the provision of pseudowires over an 
MPLS transport network?
Or is it the provision of services (including pseudowires) over an MPLS 
transport network?

2. It there a need to provide demarcation between server traffic and client 
traffic?
There seem to be several reasons why one might do this:
a. architectural beauty
b. consistency with the answer to point 1
   (depending on the answer!)
c. ease of OAM and general management
  (so you can see the demarcation when you sniff the network)
d. To avoid accidental misforwarding of traffic
  For example, consider an MPLS-TP network operated using
  the management plane. In this network it is possible that an
  LSR along the path of an LSP is misconfigured to pop the
  MPLS-TP LSP top label. If what is found underneath is
  either a label from the client label space, or is treated as a label
  (in the case where the payload is IP) we will not spot an error,
  but may misforward traffic.

3. If there is demarcation as suggested in point 2, what is the best way to 
provide demarcation?
a. Encode as a PW with the end of stack set and a PW header according to the 
appropriate PW encoding type.
b. Simply use the end of stack bit to say that we have reached the bottom of 
the MPLS-TP label stack.
(The alternative clearly being that the label stack runs through from the 
client label stack to the server label stack.)

Opinions are needed!

Cheers,
Adrian

----- Original Message ----- 
From: "Drake, John E" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, December 10, 2008 10:48 PM
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 08:30:25 -0500

Adrian,

Thanks for taking the discussion in Geneva to the list. I have some
comments inline.

Cheers,
Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, December 11, 2008 5:35 AM
To: Drake, John E; Ben Niven-Jenkins; [email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Hi,

We have had considerable debate about this in Geneva.
(I think it is probably time to take this discussion to mpls-tp, so I
will 
recreate the thread there).

1. What is the service provided by an MPLS-TP network?
Is it (as described in some documents) the provision of pseudowires over
an 
MPLS transport network?
Or is it the provision of services (including pseudowires) over an MPLS 
transport network?

AM> My preference is the latter - it should be more general than just
the provisioning of pseudowires (even if we have IP and MPLS
pseudowires). A PW is an instance of a label in the stack, and what can
be transported over MPLS-TP shouldn't be limited to just that instance.

2. It there a need to provide demarcation between server traffic and
client 
traffic?

AM> Yes, we need a clear demarcation, for reasons c and d. Here in VZ,
our current discussions are around using IP/MPLS as an overlay over
MPLS-TP, with different groups in charge of the management of each
layer, thus maintaining our current layer separation. Plus in the future
we may wish to offer MPLS-TP as a customer-facing interface, with
customers using it to interconnect their own IP/MPLS routers. 

3. If there is demarcation as suggested in point 2, what is the best way
to 
provide demarcation?
a. Encode as a PW with the end of stack set and a PW header according to
the 
appropriate PW encoding type.
b. Simply use the end of stack bit to say that we have reached the
bottom of 
the MPLS-TP label stack.
(The alternative clearly being that the label stack runs through from
the 
client label stack to the server label stack.)

AM> I prefer b, for simplicity and generality of what can be carried
over MPLS-TP. Thus we could have a label stack with two EOS bits set. 

AM> Also, regarding the possible misconfiguration discussed in question
2, this could happen with PW labels as easily as with non-PW labels, so
requiring PWs to be used with MPLS-TP is no panacea. Rather, this sort
of misconfiguration needs to be detected using OAM and other MPLS-TP
layer management mechanisms.

Cheers,
Andy

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Dec 2008 13:40:17 -0000

Thanks Andy,

Just one point.
My understanding of the PW usage is that an EOS has to be present.
That means that the choice (when there is demarcation) is between PW and no 
PW. EOS would always be there.

A
----- Original Message ----- 
From: "Malis, Andrew G. (Andy)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Drake, John E" 
<[email-masked]>; "Ben Niven-Jenkins" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, December 11, 2008 1:30 PM
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

Adrian,

Cheers,
Andy

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

Hi,

Cheers,
Andy

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 08:50:44 -0500

Adrian,

Thanks for the clarification, but doesn't change my points about
generality of the MPLS-TP service.

Thanks,
Andy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 8:40 AM
To: Malis, Andrew G. (Andy)
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Thanks Andy,

Just one point.
My understanding of the PW usage is that an EOS has to be present.
That means that the choice (when there is demarcation) is between PW and
no 
PW. EOS would always be there.

A
----- Original Message ----- 
From: "Malis, Andrew G. (Andy)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Drake, John E" 

Adrian,

Cheers,
Andy

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

Hi,

Cheers,
Andy

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 11 Dec 2008 06:58:47 -0800

Snipped, comment inline 

>Is it (as described in some documents) the provision of 
>pseudowires over an MPLS transport network?
>Or is it the provision of services (including pseudowires) 
>over an MPLS transport network?
>
>pseudowires). A PW is an instance of a label in the stack, and 
>what can be transported over MPLS-TP shouldn't be limited to 
>just that instance.

JD:  I agree

>
>3. If there is demarcation as suggested in point 2, what is 
>the best way to provide demarcation?
>a. Encode as a PW with the end of stack set and a PW header 
>according to the appropriate PW encoding type.
>b. Simply use the end of stack bit to say that we have reached 
>the bottom of the MPLS-TP label stack.
>(The alternative clearly being that the label stack runs 
>through from the client label stack to the server label stack.)
>
>2, this could happen with PW labels as easily as with non-PW 
>labels, so requiring PWs to be used with MPLS-TP is no 
>panacea. Rather, this sort of misconfiguration needs to be 
>detected using OAM and other MPLS-TP layer management mechanisms.

JD:  I agree with your point about PW labels, but doesn't the same point
apply to the label stack with two EOS bits?  Viz, having the EOS bit set
will not prevent an implementation from messing up the stack in
arbitrary and capricious ways.

Isn't another alternative to just have the MPLS TP network be completely
agnostic to the contents of its payloads, as a server layer is supposed
to be?
In that case, the payload could in fact be an MPLS payload with its own
stack.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 11 Dec 2008 15:15:52 +0000

Agree with Andy on the need for demarcation for the reasons he states.

One question:

> over MPLS-TP. Thus we could have a label stack with two EOS bits set.

Does setting EOS provide the necessary separation?  Today in some MPLS
implementations if I reach the EOS in the middle of the network the label is
popped and the IP traffic inside is forwarded natively as IP across the
core.  Now if that IP traffic is really say control plane traffic for your
customers MPLS network do you want that to happen?

Is it just that we need to specify how an implementation is supposed to
behave in MPLS-TP in this sort of scenario or do we need explicit mechanisms
to prevent it such as always wrapping MPLS/IP in a PW?

Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 11 Dec 2008 10:17:53 -0500

Quite agree with Andy's points on 
- service provided by an MPLS-TP network should be general
- clear demarcation is needed, especially from the operation point of
view as the reasons c, d, Adrian stated.
> Plus in the future we may wish to offer MPLS-TP as a customer-facing
interface, with customers using it to interconnect their own IP/MPLS
routers. 

I think these points are consistent with the requirements draft.

Thanks,
Luyuan 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Malis, Andrew G.
(Andy)
Sent: 11 December 2008 08:51
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Adrian,

Thanks,
Andy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 8:40 AM
To: Malis, Andrew G. (Andy)
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Thanks Andy,

Just one point.
My understanding of the PW usage is that an EOS has to be present.
That means that the choice (when there is demarcation) is between PW and
no PW. EOS would always be there.

A
----- Original Message -----
From: "Malis, Andrew G. (Andy)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Drake, John E" 

Adrian,

Cheers,
Andy

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

Hi,

Cheers,
Andy

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 10:18:31 -0500

John,

AM> I must not have been clear enough, because that was my intention. We
are in agreement here. The payload would not have to be another MPLS
stack, but it could be, and that was the context of the original
discussion between Ben and Adrian.

Cheers,
Andy

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 11 Dec 2008 07:27:51 -0800

Andy,

Great.  So, it is up to the client endpoints of the MPLS TP LSP to
understand the payload contents and we could have as payloads, for
example, MPLS packets with their own label stack, IP packets, or
ethernet PW packets which in turn contain, for example, MPLS packets or
IP packets.

Thanks,

John  

>From: Malis, Andrew G. (Andy) [mailto:[email-masked]] 
>Sent: Thursday, December 11, 2008 7:19 AM
>To: Drake, John E; Adrian Farrel; Ben Niven-Jenkins; 
>[email-masked]
>JD:  I agree with your point about PW labels, but doesn't the 
>same point apply to the label stack with two EOS bits?  Viz, 
>having the EOS bit set will not prevent an implementation from 
>messing up the stack in arbitrary and capricious ways.
>
>Isn't another alternative to just have the MPLS TP network be 
>completely agnostic to the contents of its payloads, as a 
>server layer is supposed to be?
>In that case, the payload could in fact be an MPLS payload 
>with its own stack.
>
>are in agreement here. The payload would not have to be 
>another MPLS stack, but it could be, and that was the context 
>of the original discussion between Ben and Adrian.
>
>Cheers,
>Andy
>
>

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 10:31:10 -0500

Ben,

Does setting EOS provide the necessary separation?  Today in some MPLS
implementations if I reach the EOS in the middle of the network the
label is
popped and the IP traffic inside is forwarded natively as IP across the
core.  Now if that IP traffic is really say control plane traffic for
your
customers MPLS network do you want that to happen?

Is it just that we need to specify how an implementation is supposed to
behave in MPLS-TP in this sort of scenario or do we need explicit
mechanisms
to prevent it such as always wrapping MPLS/IP in a PW?

AM> The intention would be that the MPLS-TP EOS bit would only be
encountered at boundary the MPLS-TP network, and the payload would
delivered to the client to do with as it desires (and expects), whether
it's IP to forward, MPLS to switch using router-allocated labels, PW
contents, or something else entirely. To the client, there should be no
difference (at some layer of abstraction above the interface details)
between using MPLS-TP for transport and POS or GFP encapsulation for
transport.

Cheers,
Andy

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 10:32:33 -0500

John,

Exactly.

Cheers,
Andy

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 10:28 AM
To: Malis, Andrew G. (Andy); Adrian Farrel; Ben Niven-Jenkins;
[email-masked]

Andy,

Thanks,

John

---

From: Loa Andersson <[email-masked]>
Date: Thu, 11 Dec 2008 07:35:41 -0800

All,
Adrain made an effort to move this to the mpls-tp list, we should take the discussion there.

Make sure you send to the mpls-tp list(at least) if ypu couy the MEAD list that is fine, but the
effect is that everyone copied explicitly on this list gets two mails.

/Loa

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Malis, Andrew G. (Andy) [[email-masked]]
Sent: Thursday, December 11, 2008 16:32
To: Drake, John E; Adrian Farrel; Ben Niven-Jenkins; [email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

John,

Exactly.

Cheers,
Andy

-----Original Message-----
From: Drake, John E [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 10:28 AM
To: Malis, Andrew G. (Andy); Adrian Farrel; Ben Niven-Jenkins;
[email-masked]

Andy,

Thanks,

John

---

From: hejia 48726 <[email-masked]>
Date: Thu, 11 Dec 2008 23:47:11 +0800

Hi Andy,
   I guess what you suggest by using "a label stack with two EOS bits set" to realize demarcation was once discussed in MPLS over T-MPLS scenario(ITU-T contribution),as a alternative of PW way (which is valid, but not efficient). But the whole idea was not accepted at that time beacause this was claimed to invalid the existing MPLS architecure. :(

B.R.
Jia

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

----- 原邮件 -----
发件人: "Malis, Andrew G. (Andy)" <[email-masked]>
日期: 星期四, 十二月 11日, 2008 下午9:51
主题: Re: [Mpls-interop] MPLS over MPLS-TP
收件人: Adrian Farrel <[email-masked]>
抄送: [email-masked]

> pseudowires over
> Or is it the provision of services (including pseudowires) over an 
> MPLStransport network?
> 
> what can
> layer, thus maintaining our current layer separation. Plus in the 
> futurewe may wish to offer MPLS-TP as a customer-facing interface, 
> withcustomers using it to interconnect their own IP/MPLS routers.
> 
> according to
> AM> Also, regarding the possible misconfiguration discussed in 
> question2, this could happen with PW labels as easily as with non-
> PW labels, so

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 11:00:15 -0500

Jia,

I don't really want to get back into MPLS-TP vs. T-MPLS, but that was really a minor bit at the time compared to other technical points, and that is still the case, which is why it's being discussed now rather than being included as a part of the JWT report.

Cheers,
Andy

-----Original Message-----
From: hejia 48726 [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 10:47 AM
To: Malis, Andrew G. (Andy)
Cc: Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Hi Andy,

B.R.
Jia

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 11 Dec 2008 11:22:35 -0500

Andy,

I am of the opinion that PW provides the better demarcation
than mapping client MPLS or IP packets directly over the MPLS-TP
tunnel. The generalized useage comes by virtue of being able to map
different kinds of PWs over MPLS-TP tunnels.

Now, MPLS-PWoverMPLS-TP vs client-MPLSoverMPLS-TP are virtually
indistiguishable at the LSRs, but atleast PW labels have provider
label contexts at the LSEs. Not sure if erroneous label pop changing
the trajectory is a solvable problem in MPLS (especially for stacked
labels).

/himanshu

-----Original Message-----
Sent: Thursday, December 11, 2008 10:33 AM

John,

Exactly.

Cheers,
Andy

-----Original Message-----
From: Drake, John E [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 10:28 AM
To: Malis, Andrew G. (Andy); Adrian Farrel; Ben Niven-Jenkins;
[email-masked]

Andy,

Thanks,

John  

>JD:  I agree with your point about PW labels, but doesn't the same 
>point apply to the label stack with two EOS bits?  Viz, having the EOS 
>bit set will not prevent an implementation from messing up the stack in

>completely agnostic to the contents of its payloads, as a server layer 
>is supposed to be?

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 11 Dec 2008 08:45:10 -0800

>From: Shah, Himanshu [mailto:[email-masked]] 
>Sent: Thursday, December 11, 2008 8:23 AM
>To: Malis, Andrew G. (Andy); Drake, John E; Adrian Farrel; Ben 
>Niven-Jenkins; [email-masked]
>than mapping client MPLS or IP packets directly over the 
>MPLS-TP tunnel. The generalized useage comes by virtue of 
>being able to map different kinds of PWs over MPLS-TP tunnels.

JD:  I'm sure everyone has a different opinion.  By saying that MPLS TP
is payload agnostic, we allow each service provider to make their own
decision wrt service demarcation.

>
>Now, MPLS-PWoverMPLS-TP vs client-MPLSoverMPLS-TP are 
>virtually indistiguishable at the LSRs, but atleast PW labels 
>have provider label contexts at the LSEs.

JD:  What is so much more appealing about having provider label context
via a PW label rather than an MPLS Label?  

>Not sure if 
>erroneous label pop changing the trajectory is a solvable 
>problem in MPLS (especially for stacked labels).
>
>/himanshu
>
>
>
>Great.  So, it is up to the client endpoints of the MPLS TP 
>LSP to understand the payload contents and we could have as 
>payloads, for example, MPLS packets with their own label 
>stack, IP packets, or ethernet PW packets which in turn 
>contain, for example, MPLS packets or IP packets.
>
>Thanks,
>
>John  
>
>with its own

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 11 Dec 2008 17:54:40 +0100

The first option also allows you to have better trouble shooting in case
of a problem (thanks to the clear separation). 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Ben
Niven-Jenkins
Sent: Thursday, December 11, 2008 00:41
To: [email-masked]
Subject: [Mpls-interop] MPLS over MPLS-TP

Colleagues,

Do we put a PW in the middle (like draft-bryant) or do we just use the
label
stack and have MPLS directly over MPLS-TP?

Advantage of the first is that it gives layer separation (e.g. If the
two
layers are operated by different parties), advantage of the second is
it's
probably a bit simpler.

Do the drafts we have say anything about the MPLS over MPLS-TP case?
Same
for IP over MPLS-TP?

Thanks
Ben

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 11 Dec 2008 09:01:33 -0800

>Sent: Thursday, December 11, 2008 8:55 AM
>To: ext Ben Niven-Jenkins; [email-masked]
>The first option also allows you to have better trouble 
>shooting in case of a problem (thanks to the clear separation).

JD:  Regardless of whether you have MPLS TP/PW/MPLS *or* MPLS TP/MPLS,
you will have two label stacks.  The only difference is whether the last
label in the provider's stack is an PW label *or* an MPLS label.  This
was the point in Andy's first e-mail, which as I read it, said that
there was nothing magic about that label being a PW label.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 11 Dec 2008 12:05:32 -0500

...inline 

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 11:45 AM
To: Shah, Himanshu; Malis, Andrew G. (Andy); Adrian Farrel; Ben

>I am of the opinion that PW provides the better demarcation than 
>mapping client MPLS or IP packets directly over the MPLS-TP tunnel. The

>generalized useage comes by virtue of being able to map different kinds

>of PWs over MPLS-TP tunnels.

>indistiguishable at the LSRs, but atleast PW labels have provider label

>contexts at the LSEs.

himanshu> Several. traditional ones.
himanshu> 1. LSEs do not have to participate in client MPLS
himanshu> 2. PW label can be followed by control word, giving more
separation, less confusion for LSRs
himanshu> 3. Given provider may chose custom label range for PWs and
MPLS in his network, giving further separation
etc etc

/himanshu

>Not sure if
>erroneous label pop changing the trajectory is a solvable problem in 
>MPLS (especially for stacked labels).
>
>/himanshu
>
>
>

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 11 Dec 2008 09:17:15 -0800

inline 

>Sent: Thursday, December 11, 2008 9:06 AM
>To: Drake, John E; Malis, Andrew G. (Andy); Adrian Farrel; Ben 
>To: Shah, Himanshu; Malis, Andrew G. (Andy); Adrian Farrel; 
>Ben Niven-Jenkins; [email-masked]
>JD:  I'm sure everyone has a different opinion.  By saying 
>that MPLS TP is payload agnostic, we allow each service 
>provider to make their own decision wrt service demarcation.
>
>>
>JD:  What is so much more appealing about having provider 
>label context via a PW label rather than an MPLS Label?  
>
>

JD:  In neither case, MPLS TP/PW/MPLS nor MPLS TP/MPLS, does the
provider participate in client MPLS.  Please see my response to Nurit.

> 2. 
>PW label 
>himanshu> can be followed by control word, giving more

JD:  This sounds like an assertion.

>MPLS in his network, giving further separation etc etc

JD:  A given provider is free to use custom label ranges in his network
in both the MPLS TP/PW/MPLS and the MPLS TP/MPLS cases.  As noted above,
in either case, the service provider only deals with his label stack and
has no visibility or awareness of the customer label stack.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 11 Dec 2008 20:16:50 +0100

Well there is a difference, named control word. Also for OAM, with or
with out GALs.

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 19:02
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ben Niven-Jenkins;
[email-masked]

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 11 Dec 2008 11:22:51 -0800

Both the provider and the customer can independently run OAM, each using
their own label stack.   

>Sent: Thursday, December 11, 2008 11:17 AM
>To: Drake, John E; ext Ben Niven-Jenkins; [email-masked]
>Well there is a difference, named control word. Also for OAM, 
>with or with out GALs.
>
>To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ben 
>>The first option also allows you to have better trouble shooting in 
>>case of a problem (thanks to the clear separation).
>
>JD:  Regardless of whether you have MPLS TP/PW/MPLS *or* MPLS 
>TP/MPLS, you will have two label stacks.  The only difference 
>is whether the last label in the provider's stack is an PW 
>label *or* an MPLS label.  This was the point in Andy's first 
>e-mail, which as I read it, said that there was nothing magic 
>about that label being a PW label.
> 
>>
>>label stack and have MPLS directly over MPLS-TP?
>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 11 Dec 2008 20:03:13 +0000

Andy,

> between using MPLS-TP for transport and POS or GFP encapsulation for

Yes, but my concern is that IP & MPLS may well be 'recognised' in the
network core and if something happened (e.g. Erroneous label pop) to expose
them they could be forwarded natively in error.  Other traffic types are
unlikely to have this happen as the network core is unlikely to support
natively forwarding them.

Ben

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 15:11:16 -0500

How is it any better for a PW? You still have a label at the top of the
stack. There are two scenarios:

1. A label is popped at the MPLS-TP layer that shouldn't have been

That's either going to expose another label at that layer that won't be
have the proper context, or the start of an IP packet that'll be
misinterpreted as a label (since MPLS-TP switches presumably won't know
how to forward IP, at least in the fast path). In either case, if
there's a matching label allocation to the 20 bits in the header, then
it'll be forwarded out a random interface, or dropped if there's no
match.

2. An MPLS-TP label wasn't popped that should have been

That'll expose (probably) the bottom-most MPLS-TP label to the IP/MPLS
client router. Again, what happens next depends on how that label is
interpreted by the router.

Either way, how are things any better if you use a PW label?

Cheers,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
[email-masked]

Andy,

On 11/12/2008 15:31, "Malis, Andrew G. (Andy)"
<[email-masked]>

network core and if something happened (e.g. Erroneous label pop) to
expose

Ben

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 11 Dec 2008 15:34:23 -0500

Control word after the PW label prevents identifying the packet as IP
packet at an LSR.
As I said earlier, misdirection due to erroneous label operation yields 
unpredictable results. There are a limited things one can do (some of
which was mentioned 
in my previous email (like label range separation, control word
insertion, etc etc))

/himanshu 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Malis, Andrew G.
(Andy)
Sent: Thursday, December 11, 2008 3:11 PM
To: Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
[email-masked]
Subject: Re: [Mpls-interop] MPLS over MPLS-TP

Cheers,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
[email-masked]

Andy,

Yes, but my concern is that IP & MPLS may well be 'recognised' in the
network core and if something happened (e.g. Erroneous label pop) to
expose them they could be forwarded natively in error.  Other traffic
types are unlikely to have this happen as the network core is unlikely
to support natively forwarding them.

Ben

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 15:39:23 -0500

Himanshu,

If things are misconfigured that badly, why couldn't the PW control word be misinterpreted as a label if too many labels were popped at the MPLS-TP layer?

Cheers,
Andy

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 3:34 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake, John E; [email-masked]
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

/himanshu 

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

Cheers,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
[email-masked]

Andy,

Ben

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 11 Dec 2008 15:44:25 -0500

...and hence the second point applies.

There is only limited to none things that you can do
in MPLS if an LSR misbehaves. PW gives you limited protection,
MPLSoMPLS-TP provides none protection. Ample room to break things
based on how bad the behavior is

/himanshu

-----Original Message-----
From: Malis, Andrew G. (Andy) [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 3:39 PM
To: Shah, Himanshu; Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
[email-masked]

Himanshu,

If things are misconfigured that badly, why couldn't the PW control word
be misinterpreted as a label if too many labels were popped at the
MPLS-TP layer?

Cheers,
Andy

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:34 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake,
John E; [email-masked]
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

Control word after the PW label prevents identifying the packet as IP
packet at an LSR.
As I said earlier, misdirection due to erroneous label operation yields
unpredictable results. There are a limited things one can do (some of
which was mentioned in my previous email (like label range separation,
control word insertion, etc etc))

/himanshu 

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

Cheers,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
[email-masked]

Andy,

Ben

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Thu, 11 Dec 2008 15:52:50 -0500

Himanshu,

I still don't get what protection the PW gives you over not having the PW.

To me, the major difference between whether you have a PW or not is what OAM is used end-to-end at the top of the transport layer (think of ATM F5 OAM). This will either be MPLS-TP OAM or pseudowire OAM. As an operator, I would want the former, not the latter.

Cheers,
Andy

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 3:44 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake, John E; [email-masked]
Subject: RE: [Mpls-interop] MPLS over MPLS-TP

/himanshu

-----Original Message-----
From: Malis, Andrew G. (Andy) [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 3:39 PM
To: Shah, Himanshu; Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
[email-masked]

Himanshu,

Cheers,
Andy

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:34 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake,

/himanshu 

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

Cheers,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
[email-masked]

Andy,

Ben

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 11 Dec 2008 16:18:35 -0500

Andy,

We are shifting gears. We were talking about protection against
misbehaving
LSR. Now we are discussing end to end protection/fault detection/fault
propagation, etc.

Also, I believe, we were discussing what suits best over MPLS-TP;
MPLS-PWoMPLS-TP or MPLSoMPLS-TP.

Without doubt, MPLS-TP based e-e OAM is available for both models.
In addition, for PWoMPLS-TP, you have PW based OAM.
For MPLSoMPLS-TP, PE is actually an LSR in hierarchical tunnel.

/himanshu

-----Original Message-----
From: Malis, Andrew G. (Andy) [mailto:[email-masked]] 
Sent: Thursday, December 11, 2008 3:53 PM
To: Shah, Himanshu; Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
[email-masked]

Himanshu,

I still don't get what protection the PW gives you over not having the
PW.

To me, the major difference between whether you have a PW or not is what
OAM is used end-to-end at the top of the transport layer (think of ATM
F5 OAM). This will either be MPLS-TP OAM or pseudowire OAM. As an
operator, I would want the former, not the latter.

Cheers,
Andy

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:44 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake,

There is only limited to none things that you can do in MPLS if an LSR
misbehaves. PW gives you limited protection, MPLSoMPLS-TP provides none
protection. Ample room to break things based on how bad the behavior is

/himanshu

-----Original Message-----
From: Malis, Andrew G. (Andy) [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:39 PM
To: Shah, Himanshu; Ben Niven-Jenkins; Adrian Farrel; Drake, John E;
[email-masked]

Himanshu,

Cheers,
Andy

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:34 PM
To: Malis, Andrew G. (Andy); Ben Niven-Jenkins; Adrian Farrel; Drake,

/himanshu 

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

Cheers,
Andy

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Thursday, December 11, 2008 3:03 PM
To: Malis, Andrew G. (Andy); Adrian Farrel; Drake, John E;
[email-masked]

Andy,

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 12 Dec 2008 09:40:28 +0000

Andy,

OK I see your point. If the network is screwed up all bets are off.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Dec 2008 20:56:09 -0000

Well, there is a difference IMHO between screwed and screwed.

If you pop a label you may be perfectly happy to continue forwarding on the 
label underneath.
But if you pop the last label (i.e. EOS), you have to go somewhere else to 
find out what to do next.

Of course, that can be screwed as well, but it is perhaps a little less 
likely.

A

----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "Malis, Andrew G. (Andy)" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; "Drake, John E" <[email-masked]>; 
<[email-masked]>
Sent: Friday, December 12, 2008 9:40 AM
Subject: Re: [Mpls-interop] MPLS over MPLS-TP