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

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 31 Mar 2009 14:07:41 +0100

Sasha,

As you were the one who asked for this to be explicitly mentioned can you
work with Suhui to get a wording you are both happy with and I will include.

I have now updated the requirements and have a new version (-06) ready to
publish and liaise to ITU-T so a fast turn around (24 hours) would be
appreciated as this is the only outstanding comment on the draft.

Ben

On 31/03/2009 13:51, "[email-masked]" <[email-masked]> wrote:

> 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
> 
> 
> 
> 
> Ben Niven-Jenkins <[email-masked]>
> 发件人:  [email-masked]
> 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,
> 
> 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:
> 
>> 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
>>> 
>>>  ------------------------------
>>> *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]>
>>> 
>>>> 
>>>> 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
> nodesof
>>>> 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]>*
>>>>  发件人:  [email-masked]
>>>> 
>>>> 2009-03-29 23:04
>>>>    收件人
>>>>  Ben Niven-Jenkins <[email-masked]>
>>>>   抄送
>>>>  "[email-masked]" <[email-masked]>
>>>>   主题
>>>>    Re: [mpls-tp] Associated bidirectional transport path requirements
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Totally agree and support.
>>>> 
>>>> Regards,
>>>> Greg
>>>> 
>>>> On Sat, Mar 28, 2009 at 9:30 PM, Ben Niven-Jenkins <*
>>>> [email-masked]* <[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:
>>>> 
>>>> 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]*
> <[email-masked]>>
>>>> wrote:
>>>> 
>>>>> 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]> [*
>>>> [email-masked]* <[email-masked]>] On Behalf Of Ben
>>>>> Niven-Jenkins
>>>>> [[email-masked]*<[email-masked]>
>>>> ]
>>>>> Sent: Saturday, March 28, 2009 11:54 AM
>>>>> To: Benjamin Niven-Jenkins; [email-masked]* <[email-masked]>
>>>>> Subject: Re: [mpls-tp] Associated bidirectional transport path
>>>> requirements
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> On 25/03/2009 23:32, "Benjamin Niven-Jenkins"
>>>>> <[email-masked]* <[email-masked]>>
>>>> wrote:
>>>>> 
>>>>>> 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]* <[email-masked]>>
>>>> wrote:
>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> mpls-tp mailing list
>>>>>>> [email-masked]* <[email-masked]>
>>>>>>> *https://www.ietf.org/mailman/listinfo/mpls-tp*<
> https://www.ietf.org/mail
>>>>>>> man/listinfo/mpls-tp>
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> mpls-tp mailing list
>>>>> [email-masked]* <[email-masked]>
>>>>> *https://www.ietf.org/mailman/listinfo/mpls-tp*<
> https://www.ietf.org/mailma
>>>>> n/listinfo/mpls-tp>
>>>> 
>>>> _______________________________________________
>>>> mpls-tp mailing list*
>>>> [email-masked]* <[email-masked]>*
>>>> **https://www.ietf.org/mailman/listinfo/mpls-tp*<
> https://www.ietf.org/mailma
>>>> n/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.
>>>> This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.
>>>> 
>>>> 
>>> 
>> _______________________________________________
>> mpls-tp mailing list
>> [email-masked]
>> 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.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.