Subject: [mpls-tp] Associated bidirectional transport path requirements

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 25 Mar 2009 17:58:07 +0000

Folks,

Following a chat with Lou I will expand the text around the requirement on
associated bidirectional transport paths to try and clear up some of the
confusion expressed in the meeting just now.

IMO any more than a few clarifying statements belongs in the framework draft
not the requirements draft.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 25 Mar 2009 23:32:38 +0000

OK, How about this, change requirement 32 from:

   32  The intermediate nodes at each (sub-)layer MUST be aware about
       the pairing relationship of the forward and the backward
       directions belonging to the same co-routed bidirectional
       transport path.

To:
   32  The intermediate nodes at each (sub-)layer MUST be aware about
       the pairing relationship of the forward and the backward
       directions belonging to the same co-routed bidirectional
       transport path.

       A  This requirement does not apply to associated bidirectional
          transport paths. Only the ingress and egress nodes at each
          (sub-)layer MUST be aware about the pairing relationship of the
          forward and backward directions belonging to the same associated
          bidirectional transport path.

Quick review appreciated as I am hoping to spin -06 early next week ready to
liaise to ITU.

Ben

On 25/03/2009 17:58, "Benjamin Niven-Jenkins"
<[email-masked]> wrote:

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 25 Mar 2009 16:54:41 -0700

Ben,

Looks good to me.

Cheers,
Andy

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 26 Mar 2009 07:52:10 +0200

Andy, Ben and all,
I've scanned the Framework and Requirements drafts (in their present form) and I've found the following:

1. The notions "Associated bidirectional path" and "Co-routed bidirectional path" are defined in the
    Requirements draft. 
   - The definition of a associated bidirectional path explicitly states that co-routing is not
      required, meaning that the data plane of intermediate nodes, generally speaking, 
      cannot be aware of the pairing relationship 
   - Unsurprisingly, the definition of a co-routed bidirectional path includes co-routing

2. The Framework draft does not mention associated bidirectional paths at all. 
    It mentions bidirectional paths that, if so required, would  be co-routed 
    ("it MUST be possible to configure..." - Section 3.3,  Para 8). And it does not
    mention (at least explicitly) the requirement to setup, monitor and protect both directions
    as a single entity (which seems to be the key point of the definition in the Requirements 
    document)

3. The Framework and Requirement documents seem to treat the issue of pairing awareness
    somewhat differently:
    - the former requires such an awareness "at each MEP, MIP or segment protection endpoint"
    - the latter requires such an awareness at each intermediate node (Requirement 32).

Taken all this into account, it would probably suffice to change Requirement 32 to from:

to something like:

   32  The intermediate nodes OF A CO-ROUTED BI-DIRECTIONL PATH at each (sub-)layer 
         MUST be aware about the pairing relationship of the forward and the backward
        directions OF THIS PATH. 

It would be nice to note that this arrangement guarantees that such an awareness can be
provided at every MEP, MIP or segment protection endpoint.

I also wonder whether the entire Definitions section actually belongs to the Framework draft.
Isn't that the first place you usually look at when you encounter a term you do not recognize?

My 2c,
     Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Andrew G. Malis [[email-masked]]
Sent: Thursday, March 26, 2009 1:54 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Ben,

Looks good to me.

Cheers,
Andy

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 26 Mar 2009 13:34:06 -0400

Sasha, I think your text does not cover the possibility of using a pair
of (independent) uni directional paths to support a bi directional
service by providing an association at the end points (only)

So how about:

32  The intermediate nodes OF A CO-ROUTED BI-DIRECTIONL PATH at each
(sub-)layer 
         MUST be aware about the pairing relationship of the forward and
the backward
        directions OF THIS PATH.   
        The end points of a pair of uni directional paths that are used
to support a
        bi directional service MUST be aware of the pairing relationship
of the
        forward and reverse paths used to support the bidirectional
service. 

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexander Vainshtein
Sent: Thursday, March 26, 2009 1:52 AM
To: Andrew G. Malis; Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

Andy, Ben and all,
I've scanned the Framework and Requirements drafts (in their present
form) and I've found the following:

1. The notions "Associated bidirectional path" and "Co-routed
bidirectional path" are defined in the
    Requirements draft. 
   - The definition of a associated bidirectional path explicitly states
that co-routing is not
      required, meaning that the data plane of intermediate nodes,
generally speaking, 
      cannot be aware of the pairing relationship 
   - Unsurprisingly, the definition of a co-routed bidirectional path
includes co-routing

2. The Framework draft does not mention associated bidirectional paths
at all. 
    It mentions bidirectional paths that, if so required, would  be
co-routed 
    ("it MUST be possible to configure..." - Section 3.3,  Para 8). And
it does not
    mention (at least explicitly) the requirement to setup, monitor and
protect both directions
    as a single entity (which seems to be the key point of the
definition in the Requirements 
    document)

3. The Framework and Requirement documents seem to treat the issue of
pairing awareness
    somewhat differently:
    - the former requires such an awareness "at each MEP, MIP or segment
protection endpoint"
    - the latter requires such an awareness at each intermediate node
(Requirement 32).

Taken all this into account, it would probably suffice to change
Requirement 32 to from:

to something like:

   32  The intermediate nodes OF A CO-ROUTED BI-DIRECTIONL PATH at each
(sub-)layer 
         MUST be aware about the pairing relationship of the forward and
the backward
        directions OF THIS PATH. 

It would be nice to note that this arrangement guarantees that such an
awareness can be provided at every MEP, MIP or segment protection
endpoint.

I also wonder whether the entire Definitions section actually belongs to
the Framework draft.
Isn't that the first place you usually look at when you encounter a term
you do not recognize?

My 2c,
     Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of
Andrew G. Malis [[email-masked]]
Sent: Thursday, March 26, 2009 1:54 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

Ben,

Looks good to me.

Cheers,
Andy

On Wed, Mar 25, 2009 at 4:32 PM, Ben Niven-Jenkins
<[email-masked]> wrote:
> Quick review appreciated as I am hoping to spin -06 early next week 
> ready to liaise to ITU.
>
> Ben
>
>
>
>> Following a chat with Lou I will expand the text around the 
>> requirement on associated bidirectional transport paths to try and 
>> clear up some of the confusion expressed in the meeting just now.
>>
>> IMO any more than a few clarifying statements belongs in the 
>> framework draft not the requirements draft.
>>
>> Ben
>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 26 Mar 2009 11:46:31 -0700

I support Malcom's intention to include intermediate nodes of associated
bidirectional path. An associated bidirectional path can have node and link
diversity or node diversity with any level of such from complete diversity
to being actually same as co-routed. If over associated bidirectional path
exist a intermediate node that node that intersects forward and backward (or
reverse) directions it, I believe, must behave as an intermediate node of
co-routed bidirectional path.

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 26 Mar 2009 22:27:23 +0200

Malcolm (and all),
You definitely have a point here. 
However, "Associated bidirectional path" seems to be exactly "A pair of unidirectional paths that are used
to support a bidirectional service". 
Hence the second statement could be compressed into something like

"The end points of an associated bi-directional path MUST be aware of the pairing relationship."

My 2c,
     Sasha

________________________________________
From: Malcolm Betts [[email-masked]]
Sent: Thursday, March 26, 2009 7:34 PM
To: Alexander Vainshtein; Andrew G. Malis; Ben Niven-Jenkins
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

So how about:

Malcolm Betts
Nortel Networks

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

Andy, Ben and all,

to something like:

My 2c,
     Sasha

Ben,

Looks good to me.

Cheers,
Andy

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 26 Mar 2009 17:10:39 -0400

This works for me.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, March 26, 2009 4:27 PM
To: Betts, Malcolm (CAR:X632); Andrew G. Malis; Ben Niven-Jenkins
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path
requirements

Malcolm (and all),
You definitely have a point here. 
However, "Associated bidirectional path" seems to be exactly "A pair of
unidirectional paths that are used to support a bidirectional service". 
Hence the second statement could be compressed into something like

"The end points of an associated bi-directional path MUST be aware of
the pairing relationship."

My 2c,
     Sasha

Subject: RE: [mpls-tp] Associated bidirectional transport path
requirements

So how about:

Malcolm Betts
Nortel Networks

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

Andy, Ben and all,

to something like:

My 2c,
     Sasha

Ben,

Looks good to me.

Cheers,
Andy

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 26 Mar 2009 14:40:41 -0700

Sasha,
if the associated bidirectional path IS "a pair of unidirectional paths that
are used
to support a bidirectional service" then I agree with your point. But if the
associated bidirectional is a bidirectional path whose directions (for the
luck of better term) may cross different nodes and segments between the same
pair of end-points, then it, the path, should be treated as bidirectional
first and associated second. In latter interpretation an associated is more
generic case and a co-routed is a special case of bidirectional path. We've
found that this is very important to agree on one interpretation since it
impacts many other areas, e.g. linear protection.

Regards,
Grigorij

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Mar 2009 23:14:43 +0000

Sasha,

It may help if I explain the requirement.

I do not want to build an MPLS-TP network. I want to use some MPLS-TP
functionality in my existing deployed boxes/implementations.

My MPLS network does not support co-routed bidirectional LSPs.

I need the end points of an LSP to be able to associate the forward and
backwards directions in order for them to know the appropriate "back
channel" for traffic originating out of that LSP end point.

With respect to the wording, There was a lot of confusion in the meeting
about what is/is not required wrt pairing for co-routed bidirectional Vs
associated bi-directional. So I'm inclined to have more text to make things
explicit Vs less text and leave some things implicit.

Ben

P.S. The question of where the definitions sit - I do not care, I guess they
sit in the requirements draft right now because (a) I wrote a lot of them
and don't edit the framework draft and (b) the requirements draft is more
stable right now.

But like I say I don't care where ultimately the sit as long as it doesn't
hold up getting the requirements draft out of the door & published.

On 26/03/2009 05:52, "Alexander Vainshtein"
<[email-masked]> wrote:

> awareness can be

---

From: [email-masked]
Date: Fri, 27 Mar 2009 10:14:52 +0800

Greg:
  I agree your opinion, for associated bidirectional path and co-routed 
bidirectional path, We have one interpretation about them. 
for linear protection,it maybe exist the problem: when one directional 
path of  a pair of associated bidirectional have fault,whether this two 
directional working path will be switch into their protectional path?
these problem may be considered?
 
thank you
liu 

Greg Mirsky <[email-masked]> 
发件人:  [email-masked]
2009-03-27 05:40

收件人
Alexander Vainshtein <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Sasha,
if the associated bidirectional path IS "a pair of unidirectional paths 
that are used
to support a bidirectional service" then I agree with your point. But if 
the associated bidirectional is a bidirectional path whose directions (for 
the luck of better term) may cross different nodes and segments between 
the same pair of end-points, then it, the path, should be treated as 
bidirectional first and associated second. In latter interpretation an 
associated is more generic case and a co-routed is a special case of 
bidirectional path. We've found that this is very important to agree on 
one interpretation since it impacts many other areas, e.g. linear 
protection.

Regards,
Grigorij

unidirectional paths that are used

"The end points of an associated bi-directional path MUST be aware of the 
pairing relationship."

My 2c,
    Sasha

So how about:

Malcolm Betts
Nortel Networks

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

Andy, Ben and all,

to something like:

My 2c,
    Sasha

Ben,

Looks good to me.

Cheers,
Andy

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 28 Mar 2009 12:28:36 +0300

Grigorij,
Sorry, but I am not sure I follow you. This is my reading of the definitions:

 1.
A P2P path is bi-directional if the traffic can flow in both directions (i.e. from end point A to end point Z and from end point Z to end point A)
 2.  A bi-directional path can be :
    *
Co-routed bidirectional if both directions:
       *
Are setup, monitored and protected as a single entity
       *
Cross exactly the same set of intermediate nodes and links (in mutually reverse order)
    *
Associated bidirectional if:
       *
Its end points are aware of the pairing relationship between two directions
       *
The paths for the two directions have been setup, monitored and protected independently and hence do not necessary traverse the same set of node of links.
 3.  Now comes the question: Is there a case when a bi-directional path is neither a co-routed one nor an associated one? I must admit that I do not see how this could happen.

Did I miss something? And if I did, which requirements can be reasonably applied to a bidirectional path that is neither a co-routed nor an associated one?

Regards,

     Sasha

________________________________
From: Greg Mirsky [[email-masked]]
Sent: Thursday, March 26, 2009 11:40 PM
To: Alexander Vainshtein
Cc: Malcolm Betts; Andrew G. Malis; Ben Niven-Jenkins; [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Sasha,
if the associated bidirectional path IS "a pair of unidirectional paths that are used
to support a bidirectional service" then I agree with your point. But if the associated bidirectional is a bidirectional path whose directions (for the luck of better term) may cross different nodes and segments between the same pair of end-points, then it, the path, should be treated as bidirectional first and associated second. In latter interpretation an associated is more generic case and a co-routed is a special case of bidirectional path. We've found that this is very important to agree on one interpretation since it impacts many other areas, e.g. linear protection.

Regards,
Grigorij

On Thu, Mar 26, 2009 at 1:27 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Malcolm (and all),

My 2c,
    Sasha

________________________________________
From: Malcolm Betts [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 26, 2009 7:34 PM
To: Alexander Vainshtein; Andrew G. Malis; Ben Niven-Jenkins
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

So how about:

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
Behalf Of Alexander Vainshtein
Sent: Thursday, March 26, 2009 1:52 AM
To: Andrew G. Malis; Ben Niven-Jenkins
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

Andy, Ben and all,

to something like:

My 2c,
    Sasha
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of
Andrew G. Malis [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 26, 2009 1:54 AM
To: Ben Niven-Jenkins
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

Ben,

Looks good to me.

Cheers,
Andy

On Wed, Mar 25, 2009 at 4:32 PM, Ben Niven-Jenkins
<[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Folks,
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Sat, 28 Mar 2009 09:36:43 -0000

Sasha,
 
Not sure if this is the answer to your question or not, but to be truly
co-routed this does not just apply to the layer network being considered
but also all lower layer networks down to the duct, ie each link
connection in layer N is co-routed in layer N-1...and this recuses to
the duct.  
 
In many cases the party owning layer N may not own all of the lower
layers to the duct, so ensuring full co-routing may not be possible.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexander Vainshtein
	Sent: 28 March 2009 09:29
	To: Greg Mirsky
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

	Grigorij,
	Sorry, but I am not sure I follow you. This is my reading of the
definitions:

	1.	
		A P2P path is bi-directional if the traffic can flow in
both directions (i.e. from end point A to end point Z and from end point
Z to end point A)
	2.	A bi-directional path can be : 

		*	

			*	
				Are setup, monitored and protected as a
single entity
			*	
				Cross exactly the same set of
intermediate nodes and links (in mutually reverse order)

		*	

			*	
				Its end points are aware of the pairing
relationship between two directions
			*	
				The paths for the two directions have
been setup, monitored and protected independently and hence do not
necessary traverse the same set of node of links.

	3.	Now comes the question: Is there a case when a
bi-directional path is neither a co-routed one nor an associated one? I
must admit that I do not see how this could happen.

	Did I miss something? And if I did, which requirements can be
reasonably applied to a bidirectional path that is neither a co-routed
nor an associated one?

	Regards,

	     Sasha

	From: Greg Mirsky [[email-masked]]
	Sent: Thursday, March 26, 2009 11:40 PM
	To: Alexander Vainshtein
	Cc: Malcolm Betts; Andrew G. Malis; Ben Niven-Jenkins;
[email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

	Sasha,
	if the associated bidirectional path IS "a pair of
unidirectional paths that are used
	to support a bidirectional service" then I agree with your
point. But if the associated bidirectional is a bidirectional path whose
directions (for the luck of better term) may cross different nodes and
segments between the same pair of end-points, then it, the path, should
be treated as bidirectional first and associated second. In latter
interpretation an associated is more generic case and a co-routed is a
special case of bidirectional path. We've found that this is very
important to agree on one interpretation since it impacts many other
areas, e.g. linear protection.
	
	Regards,
	Grigorij

	On Thu, Mar 26, 2009 at 1:27 PM, Alexander Vainshtein
<[email-masked]> wrote:

		Malcolm (and all),
		You definitely have a point here.
		However, "Associated bidirectional path" seems to be
exactly "A pair of unidirectional paths that are used
		to support a bidirectional service".
		Hence the second statement could be compressed into
something like
		
		"The end points of an associated bi-directional path
MUST be aware of the pairing relationship."
		
		My 2c,
		    Sasha
		
		________________________________________
		From: Malcolm Betts [[email-masked]]
		Sent: Thursday, March 26, 2009 7:34 PM
		To: Alexander Vainshtein; Andrew G. Malis; Ben
Niven-Jenkins
		
		Cc: [email-masked]
		
		Subject: RE: [mpls-tp] Associated bidirectional
transport path requirements

		Sasha, I think your text does not cover the possibility
of using a pair
		of (independent) uni directional paths to support a bi
directional
		service by providing an association at the end points
(only)
		
		So how about:
		
		32  The intermediate nodes OF A CO-ROUTED BI-DIRECTIONL
PATH at each
		(sub-)layer
		        MUST be aware about the pairing relationship of
the forward and
		the backward
		       directions OF THIS PATH.
		       The end points of a pair of uni directional paths
that are used
		to support a
		       bi directional service MUST be aware of the
pairing relationship
		of the
		       forward and reverse paths used to support the
bidirectional
		service.

		Malcolm Betts
		Nortel Networks
		
		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf Of Alexander Vainshtein
		Sent: Thursday, March 26, 2009 1:52 AM
		To: Andrew G. Malis; Ben Niven-Jenkins
		Cc: [email-masked]
		Subject: Re: [mpls-tp] Associated bidirectional
transport path
		requirements
		
		Andy, Ben and all,
		I've scanned the Framework and Requirements drafts (in
their present
		form) and I've found the following:
		
		1. The notions "Associated bidirectional path" and
"Co-routed
		bidirectional path" are defined in the
		   Requirements draft.
		  - The definition of a associated bidirectional path
explicitly states
		that co-routing is not
		     required, meaning that the data plane of
intermediate nodes,
		generally speaking,
		     cannot be aware of the pairing relationship
		  - Unsurprisingly, the definition of a co-routed
bidirectional path
		includes co-routing
		
		2. The Framework draft does not mention associated
bidirectional paths
		at all.
		   It mentions bidirectional paths that, if so required,
would  be
		co-routed
		   ("it MUST be possible to configure..." - Section 3.3,
Para 8). And
		it does not
		   mention (at least explicitly) the requirement to
setup, monitor and
		protect both directions
		   as a single entity (which seems to be the key point
of the
		definition in the Requirements
		   document)
		
		3. The Framework and Requirement documents seem to treat
the issue of
		pairing awareness
		   somewhat differently:
		   - the former requires such an awareness "at each MEP,
MIP or segment
		protection endpoint"
		   - the latter requires such an awareness at each
intermediate node
		(Requirement 32).
		
		Taken all this into account, it would probably suffice
to change
		Requirement 32 to from:
		
		  32  The intermediate nodes at each (sub-)layer MUST be
aware about
		      the pairing relationship of the forward and the
backward
		      directions belonging to the same co-routed
bidirectional
		      transport path.
		
		to something like:
		
		  32  The intermediate nodes OF A CO-ROUTED
BI-DIRECTIONL PATH at each
		(sub-)layer
		        MUST be aware about the pairing relationship of
the forward and
		the backward
		       directions OF THIS PATH.
		
		It would be nice to note that this arrangement
guarantees that such an
		awareness can be provided at every MEP, MIP or segment
protection
		endpoint.
		
		I also wonder whether the entire Definitions section
actually belongs to
		the Framework draft.
		Isn't that the first place you usually look at when you
encounter a term
		you do not recognize?
		
		My 2c,
		    Sasha
		________________________________________
		From: [email-masked]
[[email-masked]] On Behalf Of
		Andrew G. Malis [[email-masked]]
		Sent: Thursday, March 26, 2009 1:54 AM
		To: Ben Niven-Jenkins
		Cc: [email-masked]
		Subject: Re: [mpls-tp] Associated bidirectional
transport path
		requirements
		
		Ben,
		
		Looks good to me.
		
		Cheers,
		Andy
		
		On Wed, Mar 25, 2009 at 4:32 PM, Ben Niven-Jenkins
		<[email-masked]> wrote:
		>          (sub-)layer MUST be aware about the pairing
relationship of
		the
		>          forward and backward directions belonging to
the same
		associated

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 28 Mar 2009 12:49:57 +0300

Ben,

Lots of thanks for the clarification.

Please see some comments inline below (blue italics).

Regards,

     Sasha

________________________________________
From: Ben Niven-Jenkins [[email-masked]]
Sent: Friday, March 27, 2009 1:14 AM
To: Alexander Vainshtein; Andrew G. Malis
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Sasha,

I do not want to build an MPLS-TP network. I want to use some MPLS-TP
functionality in my existing deployed boxes/implementations. [[Sasha]] So far, so good.

[[Sasha]] Probably not. And one of the major obstacles is probably the requirement for "the pairing awareness in all the intermediate nodes" which would add quite a lot of state to the data plane of these nodes.

I need the end points of an LSP to be able to associate the forward and backwards directions in order for them to know the appropriate "back
channel" for traffic originating out of that LSP end point.  [[Sasha]] One reason for that could be the need to maintain inband signaling for linear protection switching. I wonder if there are any other reasons.

With respect to the wording, There was a lot of confusion in the meeting about what is/is not required wrt pairing for co-routed bidirectional Vs
associated bi-directional. So I'm inclined to have more text to make things explicit Vs less text and leave some things implicit.

[[Sasha]] I do not object to having more text - as long as additional text clarifies things. Introducing a notion ("associated bidirectional") and then not using it does not really help. Please note that, in addition to the definition, the notion of an "associated bidirectional path" is only used once in the requirements draft - when it says that MPLS TP MUST support them along with co-routed bidirectional and unidirectional P2P path. At the same time your message seems to imply that this is actually going to be the most important/popular type of bidirectional path - at least, as long as people do not start building "pure MPLS-TP" networks from brand new boxes.

And this brings me to the following question: Do we really need co-routed bidirectional paths in MPLS-TP? What added value do they provide for the operators in addition to added complexity and, in the bottom line, added cost?
Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 28 Mar 2009 12:56:31 +0300

Neil,
I've just sent an email to Ben questioning added value of co-routed bidirectional paths.
And I agree with you that they may be quite often impossible to create for reasons beyond control of the network operators and network equipment vendors.

So again: do we need something that:

 1.
Definitely adds complexity (and cost) to the network boxes
 2.
In many cases cannot be provided
 3.
Does not provide any self-evident advantages

My 2c,
     Sasha
________________________________
From: [email-masked] [[email-masked]]
Sent: Saturday, March 28, 2009 12:36 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Sasha,

Not sure if this is the answer to your question or not, but to be truly co-routed this does not just apply to the layer network being considered but also all lower layer networks down to the duct, ie each link connection in layer N is co-routed in layer N-1...and this recuses to the duct.

In many cases the party owning layer N may not own all of the lower layers to the duct, so ensuring full co-routing may not be possible.

regards, Neil

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 28 March 2009 09:29
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Grigorij,

 1.

Regards,

     Sasha

Sasha,

Regards,
Grigorij

My 2c,
    Sasha

So how about:

Malcolm Betts
Nortel Networks

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

Andy, Ben and all,

to something like:

My 2c,
    Sasha

Ben,

Looks good to me.

Cheers,
Andy

---

From: <[email-masked]>
Date: Sat, 28 Mar 2009 10:12:47 -0000

Thanks Sasha, I have some views on why co-routing (to the duct) is
desirable (even if we can't ensure it), but I am going to see what other
views folks have here and then I'll respond....so this will be sometime
next week, and I hope that is OK.
 
regards, Neil

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: 28 March 2009 09:57
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; [email-masked];
Niven-jenkins,B,Ben,DMF R
	Subject: RE: [mpls-tp] Associated bidirectional transport path
requirements

	Neil,
	I've just sent an email to Ben questioning added value of
co-routed bidirectional paths.
	And I agree with you that they may be quite often impossible to
create for reasons beyond control of the network operators and network
equipment vendors.

	1.	
		Definitely adds complexity (and cost) to the network
boxes
	2.	
		In many cases cannot be provided
	3.	
		Does not provide any self-evident advantages

	My 2c,
	     Sasha

	Sasha,
	 
	Not sure if this is the answer to your question or not, but to
be truly co-routed this does not just apply to the layer network being
considered but also all lower layer networks down to the duct, ie each
link connection in layer N is co-routed in layer N-1...and this recuses
to the duct.  
	 
	In many cases the party owning layer N may not own all of the
lower layers to the duct, so ensuring full co-routing may not be
possible.
	 
	regards, Neil

[mailto:[email-masked]] On Behalf Of Alexander Vainshtein

		Grigorij,
		Sorry, but I am not sure I follow you. This is my
reading of the definitions:

		1.	
			A P2P path is bi-directional if the traffic can
flow in both directions (i.e. from end point A to end point Z and from
end point Z to end point A)
		2.	A bi-directional path can be : 

			*	
				Co-routed bidirectional if both
directions:

				*	
					Are setup, monitored and
protected as a single entity
				*	
					Cross exactly the same set of
intermediate nodes and links (in mutually reverse order)

			*	

				*	
					Its end points are aware of the
pairing relationship between two directions
				*	
					The paths for the two directions
have been setup, monitored and protected independently and hence do not
necessary traverse the same set of node of links.

		Did I miss something? And if I did, which requirements
can be reasonably applied to a bidirectional path that is neither a
co-routed nor an associated one?

		Regards,

		     Sasha

		Sasha,
		if the associated bidirectional path IS "a pair of
unidirectional paths that are used
		to support a bidirectional service" then I agree with
your point. But if the associated bidirectional is a bidirectional path
whose directions (for the luck of better term) may cross different nodes
and segments between the same pair of end-points, then it, the path,
should be treated as bidirectional first and associated second. In
latter interpretation an associated is more generic case and a co-routed
is a special case of bidirectional path. We've found that this is very
important to agree on one interpretation since it impacts many other
areas, e.g. linear protection.
		
		Regards,
		Grigorij

			Malcolm (and all),
			You definitely have a point here.
			However, "Associated bidirectional path" seems
to be exactly "A pair of unidirectional paths that are used
			to support a bidirectional service".
			Hence the second statement could be compressed
into something like
			
			"The end points of an associated bi-directional
path MUST be aware of the pairing relationship."
			
			My 2c,
			    Sasha

			Cc: [email-masked]

			Sasha, I think your text does not cover the
possibility of using a pair
			of (independent) uni directional paths to
support a bi directional
			service by providing an association at the end
points (only)
			
			So how about:
			
			32  The intermediate nodes OF A CO-ROUTED
BI-DIRECTIONL PATH at each
			(sub-)layer
			        MUST be aware about the pairing
relationship of the forward and
			the backward
			       directions OF THIS PATH.
			       The end points of a pair of uni
directional paths that are used
			to support a
			       bi directional service MUST be aware of
the pairing relationship
			of the
			       forward and reverse paths used to support
the bidirectional
			service.

			Malcolm Betts
			Nortel Networks
			
			-----Original Message-----
			
			Andy, Ben and all,
			I've scanned the Framework and Requirements
drafts (in their present
			form) and I've found the following:
			
			1. The notions "Associated bidirectional path"
and "Co-routed
			bidirectional path" are defined in the
			   Requirements draft.
			  - The definition of a associated bidirectional
path explicitly states
			that co-routing is not
			     required, meaning that the data plane of
intermediate nodes,
			generally speaking,
			     cannot be aware of the pairing relationship
			  - Unsurprisingly, the definition of a
co-routed bidirectional path
			includes co-routing
			
			2. The Framework draft does not mention
associated bidirectional paths
			at all.
			   It mentions bidirectional paths that, if so
required, would  be
			co-routed
			   ("it MUST be possible to configure..." -
Section 3.3,  Para 8). And
			it does not
			   mention (at least explicitly) the requirement
to setup, monitor and
			protect both directions
			   as a single entity (which seems to be the key
point of the
			definition in the Requirements
			   document)
			
			3. The Framework and Requirement documents seem
to treat the issue of
			pairing awareness
			   somewhat differently:
			   - the former requires such an awareness "at
each MEP, MIP or segment
			protection endpoint"
			   - the latter requires such an awareness at
each intermediate node
			(Requirement 32).
			
			Taken all this into account, it would probably
suffice to change
			Requirement 32 to from:
			
			  32  The intermediate nodes at each (sub-)layer
MUST be aware about
			      the pairing relationship of the forward
and the backward
			      directions belonging to the same co-routed
bidirectional
			      transport path.
			
			to something like:
			
			  32  The intermediate nodes OF A CO-ROUTED
BI-DIRECTIONL PATH at each
			(sub-)layer
			        MUST be aware about the pairing
relationship of the forward and
			the backward
			       directions OF THIS PATH.
			
			It would be nice to note that this arrangement
guarantees that such an
			awareness can be provided at every MEP, MIP or
segment protection
			endpoint.
			
			I also wonder whether the entire Definitions
section actually belongs to
			the Framework draft.
			Isn't that the first place you usually look at
when you encounter a term
			you do not recognize?
			
			My 2c,
			    Sasha
			
			Ben,
			
			Looks good to me.
			
			Cheers,
			Andy
			
			On Wed, Mar 25, 2009 at 4:32 PM, Ben
Niven-Jenkins
			<[email-masked]> wrote:
			>          (sub-)layer MUST be aware about the
pairing relationship of
			the
			>          forward and backward directions
belonging to the same
			associated

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 28 Mar 2009 15:56:48 +0300

Neil,
Of course it is OK to wait for next week.
Meanwhile, IMO one more point in your email deserves special attention:

 *
The term you use when you mention co-routed bidirectional paths is "desirable"
 *
The term the MPLS-TP requirements draft uses for the same is MUST (Requirement 31).

Do you feel that MUST is the appropriate requirement level to associate with something that cannot be ensured?

Regards,

     Sasha

From: [email-masked] [[email-masked]]
Sent: Saturday, March 28, 2009 1:12 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Thanks Sasha, I have some views on why co-routing (to the duct) is desirable (even if we can't ensure it), but I am going to see what other views folks have here and then I'll respond....so this will be sometime next week, and I hope that is OK.

regards, Neil

Cc: [email-masked]; [email-masked]; Niven-jenkins,B,Ben,DMF R

Neil,

 1.

My 2c,
     Sasha

Sasha,

regards, Neil

Grigorij,

 1.

Regards,

     Sasha

Sasha,

Regards,
Grigorij

My 2c,
    Sasha

So how about:

Malcolm Betts
Nortel Networks

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

Andy, Ben and all,

to something like:

My 2c,
    Sasha

Ben,

Looks good to me.

Cheers,
Andy

---

From: <[email-masked]>
Date: Sat, 28 Mar 2009 13:57:11 -0000

This is a valid point Sasha.  Indeed when one leases server layer
capacity off some other party one can never be quite sure how this will
be provided.....the only thing can do is set some
availability/performance SLA that it should meet. 
 
I suspect this has never consciously been thought about in the past
since traditional PDH/SDH/OTN transport networks are invariably
symmetrically routed.   Further, you may recall that I have tried to
alert folks to the issue of performance inheritance as this is something
that has also been taken for granted in the past wrt performance HRX
specifications...again PDH/SDH/OTN have no performance inheritance
concerns since the co-cs mode performance provided to clients is not
affected by traffic loading.  
 
And this is why *transparency* of transport networks is
important...which means:
-    the server layer treats all client bits equally
-    the server layer preserves client layer bit ordering
-    the server layer makes no attempt to infer meaning from client
symbols (ie a group of client bits) and never changes them
-    the server layer does not allow the traffic behaviour of client X
to affect the performance experienced by client Y
 
Aside=> I was just looking at some of FAT PWs stuff....this essentially
violates the above.
 
Now, whilst awaiting be able to talk with some other guys here in BT
next week to find out their view on this, here is why I think co-routing
to the duct is 'desirable'
-    symmetric delay behaviour...some clients might want this.......and
for customer groups (eg financial trading) having control over delay is
important....might also be true for some SAN clients
-    minimised the number of breaks/prot-sw events at layer N.......if
co-routed to the duct then all physical layer cuts kill both directions,
if not co-routed to the duct than physical layer cuts only kill one
direction....so for a value of N physical layer cut events over some
time period, one could see ~ 2N break/prot-sw events in the
non-co-routed case
 
Although I think nested TCM OAM sublayers are not a good idea, I believe
that nested MEPs/MIPs would require co-routing in the layer under
consideration.....though this does not require lower layer co-routing.
 
regards, Neil

	Sent: 28 March 2009 12:57

	Neil,
	Of course it is OK to wait for next week.
	Meanwhile, IMO one more point in your email deserves special
attention:

	*	
		The term you use when you mention co-routed
bidirectional paths is "desirable"
	*	
		The term the MPLS-TP requirements draft uses for the
same is MUST (Requirement 31).

	Do you feel that MUST is the appropriate requirement level to
associate with something that cannot be ensured? 

	Regards,

	     Sasha

[email-masked]

	Thanks Sasha, I have some views on why co-routing (to the duct)
is desirable (even if we can't ensure it), but I am going to see what
other views folks have here and then I'll respond....so this will be
sometime next week, and I hope that is OK.
	 
	regards, Neil

		Neil,
		I've just sent an email to Ben questioning added value
of co-routed bidirectional paths.
		And I agree with you that they may be quite often
impossible to create for reasons beyond control of the network operators
and network equipment vendors.

		1.	
			Definitely adds complexity (and cost) to the
network boxes
		2.	
			In many cases cannot be provided
		3.	
			Does not provide any self-evident advantages

		My 2c,
		     Sasha

		Sasha,
		 
		Not sure if this is the answer to your question or not,
but to be truly co-routed this does not just apply to the layer network
being considered but also all lower layer networks down to the duct, ie
each link connection in layer N is co-routed in layer N-1...and this
recuses to the duct.  
		 
		In many cases the party owning layer N may not own all
of the lower layers to the duct, so ensuring full co-routing may not be
possible.
		 
		regards, Neil

			Grigorij, 
			Sorry, but I am not sure I follow you. This is
my reading of the definitions:

			1.	
				A P2P path is bi-directional if the
traffic can flow in both directions (i.e. from end point A to end point
Z and from end point Z to end point A)
			2.	A bi-directional path can be : 

				*	

				*	
					Are setup, monitored and

				*	

				*	

			3.	Now comes the question: Is there a case
when a bi-directional path is neither a co-routed one nor an associated
one? I must admit that I do not see how this could happen.

			Did I miss something? And if I did, which
requirements can be reasonably applied to a bidirectional path that is
neither a co-routed nor an associated one?

			Regards,

			     Sasha

			From: Greg Mirsky [[email-masked]]
			Sent: Thursday, March 26, 2009 11:40 PM
			To: Alexander Vainshtein
			Cc: Malcolm Betts; Andrew G. Malis; Ben
Niven-Jenkins; [email-masked]
			Subject: Re: [mpls-tp] Associated bidirectional
transport path requirements

			Sasha,
			if the associated bidirectional path IS "a pair
of unidirectional paths that are used
			to support a bidirectional service" then I agree
with your point. But if the associated bidirectional is a bidirectional
path whose directions (for the luck of better term) may cross different
nodes and segments between the same pair of end-points, then it, the
path, should be treated as bidirectional first and associated second. In
latter interpretation an associated is more generic case and a co-routed
is a special case of bidirectional path. We've found that this is very
important to agree on one interpretation since it impacts many other
areas, e.g. linear protection.
			
			Regards,
			Grigorij

			On Thu, Mar 26, 2009 at 1:27 PM, Alexander
Vainshtein <[email-masked]> wrote:

				Malcolm (and all),
				You definitely have a point here.
				However, "Associated bidirectional path"
seems to be exactly "A pair of unidirectional paths that are used
				to support a bidirectional service".
				Hence the second statement could be
compressed into something like
				
				"The end points of an associated
bi-directional path MUST be aware of the pairing relationship."
				
				My 2c,
				    Sasha
				
				________________________________________
				From: Malcolm Betts [[email-masked]]
				Sent: Thursday, March 26, 2009 7:34 PM
				To: Alexander Vainshtein; Andrew G.
Malis; Ben Niven-Jenkins
				
				Cc: [email-masked]
				
				Subject: RE: [mpls-tp] Associated
bidirectional transport path requirements

				Sasha, I think your text does not cover
the possibility of using a pair
				of (independent) uni directional paths
to support a bi directional
				service by providing an association at
the end points (only)
				
				So how about:
				
				32  The intermediate nodes OF A
CO-ROUTED BI-DIRECTIONL PATH at each
				(sub-)layer
				        MUST be aware about the pairing
relationship of the forward and
				the backward
				       directions OF THIS PATH.
				       The end points of a pair of uni
directional paths that are used
				to support a
				       bi directional service MUST be
aware of the pairing relationship
				of the
				       forward and reverse paths used to
support the bidirectional
				service.

				Malcolm Betts
				Nortel Networks
				
				-----Original Message-----
				From: [email-masked]
[mailto:[email-masked]] On
				Behalf Of Alexander Vainshtein
				Sent: Thursday, March 26, 2009 1:52 AM
				To: Andrew G. Malis; Ben Niven-Jenkins
				Cc: [email-masked]
				Subject: Re: [mpls-tp] Associated
bidirectional transport path
				requirements
				
				Andy, Ben and all,
				I've scanned the Framework and
Requirements drafts (in their present
				form) and I've found the following:
				
				1. The notions "Associated bidirectional
path" and "Co-routed
				bidirectional path" are defined in the
				   Requirements draft.
				  - The definition of a associated
bidirectional path explicitly states
				that co-routing is not
				     required, meaning that the data
plane of intermediate nodes,
				generally speaking,
				     cannot be aware of the pairing
relationship
				  - Unsurprisingly, the definition of a
co-routed bidirectional path
				includes co-routing
				
				2. The Framework draft does not mention
associated bidirectional paths
				at all.
				   It mentions bidirectional paths that,
if so required, would  be
				co-routed
				   ("it MUST be possible to
configure..." - Section 3.3,  Para 8). And
				it does not
				   mention (at least explicitly) the
requirement to setup, monitor and
				protect both directions
				   as a single entity (which seems to be
the key point of the
				definition in the Requirements
				   document)
				
				3. The Framework and Requirement
documents seem to treat the issue of
				pairing awareness
				   somewhat differently:
				   - the former requires such an
awareness "at each MEP, MIP or segment
				protection endpoint"
				   - the latter requires such an
awareness at each intermediate node
				(Requirement 32).
				
				Taken all this into account, it would
probably suffice to change
				Requirement 32 to from:
				
				  32  The intermediate nodes at each
(sub-)layer MUST be aware about
				      the pairing relationship of the
forward and the backward
				      directions belonging to the same
co-routed bidirectional
				      transport path.
				
				to something like:
				
				  32  The intermediate nodes OF A
CO-ROUTED BI-DIRECTIONL PATH at each
				(sub-)layer
				        MUST be aware about the pairing
relationship of the forward and
				the backward
				       directions OF THIS PATH.
				
				It would be nice to note that this
arrangement guarantees that such an
				awareness can be provided at every MEP,
MIP or segment protection
				endpoint.
				
				I also wonder whether the entire
Definitions section actually belongs to
				the Framework draft.
				Isn't that the first place you usually
look at when you encounter a term
				you do not recognize?
				
				My 2c,
				    Sasha
				________________________________________
				From: [email-masked]
[[email-masked]] On Behalf Of
				Andrew G. Malis [[email-masked]]
				Sent: Thursday, March 26, 2009 1:54 AM
				To: Ben Niven-Jenkins
				Cc: [email-masked]
				Subject: Re: [mpls-tp] Associated
bidirectional transport path
				requirements
				
				Ben,
				
				Looks good to me.
				
				Cheers,
				Andy
				
				On Wed, Mar 25, 2009 at 4:32 PM, Ben
Niven-Jenkins
				<[email-masked]> wrote:
				>          (sub-)layer MUST be aware
about the pairing relationship of
				the
				>          forward and backward
directions belonging to the same
				associated

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 28 Mar 2009 08:54:00 +0000

OK, following list traffic and private comments, how about change
requirements 32 and insert requirements 33, 34, 35 worded as follows.

I have kept each as individual requirement to try to avoid ambiguity
introduced by having lots of text in a single requirement.

32  The end points of a co-routed bidirectional transport path MUST be aware
of the pairing relationship of the forward and reverse paths used to support
the bidirectional service.

33  The intermediate nodes (including MEPs, MIPs and other internal
functions as appropriate) of a co-routed bidirectional transport path at
each (sub-)layer MUST be aware of the pairing relationship of the forward
and the backward directions of that transport path.

34  The end points of an associated bidirectional transport path MUST be
aware of the pairing relationship of the forward and reverse paths used to
support the bidirectional service.

35  The intermediate nodes (including MEPs, MIPs and other internal
functions as appropriate) of a co-routed bidirectional transport path at
each (sub-)layer MAY be aware of the pairing relationship of the forward and
the backward directions of that transport path.

Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 28 Mar 2009 21:48:12 +0300

Ben,
Looks like 33 and 35 define the same requirement at two different levels: MUST and MAY.

Did I miss something?

Regards,
      Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ben Niven-Jenkins [[email-masked]]
Sent: Saturday, March 28, 2009 11:54 AM
To: Benjamin Niven-Jenkins; [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 29 Mar 2009 04:20:43 +0000

Sasha,

On 28/03/2009 09:49, "Alexander Vainshtein"
> [[Sasha]] Probably not. And one of the major obstacles is probably the
> requirement for "the pairing awareness in all the intermediate nodes" which
> would add quite a lot of state to the data plane of these nodes.

If one wants to make use of MIPs the MIP must be aware of the pairing
relationship. The question to me is: is the cost of the extra state less
than the operational saving resulting from the reduced operational
complexity that I believe co-routed bidirectional transport paths have?

> [[Sasha]] I do not object to having more text - as long as additional text
> clarifies things. Introducing a notion ("associated bidirectional") and then
> not using it does not really help. Please note that, in addition to the
> definition, the notion of an "associated bidirectional path" is only used once
> in the requirements draft - when it says that MPLS TP MUST support them along
> with co-routed bidirectional and unidirectional P2P path. At the same time
> your message seems to imply that this is actually going to be the most
> important/popular type of bidirectional path - at least, as long as people do
> not start building "pure MPLS-TP" networks from brand new boxes.

The original motivation behind MPLS-TP AFAIK was the thinking it would apply
to new boxes (or at least be a new technology in its own right). As it
reuses MPLS functionality when it came to IETF some of us wanted also to be
able to reuse MPLS-TP functionality in our MPLS networks.

I think the associated bidirectional case is probably of more relevance to
those of us in the latter camp. Specifying exhaustive requirements for
associated bidirectional in the MPLS-TP requirements smells to me like
restating the requirements for MPLS again. I do not see the value in that
and it risks introducing significant confusion.

> And this brings me to the following question: Do we really need co-routed
> bidirectional paths in MPLS-TP? What added value do they provide for the
> operators in addition to added complexity and, in the bottom line, added cost?

I would say yes we do. Today we have layer 2 and layer 3 services with
requirements for symmetric latency. Today we achieve that with network
engineering. If one wants to support those services on MPLS-TP the question
becomes is the added complexity introduced in MPLS-TP less than the network
engineering effort? I also believe co-routed bidirectional paths provide
operational benefits and reduced operational complexity which in turns leads
to lower operational cost and improved service for one's customers.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 29 Mar 2009 04:25:06 +0000

On 28/03/2009 09:56, "Alexander Vainshtein"
> Definitely adds complexity (and cost) to the network boxes

Box cost is only one element of the cost base for delivering a service. It
is often not the overriding factor.

> In many cases cannot be provided

Just because something does not apply in all cases does not mean it is not
useful. Co-routing in lower layers can often be ensured through non
technological means.

> Does not provide any self-evident advantages

See my other mail just now.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 29 Mar 2009 04:28:21 +0000

> something that cannot be ensured?

Please let's not have this discussion again.

The draft states:

   Although this document is not a protocol specification, the key words
   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
   interpreted as described in RFC 2119 [RFC2119] and are to be
   interpreted as instructions to the protocol designers producing
   solutions that satisfy the requirements set out in this document.

So MPLS-TP as a technology "toolbox" MUST provide a solution to the
requirements. It is up to individual vendors and operators which tools they
implement & deploy.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 29 Mar 2009 04:30:04 +0000

Cut & paste error - my fault for trying to do this on the plane when I
should have been sleeping :-) 35 should read:

35  The intermediate nodes (including MEPs, MIPs and other internal
functions as appropriate) of an ASSOCIATED bidirectional transport path at
each (sub-)layer MAY be aware of the pairing relationship of the forward and
the backward directions of that transport path.

Ben

On 28/03/2009 18:48, "Alexander Vainshtein"
<[email-masked]> wrote:

> From: [email-masked] [[email-masked]] On Behalf Of Ben
> Niven-Jenkins [[email-masked]]

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 29 Mar 2009 08:04:46 -0700

Totally agree and support.

Regards,
Greg

On Sat, Mar 28, 2009 at 9:30 PM, Ben Niven-Jenkins <
[email-masked]> wrote:

> > Looks like 33 and 35 define the same requirement at two different levels:
> MUST
> > and MAY.
> >
> > Did I miss something?
> >
> > Regards,
> >       Sasha
> ready to

---

From: [email-masked]
Date: Mon, 30 Mar 2009 10:58:44 +0800

Hi, Ben and Greg:
 I don't understand why to need be aware of the pairing relationship of 
the forward and backward directions of that path for intermediate nodes of 
associated bidirectional transport path?   I think it necessary to be 
aware of the pairing relationship  for two-end MEP .
do you provide good reason?
thank you
liu

2009-03-29 23:04

收件人
Ben Niven-Jenkins <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Regards,
Greg

35  The intermediate nodes (including MEPs, MIPs and other internal
functions as appropriate) of an ASSOCIATED bidirectional transport path at
each (sub-)layer MAY be aware of the pairing relationship of the forward 
and
the backward directions of that transport path.

Ben

On 28/03/2009 18:48, "Alexander Vainshtein"
<[email-masked]> wrote:

> Ben,
> Looks like 33 and 35 define the same requirement at two different 
levels: MUST
Ben
requirements
ready to
>>> Following a chat with Lou I will expand the text around the 
requirement on

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 30 Mar 2009 07:11:03 +0200

Ben,

> I do not want to build an MPLS-TP network. 
> I want to use some MPLS-TP functionality in my existing deployed
boxes/implementations.

This is an interesting new application. Please provide some further detail
so that it is possible to judge if this adds requirements beyond the scope
of MPLS-TP on the tools under development of MPLS-TP.

> My MPLS network does not support co-routed bidirectional LSPs.

This is a basic deviation from what I understand to be the case in
"transport networks".

> I need the end points of an LSP to be able to associate the forward and
backwards
> directions in order for them to know the appropriate "back channel" for
traffic
> originating out of that LSP end point.

What type of traffic are you referring to in the above sentence? Is it OAM
traffic, e.g. RDI/BDI?

Your words suggest that your network deploys mp2p LSPs, is this correct? If
so, then I assume that the following case is applicable:
Assume that in your network 500 nodes are to be interconnected with LSPs.
There will then be 500 mp2p LSPs, each with one output port and 499 input
ports. These 500 mp2p LSPs emulate a 500 port VLAN. Ethernet OAM has been
designed to operate in such mp2p environment and I believe that the Y.1731
CCM PDU and G.8021/802.1ag ETH MEPs would be reusable with minor
modifications as MPLS MEPs. 

- Each mp2p LSP is a Maintenance Entity Group (MEG), and the set of 500 mp2p
LSPs forms a MEG Group. This MEG Group can be uniquely identified by a
common value in the most significant bits of the MEGID.

- Each MPLS MEP has one input port and 499 output ports. Such MPLS MEP
generates a MPLS CCM packet per output port, and receives 499 CCM packets on
its input port. Those CCM PDUs (with MPLS specific header (i.e. ACH)) have a
MEGID and a MEPID. If you assign each of the 500 MPLS MEPs a unique MEPID in
the range 1 to 500, then each MPLS CCM packet carries a Source MEPID. The
MSBs of the MEGID carry the MEG Group ID. The least significant bits of the
MEGID can then carry the Destination MEPID.

- The MEGID/MEPID now carries the following informaiton: MEGID=<MEG Group
ID><Destination MEPID>, MEPID=<Source MEPID>. 

- If one of the mp2p LSPs is interrupted and e.g. 200 input ports are
disconnected, its MEP Sink function will detect 200 Loss of CCM conditions.
The MEGID/MEPID (and thus the source MEPIDs) of these 200 lost CCMs are
known at the MEP Sink function, and it is possible to "associate the forward
and backwards directions" so that the RDI bit in the MPLS CCM packets of the
associated backward mp2p LSPs can be set. I.e. the MPLS CCM packets that are
generarted with their MEGID LSB bits carrying those Source MEPID values will
have to set their RDI bit.

MPLS LBM/LBR
============
If you want to use on-demand loopback OAM, then you can perform loopback
tests between a MPLS MEP and another MPLS MEP and between a MPLS MEP and a
MPLS MIP. The MPLS MIP operates similar to the PBB-TE MIP specified; there
is one MPLS MIP associated with the MEG Group ID (i.e. associated with the
500 mp2p LSPs) and the MPLS LBM PDU will carry an additional TLV containing
the "reverse-LSP label" (see clause 21.7.5/802.1Qay for TLV with compatible
reverse-VID). The MPLS LBM packet is send on one of the 499 LSPs, i.e. on an
LSP which includes the MPLS MIP with the target loopback location. The
reverse-LSP label field of the LBM TLV contains the value of the LSP label
which will be used to transport the MPLS LBR packet back to the Source MEP.
When the LBM packet arrives at the target MIP, this MIP will extract the
reverse-LSP label and add this to the generated LBR packet so this LBR
packet will be send back to the originating MEP.

Y.1731/802.1ag/ay CCM and LBM/LBR OAM PDUs can be reused as mp2p MPLS LSP
OAM PDUs on associated bi-directional transport paths. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: vrijdag 27 maart 2009 0:15
To: Alexander Vainshtein; Andrew G. Malis
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Sasha,

Ben

co-routed
> Requirement
> 32 to from:

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 30 Mar 2009 07:23:57 +0200

Liu,
 
If you want to perform a loopback test on an intermediate point in a LSP,
then you need to be aware of the pairing relationship. 
Refer also to the email I send 10 minutes ago in which I describe how we can
perform loopback test in MPLS with mp2p LSPs.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: maandag 30 maart 2009 4:59
To: Greg Mirsky
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Hi, Ben and Greg: 
 I don't understand why to need be aware of the pairing relationship of the
forward and backward directions of that path for intermediate nodes of
associated bidirectional transport path?   I think it necessary to be aware
of the pairing relationship  for two-end MEP . 
do you provide good reason? 
thank you 
liu 

2009-03-29 23:04 

收件人

抄送

主题

Regards,
Greg

On Sat, Mar 28, 2009 at 9:30 PM, Ben Niven-Jenkins <
<mailto:[email-masked]> [email-masked]> wrote:

Ben

On 28/03/2009 18:48, "Alexander Vainshtein" 
< <mailto:[email-masked]>

MUST
> From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> [email-masked]] On Behalf Of Ben
> Niven-Jenkins [ <mailto:[email-masked]>
[email-masked]]
> To: Benjamin Niven-Jenkins;  <mailto:[email-masked]> [email-masked]
requirements
and
> < <mailto:[email-masked]> [email-masked]>
wrote:
>> < <mailto:[email-masked]> [email-masked]>
wrote:
>>>  <mailto:[email-masked]> [email-masked]
>>>  <https://www.ietf.org/mailman/listinfo/mpls-tp>
>  <mailto:[email-masked]> [email-masked]
>  <https://www.ietf.org/mailman/listinfo/mpls-tp>

_______________________________________________
mpls-tp mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/mpls-tp>
https://www.ietf.org/mailman/listinfo/mpls-tp 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.

---

From: [email-masked]
Date: Mon, 30 Mar 2009 13:58:22 +0800

maarten:
 thank you for reply, according to your saying , for 1+1 or 1:1 protection 
may need to consider for associated bidirectional path again. we can't 
regard a pair of associated bidirectional path simply as two individual 
forward and backward one-directional path.
so I advise to adding 1+1 or 1:1 protection solution in mpls-tp surivive 
draft.
do you think so.

regards
liu

Maarten Vissers <[email-masked]> 
2009-03-30 13:23

收件人
[email-masked], 'Greg Mirsky' <[email-masked]>
抄送
[email-masked]
主题
RE: [mpls-tp] Associated bidirectional transport path requirements

Liu,
 
If you want to perform a loopback test on an intermediate point in a LSP, 
then you need to be aware of the pairing relationship. 
Refer also to the email I send 10 minutes ago in which I describe how we 
can perform loopback test in MPLS with mp2p LSPs.
 
Regards,
Maarten

Hi, Ben and Greg: 

收件人

Regards,
Greg

Ben

levels: MUST
Ben
requirements
and
ready to
requirement on

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 30 Mar 2009 08:52:44 -0500

Neil,
 
    You offered a small(ish) number of fairly complicated comments on
the MPLS-TP NM
Requirements draft during the poll to accept it as a WG draft.  I am not
explicitly including
them in this mail, except indirectly in describing changes we propose to
make to address
them.
 
    We propose to simplify and clarify section 5.1 by eliminating the
bullets explicitly listed
in the table in the MPLS-TP OAM requirements draft and adding the
following as the second
paragraph in this section:
 
"The MPLS-TP NE MUST support supervision of the OAM mechanisms that are
deployed
 for supporting the OAM requirements defined in [3]."
 
(where [3] is the reference in our document to the MPLS-TP OAM
Requirements document)
 
The "added" text was previously the next to last paragraph in this
section, and moving it 
closer to the beginning of the section gives it the somewhat greater
emphasis we feel it 
deserves - as well as helping to give context for the remaining text in
the section and
allow us to remove redundant (and potentially conflicting) text.
 
Specifically what we propose to remove is the text on supervision of
alarms based on 
native OAM, traffic loss measurement, misinsertion checking, diagnostic
testing, route
determination and remote defect indication.  We feel that this either
addresses most of
your comments, or diverts them to more appropriate discussion on OAM
requirements
defined in the OAM Requirements draft.
 
In section 6.5 (OAM Configuration), we propose to change the first
sentence of the third
paragraph to read:
 
"The MPLS-TP NE MUST support the capability to configure the OAM
entities/functions
 as part of the LSP setup and tear-down, including ..."
 
We feel that this proposed change helps to clarify the fact that OAM is
tied to a service
that requires it, coming and going with it.
 
Hopefully, these changes improve the document and address your comments
to a point
at which you are not immediately going to yell at us (or point fingers
and snicker)...  :-)
 
--
Eric

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 30 Mar 2009 09:43:17 -0500

Folks,
 
In addition to proposed changes mentioned in response to comments from
Rolf and
Neil, we also found other issues we wish to address with the following
changes:
 
Text in several places was not consistent with the final disposition of
the terms we
ended up using in the MPLS-TP requirements (NOT NM requirements) draft
that Ben
is working on.  Because the changes - though small - effectively
reversed the sense
of the two types of bi-directional LSPs, there are some minor structural
changes (in
section 7.2.2, in particular) necessary to accomodate this terminology
change.
 
Specific changes required to do this are:
 
Section 6.5 (OAM Configuration), third paragraph: insert "co-routed"
prior to the
phrase bi-directional point-to-point, and change "associated
uni-directional" to
"associated bi-directional".
 
As an unrelated issue, found while looking at this text, we noticed that
we had not
included the p2p uni-directional case - for which there is presumable
applicability in
at least some corner cases.  Our proposed change to address this is to
replace
"point-to-multipoint" with "(both point-to-point and
point-to-multipoint)".  Also, we 
feel there is no grammatical purpose in repeating "connection" three
times in this
(already long) sentence, and propose to remove the first two
occurrences.
 
To effect the changes in section 7.2.2, we propose to:
 
- add "(both co-routed and associated)" to the first bullet on
bi-directional packet
  loss ratio, and eliminate (most of) the second bullet (which currently
addresses 
  the now defunct concept to an "associated uni-directional p2p"
connection).
- add a note to clarify that, in this newly combined first bullet, for
non-co-routed
  (i.e. - associated bi-directional) connections loss measurements only
make any
  sort of sense at the end points.
- In the text on Delay measurement, add a new bullet to address
"associated bi-
  directional (P2P) connection[s]".
 
Again in unrelated changes, we've noted that there ahve been issues with
the two
sections relating to security and potential confusion/ambiguity over the
content of
these sections.  We propose to make minor structural changes to fix
this.
 
Specifically:
 
- Remove the empty subsection on Data Channel Security (currently
section 8.3).
- Remove the subheading in section 8.1 "Security of Management
Communications"
- In section 9 (the required "Security Considerations" section, we
propose to cut 
  most fo this text out and replace it with the following:
 
"Section 8 includes a set of security requirements that apply to MPLS-TP
 network management.
 
"Solutions MUST provide mechanisms to prevent unauthorized and/or
unauthenticated
 access to private information by network elements, systems or users.
 
"Performance of diagnostic functions and path characterization involves
extracting a
 significant amount of information about the network construction that
the network
 operator MAY consider private."
 
Finally, we will need to add a reference to the GAL-GACH document to
accomodate
text in the appendix (earlier proposed by Adrian).
 
If anyone has objections to these proposed changes, or would like to
suggest some
improvements, please respond to this mail - including at least myself
and my to 
co-editors in your response.
 
Thanks in advance...
 
--
Eric Gray

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 30 Mar 2009 14:57:33 -0400

Hi Liu,
please note that in regard to intermediate nodes of associated
bi-directional TP-LSP this awareness is only "MAY", optional. I prefer it
being explicitly mentioned though since I see associated bi-directional
TP-LSP as bi-directional transport entity. Thus its linear 1:1 protection
behaves as 1:1 linear protection for a co-routed bidirectional path. If such
association is maintaned then it is possible, I think, to apply segment
protection to an associated bi-directional path terminating protection
segments at head-ends and intersection nodes.

Regards,
Greg

2009/3/29 <[email-masked]>

>  *Greg Mirsky <[email-masked]>*
> On Sat, Mar 28, 2009 at 9:30 PM, Ben Niven-Jenkins <*
> [email-masked]* <[email-masked]>> wrote:
> <[email-masked]* <[email-masked]>>
> wrote:
>
> > Ben,
> > From: [email-masked]* <[email-masked]> [*
> [email-masked]* <[email-masked]>] On Behalf Of Ben
> > Niven-Jenkins [[email-masked]*<[email-masked]>
> ]
> > To: Benjamin Niven-Jenkins; [email-masked]* <[email-masked]>
> > <[email-masked]* <[email-masked]>> wrote:
> >
> >> <[email-masked]* <[email-masked]>>
> wrote:
> >>
> >>> Folks,
> >>>
> >>> [email-masked]* <[email-masked]>
> >>> *https://www.ietf.org/mailman/listinfo/mpls-tp*<https://www.ietf.org/mailman/listinfo/mpls-tp>
> >>
> >
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/mpls-tp*<https://www.ietf.org/mailman/listinfo/mpls-tp>
>
> mpls-tp mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/mpls-tp*<https://www.ietf.org/mailman/listinfo/mpls-tp>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 30 Mar 2009 22:07:48 +0300

Greg and all,
Please note that, generally speaking, the set of common intermediate nodes for two directions of an associated bidirectional path can be empty. And intermediate nodes that are not common to the two directions cannot be aware of the pairing relationship...

IMHO and FWIW:
- The overall added value of this optional requirement is not high
- The restriction (only common intermediate nodes) should be mentioned explicitly.

My 2c,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Greg Mirsky [[email-masked]]
Sent: Monday, March 30, 2009 9:57 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Liu,
please note that in regard to intermediate nodes of associated bi-directional TP-LSP this awareness is only "MAY", optional. I prefer it being explicitly mentioned though since I see associated bi-directional TP-LSP as bi-directional transport entity. Thus its linear 1:1 protection behaves as 1:1 linear protection for a co-routed bidirectional path. If such association is maintaned then it is possible, I think, to apply segment protection to an associated bi-directional path terminating protection segments at head-ends and intersection nodes.

Regards,
Greg

2009/3/29 <[email-masked]<mailto:[email-masked]>>

Hi, Ben and Greg:
 I don't understand why to need be aware of the pairing relationship of the forward and backward directions of that path for intermediate nodes of associated bidirectional transport path?   I think it necessary to be aware of the pairing relationship  for two-end MEP .
do you provide good reason?
thank you
liu

Greg Mirsky <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2009-03-29 23:04

收件人

Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>>

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Regards,
Greg

On Sat, Mar 28, 2009 at 9:30 PM, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>> wrote:
Cut & paste error - my fault for trying to do this on the plane when I
should have been sleeping :-) 35 should read:

Ben

On 28/03/2009 18:48, "Alexander Vainshtein"
<[email-masked]<mailto:[email-masked]>> wrote:

> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Ben
> Niven-Jenkins [[email-masked]<mailto:[email-masked]>]
> To: Benjamin Niven-Jenkins; [email-masked]<mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 30 Mar 2009 16:49:03 -0700

Hi Sasha,
I agree with your suggestion regarding common intermediate nodes of
associated bi-directional path. Would following work:
Only common nodes that are aware of pairing relationship between forward and
backward directions of associated bidirectional path can be used as
end-points of a protected segment of that transport path.

Regards,
Greg

2009/3/30 Alexander Vainshtein <[email-masked]>

>  Greg and all,
> Please note that, generally speaking, the set of common intermediate nodes
> for two directions of an associated bidirectional path can be empty. And
> intermediate nodes that are not common to the two directions cannot be aware
> of the pairing relationship...
>
> IMHO and FWIW:
>  ------------------------------
> *From:* [email-masked] [[email-masked]] On Behalf Of
> Greg Mirsky [[email-masked]]
> *Sent:* Monday, March 30, 2009 9:57 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
>
> *Subject:* Re: [mpls-tp] Associated bidirectional transport path
> requirements
>
>  Hi Liu,
>> the forward and backward directions of that path for intermediate nodesof associated bidirectional
>> transport path?   I think it necessary to be aware of the pairing
>> relationship  for two-end MEP .

---

From: [email-masked]
Date: Tue, 31 Mar 2009 09:42:13 +0800

hi, all:
 thank all for reply and explain, I support all's opinions and 
suggestions. for linear 1:1 end to end  protection and 1:1 segment 
protection . if one directional path of working pairing associated 
bidirectional path is failed, is it necessary for another directional path 
of working pairing associated bidirectional path ,though it  is well, need 
to switch into relative directional path of protectional pairing 
associated bidirectional path?
do you think so?
regards
liu

2009-03-31 07:49

收件人
Alexander Vainshtein <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Sasha,
I agree with your suggestion regarding common intermediate nodes of 
associated bi-directional path. Would following work:
Only common nodes that are aware of pairing relationship between forward 
and backward directions of associated bidirectional path can be used as 
end-points of a protected segment of that transport path.

Regards,
Greg

2009/3/30 Alexander Vainshtein <[email-masked]>
Greg and all,
Please note that, generally speaking, the set of common intermediate nodes 
for two directions of an associated bidirectional path can be empty. And 
intermediate nodes that are not common to the two directions cannot be 
aware of the pairing relationship...
 
IMHO and FWIW:
- The overall added value of this optional requirement is not high
- The restriction (only common intermediate nodes) should be mentioned 
explicitly.
 
My 2c,
     Sasha

Hi Liu,
please note that in regard to intermediate nodes of associated 
bi-directional TP-LSP this awareness is only "MAY", optional. I prefer it 
being explicitly mentioned though since I see associated bi-directional 
TP-LSP as bi-directional transport entity. Thus its linear 1:1 protection 
behaves as 1:1 linear protection for a co-routed bidirectional path. If 
such association is maintaned then it is possible, I think, to apply 
segment protection to an associated bi-directional path terminating 
protection segments at head-ends and intersection nodes.

Regards,
Greg

Hi, Ben and Greg: 

收件人

Regards,
Greg

Ben

levels: MUST
Ben
requirements
and
ready to
requirement on

---

From: <[email-masked]>
Date: Tue, 31 Mar 2009 09:04:34 +0100

Thanks Eric,  That looks fine.  regards, Neil

	From: Eric Gray [mailto:[email-masked]] 
	Sent: 30 March 2009 14:53
	To: Harrison,N,Neil,CXM R; [email-masked]
	Cc: Lam, Hing-Kam (Kam); Scott Mansfield; Eric Gray
	Subject: Re: you comments during the poll to adopt the MPLS-TP
NM Requirements draft as an MPLS WG draft

	Neil,
	 
	    You offered a small(ish) number of fairly complicated
comments on the MPLS-TP NM
	Requirements draft during the poll to accept it as a WG draft.
I am not explicitly including
	them in this mail, except indirectly in describing changes we
propose to make to address
	them.
	 
	    We propose to simplify and clarify section 5.1 by
eliminating the bullets explicitly listed
	in the table in the MPLS-TP OAM requirements draft and adding
the following as the second
	paragraph in this section:
	 
	"The MPLS-TP NE MUST support supervision of the OAM mechanisms
that are deployed
	 for supporting the OAM requirements defined in [3]."

	The "added" text was previously the next to last paragraph in
this section, and moving it 
	closer to the beginning of the section gives it the somewhat
greater emphasis we feel it 
	deserves - as well as helping to give context for the remaining
text in the section and
	allow us to remove redundant (and potentially conflicting) text.
	 
	Specifically what we propose to remove is the text on
supervision of alarms based on 
	native OAM, traffic loss measurement, misinsertion checking,
diagnostic testing, route
	determination and remote defect indication.  We feel that this
either addresses most of
	your comments, or diverts them to more appropriate discussion on
OAM requirements
	defined in the OAM Requirements draft.
	 
	In section 6.5 (OAM Configuration), we propose to change the
first sentence of the third
	paragraph to read:

	We feel that this proposed change helps to clarify the fact that
OAM is tied to a service
	that requires it, coming and going with it.
	 
	Hopefully, these changes improve the document and address your
comments to a point
	at which you are not immediately going to yell at us (or point
fingers and snicker)...  :-)
	 
	--
	Eric

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 31 Mar 2009 11:34:15 +0100

OK,

I have added the following note in the section on protection:

Note: Only nodes that are aware of the pairing relationship between the
forward and backward directions of an associated bidirectional transport
path can be used as end points to protect all or part of that transport
path.

Ben

On 31/03/2009 00:49, "Greg Mirsky" <[email-masked]> wrote:

>>>> [[email-masked]*<[email-masked]>
>>> ]

---

From: [email-masked]
Date: Tue, 31 Mar 2009 20:51:23 +0800

Hi Ben,

I think this assertion is only valid in 1:1 linear protection. In the case 
of 1+1 linear protection and ring protection,the forward and the backward 
LSP can be protected individually, since no APS informations are need to 
exchange between two end points of the protection domain.

Regards,
Suhui

2009-03-31 18:34

收件人
Greg Mirsky <[email-masked]>, Alexander Vainshtein 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

OK,

Ben

and
>> intermediate nodes that are not common to the two directions cannot be 
aware
>> - The restriction (only common intermediate nodes) should be mentioned
such
>>> the forward and backward directions of that path for intermediate 
nodesof
>>> associated bidirectional
>>>> 32  The end points of a co-routed bidirectional transport path MUST 
be
>>> aware
>>>> aware of the pairing relationship of the forward and reverse paths 
used
>>> to
>>>>>           (sub-)layer MUST be aware about the pairing relationship 
of
>>>>>> associated bidirectional transport paths to try and clear up some 
of
>>>>>> IMO any more than a few clarifying statements belongs in the 
framework
>>> draft
>>>>>> *https://www.ietf.org/mailman/listinfo/mpls-tp*<
https://www.ietf.org/mail
>>>>>> man/listinfo/mpls-tp>
>>>> *https://www.ietf.org/mailman/listinfo/mpls-tp*<
https://www.ietf.org/mailma
>>>> n/listinfo/mpls-tp>
>>> **https://www.ietf.org/mailman/listinfo/mpls-tp*<
https://www.ietf.org/mailma
>>> n/listinfo/mpls-tp>
others.
system.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 31 Mar 2009 09:43:56 -0400

Hi Suhui,
I'd point out that for both 1+1 and Ring Protection of an Associated
Bi-directional TP-LSP protection switchover can work (optional) the same way
as for Co-routed path because both end-points must be aware of the pairing
relationship between the forward and backward directions. Thus, I think, the
version Ben proposed is accurate. Whether Associated Bi-directional TP-LSP
can be protected as two Unidirectional paths can be discussed in the MPLS-TP
Survivability Framework document. Would you agree?

Regards,
Greg

2009/3/31 <[email-masked]>

>  *Ben Niven-Jenkins <[email-masked]>*
> Greg Mirsky <[email-masked]>, Alexander Vainshtein <
> [email-masked]>
>  抄送
> "[email-masked]" <[email-masked]>  主题
> >>> <[email-masked]* <[email-masked]
> >>
> >>> wrote:
> >>>
> >>>> Ben,

---

From: [email-masked]
Date: Tue, 31 Mar 2009 22:24:39 +0800

Hi Greg,

I see what you mean, and it is ok for me if this note just describes the 
case that Associated Bi-directional TP-LSP is protected as one entity. 

Regards
Suhui

2009-03-31 21:43

收件人
[email-masked]
抄送
Ben Niven-Jenkins <[email-masked]>, Alexander Vainshtein 
<[email-masked]>, "[email-masked]" <[email-masked]>, 
[email-masked]
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Suhui,
I'd point out that for both 1+1 and Ring Protection of an Associated 
Bi-directional TP-LSP protection switchover can work (optional) the same 
way as for Co-routed path because both end-points must be aware of the 
pairing relationship between the forward and backward directions. Thus, I 
think, the version Ben proposed is accurate. Whether Associated 
Bi-directional TP-LSP can be protected as two Unidirectional paths can be 
discussed in the MPLS-TP Survivability Framework document. Would you 
agree?

Regards,
Greg

Hi Ben, 

Regards, 
Suhui 

收件人

OK,

Ben

and
aware
such
nodesof
be
used
of
of
framework
others.
system.

---

From: [email-masked]
Date: Wed, 1 Apr 2009 09:42:14 +0800

hi, guy:
 about 1:1 protection of associated bidirectional path, I have discussed 
the problem with jiang in huawei  a few days ago. if we don't regards 
associated bidirectional path as two unidirectional paths, we consider 1:1 
protections of associated bidirectional path differ from 1:1 protection of 
two unidirectional paths. thank you.

regards
liu

收件人
[email-masked]
抄送
[email-masked], "[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Suhui,

Regards,
Greg

Hi Ben, 

Regards, 
Suhui 

收件人

OK,

Ben

and
aware
such
nodesof
be
used
of
of
framework
others.
system.