Subject: [Teas] I-D Action: draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-03.txt

From: [email-masked]
Date: Sat, 14 Feb 2015 07:55:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF.

        Title           : RSVP-TE Extensions for Associated Bidirectional LSPs
        Authors         : Fei Zhang
                          Ruiquan Jing
                          Rakesh Gandhi
	Filename        : draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-03.txt
	Pages           : 20
	Date            : 2015-02-14

Abstract:
   This document describes Resource reSerVation Protocol (RSVP)
   extensions to bind two point-to-point unidirectional Label Switched
   Paths (LSPs) into an associated bidirectional LSP.  The association
   is achieved by defining new Association Types for use in ASSOCIATION
   and in Extended ASSOCIATION Objects.  One of these types enables
   independent provisioning of the associated bidirectional LSPs on both
   sides, while the other enables single sided provisioning.  The
   REVERSE_LSP Object is also defined to enable a single endpoint to
   specify all the parameters of an associated LSP in the single sided
   provisioning case.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 14 Feb 2015 16:04:51 +0000

Hi WG,

This revision clarifies the handling when a subobject is not present in
the REVERSE_LSP object in Section 5.3. This addresses a comment received
from Lou in response to the review by Adrian.

There is one outstanding comment for which I will start a new email thread.

Welcome your comments and suggestions on the changes.

thanks,
Rakesh

On 2015-02-14 10:55 AM, "[email-masked]"
<[email-masked]> wrote:

>	Filename        :
>draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-03.txt
>	Pages           : 20
>	Date            : 2015-02-14
>
>Abstract:
>_______________________________________________
>Teas mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/teas

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 14 Feb 2015 16:38:49 +0000

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 17 Feb 2015 21:09:04 -0500

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)

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 19 Feb 2015 13:17:24 +0000

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" <[email-masked]> wrote:

>>>https://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-asso
>>>ci
>>> ated-lsp/
>>>
>>>http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associated
>>>-l
>>> sp-03

---

From: "Zhangfei (Philip)" <[email-masked]>
Date: Fri, 20 Feb 2015 10:28:35 +0000

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

B.R.

Fei

-----邮件原件-----
发件人: Teas [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2015年2月18日 3:09
收件人: [email-masked]
抄送: 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 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,

On 2/14/2015 11:38 AM, Rakesh Gandhi (rgandhi) wrote:
>    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:
> ---------------------
> 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
>
>
>
>
>> https://datatracker.ietf.org/doc/draft-ietf-teas-mpls-tp-rsvpte-ext-a
>> ssoci
>> ated-lsp/
>>
>> http://tools.ietf.org/html/draft-ietf-teas-mpls-tp-rsvpte-ext-associa
>> ted-l
>> sp-03

---

From: Loa Andersson <[email-masked]>
Date: Fri, 20 Feb 2015 21:30:48 +0800

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 20 Feb 2015 15:39:47 +0000

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 20 Feb 2015 11:33:20 -0500

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

---

From: Loa Andersson <[email-masked]>
Date: Sat, 21 Feb 2015 19:03:02 +0800

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? Do we need to take steps to make sure that this is not the case?

/Loa

--

---

From: Lou Berger <[email-masked]>
Date: Sat, 21 Feb 2015 07:18:32 -0500

Loa,

See below.

On February 21, 2015 6:03:38 AM Loa Andersson <[email-masked]> wrote:

> 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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 21 Feb 2015 15:07:20 +0000

Hi Loa,

Thank you for your review and comments.

Please see inline .. <RG> ..

>what I written is clearer and you want to use, use it.

<RG> Reworded this text in the latest revision (05). May be it reads
better now.

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

<RG> Your point is fair. However, the initiating node of such
implementation needs to somehow tell the third party remote node to either
trigger or not trigger the reverse LSP. As this was not specified in the
draft, such implementation may not be interoperable, IMO.

Thanks,
Rakesh

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 23 Feb 2015 10:09:53 +0000

I tend to agree. I think option (a) is reasonable. 

BR
Daniele

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Rakesh Gandhi
> (rgandhi)
> Sent: venerdì 20 febbraio 2015 16:40
> To: Loa Andersson; Lou Berger; [email-masked]
> Subject: Re: [Teas] A clarification request for draft-ietf-teas-mpls-tp-rsvpte-
> ext-associated-lsp
> 
> Hi Loa,
> 
> 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
> 
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 24 Feb 2015 10:13:31 -0500

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)