Re: [Teas] A clarification request for draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

Hi Loa,

Thank you for your review and comments.

Please see inline .. <RG> ..

On 2015-02-21 6:03 AM, "Loa Andersson" <[e-mail]> wrote:

>Folks,
>
>We might be close requiring the obvious, but I would feel more
>comfortable if the draft said (in section 5.2) were a little bit
>clearer.
>
>It was changed from:
>	 		
>    A node initiating a Path message containing an ASSOCIATION or
>    Extended ASSOCIATION Object with the Association Type set to "Single
>    Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object
>    in the Path message of the LSP when it wishes to control the reverse
>    LSP originating on the other endpoint node.
>
>To:
>    A node initiating a Path message containing an ASSOCIATION or
>    Extended ASSOCIATION Object with the Association Type set to "Single
>    Sided Associated Bidirectional LSP" MUST include a REVERSE_LSP Object
>    in the Path message of the LSP.
>
>Maybe:	
>
>    When a node initiates setup of an LSP using a PATH message containing
>    an ASSOCIATION or Extended ASSOCIATION Object, and the Association
>    is Type "Single Sided Associated Bidirectional LSP", the PATH message
>    MUST carry the REVERSE_LSP Object.
>
>I won't insist on a change, what is there is probably good enough, if
>what I written is clearer and you want to use, use it.


<RG> Reworded this text in the latest revision (05). May be it reads
better now.


>
>However, there were one more thing that bothered me, we appear to be
>changing the rules that applies to the REVERSE_LSP Object. Before it
>was "optional" now it becomes "mandatory".
>
>The authors says that they have not deployed any implementation that
>follows the old rule. This is fine, but are we sure that no one else
>has? Do we need to take steps to make sure that this is not the case?


<RG> Your point is fair. However, the initiating node of such
implementation needs to somehow tell the third party remote node to either
trigger or not trigger the reverse LSP. As this was not specified in the
draft, such implementation may not be interoperable, IMO.


Thanks,
Rakesh


>/Loa
>
>
>
>
>On 2015-02-21 00:33, Lou Berger wrote:
>> Loa has a fair point.  If the draft is ambiguous on this point, it
>> should be clarified.
>>
>> Loa,
>>      Can you take a look at the latest rev of the draft and let us know
>> if you think is sufficiently clear?
>>
>> Thanks,
>> Lou
>>
>> On 2/20/2015 10:39 AM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Loa,
>>>
>>> This is for the associated bidirectional LSPs when using single sided
>>> provisioning.
>>> Specially, when the initiating node is inserting the ASSOCIATION Object
>>> with Association Type "Single Sided Associated Bidirectional LSP" to
>>> trigger creation of reverse LSP on the egress node.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> On 2015-02-20 8:30 AM, "Loa Andersson" <[e-mail]> wrote:
>>>
>>>> Lou,
>>>>
>>>> There are lots of "forward LSPs" out there, what is the criteria more
>>>> in detail where the REVERSE_LSP Object will be required if we choose
>>>> option 1?
>>>>
>>>> /Loa
>>>>
>>>> On 2015-02-18 10:09, Lou Berger wrote:
>>>>> Some options:
>>>>> a) Always require a  REVERSE_LSP Object in the forward LSP
>>>> --
>>>>
>>>>
>>>> Loa Andersson                        email: [e-mail]
>>>> Senior MPLS Expert                          [e-mail]
>>>> Huawei Technologies (consultant)     phone: [phone]
>>>>
>>>> _______________________________________________
>>>> Teas mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/teas
>>> _______________________________________________
>>> Teas mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/teas
>>>
>>
>>
>
>-- 
>
>
>Loa Andersson                        email: [e-mail]
>Senior MPLS Expert                          [e-mail]
>Huawei Technologies (consultant)     phone: [phone]