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

From: Lou Berger <[email-masked]>
Date: Fri, 03 Apr 2009 16:52:37 -0400

Ben,
	Given the ever expanding implications of this option, (1st: 
intermediate loopback, and 2nd intermediate/segment bidirectional 
protection). I think we need to either (a) enumerate this and the 
additional functions as requirements or (b) change req 35 from MAY to 
SHOULD NOT.

I also strongly agree with the point made by Alexander (Sasha, if I may) 
in his mail of 3/30/2009 3:07 PM that we are introducing a tremendous 
amount of complexity for low value.

I think that is worth noting that much, if not all, the same goals OAM 
and protection can be accomplished via stacking an MPLS-TP co-routed 
LSPs (as a layer) on top of associated MPLS-TP LSPs, and this is already 
covered/implied by your requirements 32-34.   In short I think we should 
follow (b) above.

Again, the implications of the current discussion is quite significant 
additional mechanisms for something that is both optional and solvable 
via layering.

Lou

On 3/29/2009 12:30 AM, Ben Niven-Jenkins 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]>  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]] 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
>>
>> 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]>  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]>  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]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>> _______________________________________________
>> 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
>
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 03 Apr 2009 22:03:22 +0100

Happy to change to SHOULD NOT. The requirement for association for me exists
only at the end points - think something analogous to a PW which runs over
two unidirectional LSPs - it only requires association at the PW end points.

Ben

---

From: Lou Berger <[email-masked]>
Date: Fri, 03 Apr 2009 17:25:01 -0400

I agree 100%.

Thanks,
Lou

On 4/3/2009 5:03 PM, Ben Niven-Jenkins wrote:
> On 03/04/2009 21:52, "Lou Berger"<[email-masked]>  wrote:
>
>> Ben,