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

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

Hi Lou, WG,

Thanks for the summary.

I support option (a).

Also copying co-authors if there is any objection.

thanks,
Rakesh



On 2015-02-17 9:09 PM, "Lou Berger" <[e-mail]> wrote:

>All,
>
>I think we *really* need some input here from the WG.  So let me try to
>summarize the situation:
>
>The problem:
>As part of flushing out details that Adrian correctly pointed out were
>underspecified, we noted that when the REVERSE_LSP Object is not present
>there is no way for a node receiving a single sided type association to
>know if it is really the triggering node and to not initiate a new
>reverse LSP. 
>
>The fix:
>There needs to be something in the Path message of a single sided type
>association to disambiguate the forward and reverse LSP.
>
>Some options:
>a) Always require a  REVERSE_LSP Object in the forward LSP
>b) use a different association types in forward and reverse directions,
>and introduce type-specific matching rules
>c) add a bit somewhere, e.g., in LSP ATTRIBUTES
>d) ???
>
>The proposal in Rakesh's mail is to go with option (a), i.e., a
>REVERSE_LSP Object MUST be present in the Path message of the forward LSP.
>
>To me this seems like a reasonable and safe change, and was even
>discussed at some point.
>
>Are there any objections?
>
>Are there any implementations that will be negatively impacted by this
>change?  (And if so, what option do you prefer.)
>
>Note the draft will need to be updated to reflect the outcome of this
>discussion at which time the WG will again be asked to comment on the
>changes.
>
>Thanks,
>Lou (as Shepherd and co-Chair)
>
>On 2/14/2015 11:38 AM, Rakesh Gandhi (rgandhi) wrote:
>> Hi WG,
>>
>> Seeking input on the following clarification.
>>
>>
>> Original text in the draft for the single sided association LSP setup:
>> ----------------------------------------------------------------------
>>    If REVERSE_LSP Object is not present in the received Path message of
>> the LSP, the egress node SHOULD use the LSP properties from the
>>    received LSP Path message to signal the LSP in the reverse direction
>> (which may depend on the local policy).
>>
>>
>> Issue with this text:
>> ---------------------
>> Let's say, an ingress node signals the forward LSP with single sided
>> association type but without REVERSE_LSP object.
>> An egress node creates a reverse LSP using the objects from the Path
>> message of the forward LSP.
>> At the ingress node, this reverse LSP can in turn trigger to create
>> another reverse (well forward) LSP as a response.
>>
>>
>> Clarification:
>> --------------
>> Use the presence of REVERSE_LSP Object in the Path message of the
>>forward
>> LSP as a trigger to create a reverse LSP on the egress node.
>> Egress node does not add it in the reverse LSP, so the ingress does not
>> trigger another reverse (well forward) LSP since REVERSE_LSP Object is
>>not
>> present.
>>
>>
>> Welcome your inputs.
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>>
>>> The IETF datatracker status page for this draft is:
>>> 
>>>https://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-asso
>>>ci
>>> ated-lsp/
>>>
>>> There's also a htmlized version available at:
>>> 
>>>http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associated
>>>-l
>>> sp-03
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>
>