[Teas] Consensus call - (Was Re: A clarification request for draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp)

[Lou Berger <[e-mail]>]

All,
    We'd like to confirm what I (as WG chair) see as consensus on this
point. 

We believe we have consensus behind requiring that the REVERSE_LSP
Object always be required in the Path message of a single sided type
association.

Please review the published version and send any objections or comments
you may have.  Unless there is objections / discussion on the list to
the contrary *before* March 3rd, I (as Shepherd) will inform the AD
(Adrian) that the WG discussion on this topic is closed. 

Editorial comments made during this period should be discussed and
resolved on the list and collected for publication in a new version on
(and not before) March 4th.

One procedure comment / question was asked WRT early allocation.  Per
RFC7120, early allocation procedures  requires:

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

We believe the stated change meets this test as the previous rules
allowed for the presence of the REVERSE_LSP object and the new rules
will support establishment of LSPs without the object present.  

If you have an implementation and you believe the change will result in
interoperability issues, please speak up -- either on the list or
privately to the chairs .

Thanks,
Lou (and Deborah)

On 2/17/2015 9:09 PM, Lou Berger 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-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
>>
>
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>