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

[Lou Berger <[e-mail]>]

Loa,

See below.

On February 21, 2015 6:03:38 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.
>
> 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?

If they have, they need to speak up, then we can decide if and how it 
impacts our direction.

> Do we need to take steps to make sure that this is not the case?
>

Given the score of post wg lc changes, I expect we'll do another lc once 
all open issues are resolved. This will be another opportunity for folks to 
speak up.

Lou

> /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]
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>