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

[Lou Berger <[e-mail]>]

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-associ
>> 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
>