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

Hi, all
As a co-author, I prefer option a, which is a simple way

B.R.

Fei

-----邮件原件-----
发件人: Teas [mailto:teas-bounces@ietf.org] 代表 Lou Berger
发送时间: 2015年2月18日 3:09
收件人: teas@ietf.org
抄送: Rakesh Gandhi (rgandhi)
主题: Re: [Teas] A clarification request for draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp

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-a
>> ssoci
>> ated-lsp/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associa
>> ted-l
>> sp-03
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas