Subject: [Teas] AD review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Jan 2015 14:37:33 -0000

Authors,
                     
Thanks for this document which I found clear and not too long.

I have done my usual AD review to try to flush out any issues that
might otherwise show up in IETF last call or IESG review.

The only largish issue I have is about error conditions. Pretty much the
only error handling I see is in 5.3 where you have:

   An egress node, upon receiving a Path message containing an
   ASSOCIATION or Extended ASSOCIATION Object with Association Type set
   to "Single Sided Associated Bidirectional LSP" MUST create an LSP in
   the reverse direction or reject the Path message by sending a
   PathErr.

...but you don't say what reason code to give.

You need to handle some other error conditions such as...

**** race conditions
**** what if the association is triggered by both ends at the same time?
**** what if the reverse dirn LSP has already been associated with 
     something else?

**** failure conditions
**** what if not willing or able to associate?
**** what if set-up of reverse LSP fails?
**** what if requested REVERSE LSP parameters are not acceptable?
**** what if the remote end point doesn't support the association

     mechanism defined here? how will the initiator know?

I also have some smaller points as set out below.

I'll put the I-D into "revised I-D needed" state while we discuss these
points and while you produce an update.

Thanks for the work, 
Adrian

====

You have a different number of font-page authors and names in the
Authors' Addresses section.

Looks like Fan Yang and Weilian Jiang should be moved to a 
Contributors section.

---

Section 1 is OK, but it would have been better to just list the relevant
requirements (7, 11, 12, 50) and then the additional requirement (14).

Probably no need to change now, but my preference is to avoid the risk 
of introducing an error during the copying or editorial process. If you
feel like making this change, I would be happier.

---

Because you use RBNF in section 4, you need to add a statement to
Section 2 like:

   This document uses the Routing Backus-Naur Form (RBNF) to define
   message formats as defined in [RFC5511].

And then, of course, add a normative reference.

---

I think 2.1.1 is missing an important statement about co-routing.

"A pair of reverse unidirectional LSPs that are associated to form an
associated bidirectional LSP do not necessarily follow the same path
through the network. If they do follow the same path, they are known as
'co-routed'."

---

3.1

   This section provides an overview and definition of the models for
   provisioning bidirectional LSPs.

This is missing the word "associated" to read "associated bidirectional"

---

Shouldn't 3.1.1 also mention the REVERSE_LSP Object. Something like...

   For the single sided provisioning, the Traffic Engineering (TE)
   tunnel is configured only on one endpoint.  An LSP for this tunnel is
   initiated by the initiating endpoint with the (Extended) ASSOCIATION
   Object inserted in the Path message.  The other endpoint then creates
   the corresponding reverse TE tunnel and signals the reverse LSP in
   response using information from the REVERSE_LSP Object if present.

---

3.1.2

Pedantry, but...

OLD
   For the double sided provisioning, two unidirectional TE tunnels are
   configured independently on both endpoints. 
NEW
   For the double sided provisioning, two unidirectional TE tunnels are
   configured independently, one on each endpoint.
END

---

3.2

   This section provides an overview of the association signaling
   methods for the bidirectional LSPs.

Again, this is missing "associated"

---

3.2.1

OLD
   LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted
   in the Path message, in which the Association Type indicating single
   sided provisioning.
NEW
   LSP1 is then signaled with an (Extended) ASSOCIATION Object inserted
   in the Path message, in which the Association Type indicating single
   sided provisioning is included.
END

---

3.2.2

OLD
   For the double sided provisioning model, both LSP1 and LSP2 are
   signaled independently with (Extended) ASSOCIATION Object inserted in
   the Path message, in which the Association Type indicating double
   sided provisioning.
NEW
   For the double sided provisioning model, both LSP1 and LSP2 are
   signaled independently with (Extended) ASSOCIATION Object inserted in
   the Path message, in which the Association Type indicating double
   sided provisioning is included.

---

3.2.2 needs to include some comment about how the two LSPs are selected
to be associated. I think this is simply "by management action applied
at both end points", although I wonder whether it is enough to apply the
action at just one end point because the association object will achieve
the desired result.

Please think about this and add a note.

---

Section 3.3.1 is fine as it is, but I think that it makes it look like
the REVERSE LSP object is only used for asymmetric b/w. Perhaps...

OLD
   As
   described in this document, addition of the REVERSE_LSP Object also
   allows the initiating node to control the reverse LSP by including
   other existing objects in a REVERSE_LSP Object.
NEW
   As
   described in Section 4.4, addition of the REVERSE_LSP Object also
   allows the initiating node to control other aspects of the reverse
   LSP (such as its path) by including other subobjects in a REVERSE_LSP
   Object.
END

---

For clarity 3.4 needs to observe that multiple association objects may
be present in the signaling of a single LSP.

---

4.2

      The new Association Types are defined as follows (values are
      temporary early allocations as per RFC7120):

Delete the bit in brackets, please, so that we don't accidentally find
it in the published RFC. Your message is already in 6.1 (which is good).
           
---

4.4.1

   Class_Num = 203 (of the form 11bbbbbb), C_Type = 1 (values are
   temporary early allocations as per RFC7120)

Same thing. Please remove the bit about early allocation.

(BTW, you have "of the form 11bbbbbb" twice in this section.

---

4.4.2 or 5.2

Maybe...

   The REVERSE_LSP object MUST NOT be included in a REVERSE_LSP object.

---

5.2

   An
   egress node MUST tear down and reestablish a new reverse LSP when
   REVERSE_LSP Object is either added or removed in the received Path
   message.

That's confusing!
- Why is modification of an existing LSP not allowed?
- Why does removal of the REVERSE_LSP object require tearing down and 
  reestablishment since all that has happened is that the requirements
  for the reverse LSP have been relaxed?
- Why does addition of the REVERSE_LSP necessarily require tear down 
  and reestablishment when the existing LSP might already satisfy the
  requirements?
- Is make-before-break used or is this assumed to be an out-of-service
  operation? If out-of-service you need to describe how that is
  achieved (e.g., using LI).

---

5.3 has

   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).

This worries me. Do you mean that in the absence of a REVERSE_LSP object
containing an ERO, the reverse LSP MUST be co-routed with the forward
LSP?

---

From: Lou Berger <[email-masked]>
Date: Thu, 22 Jan 2015 10:43:12 -0500

Adrian,
    one comment based on a quick read of your (as usual, very good)
comments.
 
On 1/22/2015 9:37 AM, Adrian Farrel wrote:
> ...

> through the network. If they do follow the same path, they are known as
actually, I disagree.  Co-routed is defined ([RFC5654]) to mean that
both directions are fully managed, including protection, as a single
entity so I don't think this qualifies.

Lou

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 22 Jan 2015 16:30:34 +0000

Hi Adrian,

Thank you for the thorough review of the document and detailed comments.

We will digest and advise accordingly.

Many Thanks,
Rakesh

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Jan 2015 13:42:24 -0000

OK, yes, good catch, thanks.

Once a year I come back to read that definition and recall that I never liked it
:-)
But it is what it is.

A

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: 22 January 2015 15:43
> To: [email-masked]; draft-ietf-teas-mpls-tp-rsvpte-ext-associated-
> [email-masked]
> Cc: Alvaro Retana; [email-masked]
> Subject: Re: [Teas] AD review of
draft-ietf-teas-mpls-tp-rsvpte-ext-associated-
> lsp

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 23 Jan 2015 23:17:01 +0000

Thank you Adrian for the thorough review.

Please see replies inline .. <RG> ..

>Thanks for this document which I found clear and not too long.

<RG> Thank you.

><RG> Ack, please see below.
>
>

><RG> For double sided provisioning, this is expected and may not
>necessary be an error. For single sided provisioning, this should not
>happen given egress node only triggers reverse LSP as a response to the
>incoming LSP.
>

><RG> This can happen when an LSP on one side is being rerouted, and may
>not necessarily be an error condition. For example, during MBB, there
>will be two LSPs and association may be updated at some time during the
>MBB process.
>
>**** failure conditions

><RG> It is a bit difficult to know if this is really an error or it is a
>transient condition due to LSP reroute or while node is being
>provisioned, or there is provisioning error, etc. In such cases,
>bidirectional LSP state would stay down so there should not any effect on
>traffic.
>
>

><RG> These are for single sided provisioning, right? For both of the
>above cases, we can add a new PathErr ("LSP Admission Failure/Reverse LSP
>Failure". Operator needs to then check the egress node as reverse LSP
>failure could be for many different reasons. If you agree, we can add a
>new PathErr code in the document (Reverse LSP Failure).
>
>

><RG> An egress node may send PathErr ("LSP Admission Failure/Bad
>Association Type" [RFC4872]. We can add it in the document if you agree.
>
>
>

<SNIP> 

Thanks,

Rakesh

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sat, 24 Jan 2015 15:23:40 +0000

Thank you Adrian for your detailed review comments.

Please see inline .. <RG>..

>     mechanism defined here? how will the initiator know?

<RG> Please refer to another email thread to address this comment.

>Looks like Fan Yang and Weilian Jiang should be moved to a

<RG> Fixed.
<RG> FYI, I also fixed WG from CCAMP to TEAS at the top.

>feel like making this change, I would be happier.

<RG> Find it easier to read the document when this text is in the same
document. Prefer to keep it:)

>And then, of course, add a normative reference.

<RG> Added.

>through the network. If they do follow the same path, they are known as

<RG> Saw the email exchange with Lou. Thanks Lou. I am assuming we are
keeping the text as is.
<RG> Note that this document does not discuss anything about co-routed
LSPs.

>This is missing the word "associated" to read "associated bidirectional"

<RG> Added.

>   response using information from the REVERSE_LSP Object if present.

<RG> Yes, added.

>   configured independently, one on each endpoint.

<RG> Added. 

>Again, this is missing "associated"

<RG> Added.

>   sided provisioning is included.

<RG> Fixed.

>   sided provisioning is included.

<RG> Fixed.

>Please think about this and add a note.

<RG> This is somewhat in Section 3.1.2.
<RG> We could add something like:
The LSPs to be selected for association are provisioned by the management
action applied at both endpoints.

>   LSP (such as its path) by including other subobjects in a REVERSE_LSP

<RG> Fixed.

>be present in the signaling of a single LSP.

<RG> Adding following:
 An LSP MAY signal multiple (Extended) ASSOCIATION Objects with different
Association Types.

>it in the published RFC. Your message is already in 6.1 (which is good).

<RG> Fixed.

>(BTW, you have "of the form 11bbbbbb" twice in this section.

<RG> Fixe both.

>   The REVERSE_LSP object MUST NOT be included in a REVERSE_LSP object.

<RG> Added in Section 5.2.

>  achieved (e.g., using LI).

<RG> Understand and agree with above comments. There are various scenarios
where change may lead to in-place modification, MBB or setup and teardown
(which may depend on implementation).

<RG> How about something like following:
An egress node MAY tear down and reestablish a new reverse LSP, or trigger
re-optimization or in-place modification when
   REVERSE_LSP Object is either added or removed in the received Path
   message (which may depend on the local policy).

>containing an ERO, the reverse LSP MUST be co-routed with the forward

<RG> No. There will also be no (forward LSP) full ERO in the LSP either to
do that.
<RG> Does following work?
  
If REVERSE_LSP Object is not present in the received Path message of
   the LSP, the egress node MAY use the LSP properties from the
   received LSP Path message to signal the LSP in the reverse direction
that MAY or MAY NOT follow the forward LSP path
   (which may depend on the local policy).

Many thanks Adrian for the great review.

Regards,
Rakesh

---

From: Lou Berger <[email-masked]>
Date: Sun, 25 Jan 2015 10:18:29 -0500

HI Rakesh,
A few comments below...

> <RG> Saw the email exchange with Lou. Thanks Lou. I am assuming we are

Right.
...
>  An LSP MAY signal multiple (Extended) ASSOCIATION Objects with different
As this document does not define the Association object it is the wrong 
place to have its conformance  language. That said, and informative 
statement is just fine. How about:

As defined, see [RFC6780], multiple ASSOCIATION objects may be present in 
the signaling of a single LSP.

>    (which may depend on the local policy).

Humm, I think we should dig into this a bit more before making this change.

Adrian,

Do you have a specific concern with the existing text that you would like 
to see addressed ?

I think the proposed revision is even less helpful.

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 25 Jan 2015 22:33:16 -0000

Hi Lou, Rakesh, all...

[snip]

> I think the proposed revision is even less helpful.

1. "MAY NOT" is not 2119 language. It would be enough to say "MAY" because it
implies you have a choice.

2. The ERO was just an example of what was worrying me. That is, that in the
absence of sub-objects in the REVERSE_LSP object, the receiving end point
SHOULD (i.e., is strongly directed to unless there is an unusual variation) use
the parameters from the forward direction to govern the reverse LSP. It seems to
me that there are probably different classes of information that fit into:
- MUST be in the REVERSE_LSP object or everything will fail (I believe this is
the empty set)
- MUST be used from the forward LSP if not in the REVERSE_LSP object
- SHOULD be used from the forward LSP if not in the REVERSE_LSP object
- MAY be used from the forward LSP if not in the REVERSE_LSP object
- MUST NOT be used from the forward LSP if not in the REVERSE_LSP object

TSpec is a simple example of SHOULD (although maybe the reverse path TSpec
should be modelled on the FlowSpec that will was sent on the Resv?).
ERO (derived from the RRO) is either a MAY or a SHOULD depending on your thought
pattern (some people think the default should be that the two LSPs fate share).
The Session Name in the Session Attribute object seems like a MAY (noting that
the name might already be in use).
The Alarm_Spec object looks like a MUST NOT.
Etc.

I'm open to being persuaded that this collapses to one or two bullets. But if it
is more than one bullet, I think there is work to be done to list it out. And
that also worries me for extensibility - when I define a new object carried in a
Path message, who is going to think about and document which class it belongs
to?
Perhaps "MAY" is the vaguest and safest?

Adrian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 26 Jan 2015 13:54:36 +0000

Hi Adrian,

Thanks for your inputs.

If the initiator really needs a specific behaviour, and depending on it,
it should signal the egress node via REVERSE_LSP.
IMO, MAY gives a reasonable choice for the egress node to do the right
thing and if that is not what the initiator prefers, it can alter it by
signaling REVERSE_LSP.

"
"

Thanks,
Rakesh

---

From: Lou Berger <[email-masked]>
Date: Mon, 26 Jan 2015 10:05:25 -0500

On 01/26/2015 08:54 AM, Rakesh Gandhi (rgandhi) wrote:> Hi Adrian,
> it should signal the egress node via REVERSE_LSP.

This is a key point.  From an interoperability standpoint there needs to
be expected behavior.

> thing and if that is not what the initiator prefers, it can alter it by

To me "MAY" translates to the initiator not being able to rely on any
particular egress' behavior, so from a practical interoperability
standpoint this translates to me to be "don't expect anything to work
reliably without inclusion of the REVERSE_LSP object". So I really think
the proposed language is a bad idea.

It seems to me that the options are:
(a) require the REVERSE_LSP Object and have it include all objects to be
used
 -- I think this is over kill and optimizes for the special case

(b) define predictable behavior when REVERSE_LSP Object isn't present
and when the REVERSE_LSP object doesn't contain all objects to be used.
 -- I agree with Adrian's comment that an object enumeration based
approach is risky as it's unclear what happens with new objects. I think
this leads to a generic rule / directive which is how I read as the
intent of the text that lead to this question.  Perhaps we can try to
tighten up the language so an egress knows what it SHOULD/MUST do while
an ingress can predict behavior?

Lou

> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 27 Jan 2015 11:26:47 -0000

Right, well it is really just a case of "what do you want to achieve?"

The point I raised originally was wrt the ERO.
Firstly the ERO when the Path reaches the egress is not a lot of help, so there
is magic mapping from the RRO required.
But more importantly, if it is OK that the default position is that the two LSPs
follow the same path, this is fine.  OTOH, without putting an ERO with a single
loose hop into the Reverse_LSP you have no way of telling the egress that it can
perform its own routing choice on the reverse LSP. That seems clunky, but if it
what the WG wants then that is OK - you'd just need to state it and explain
which RRO sub-objects need to be stripped when creating the reverse path ERO
(for example, labels and interfaces might not be suitable in all cases).

I'm guessing, however, that the ERO is just the tip of the iceberg because we
haven't gone through the task of looking at the full list of objects and
deciding which ones should/could/would be copied.

Maybe a way forward is:
- If the object is in the Reverse_LSP it MUST be used
- Otherwise the following information MUST be determined
   from the objects in the received Path message from the
   forward path LSP
    - TSpec
    - Session Attributes except for name
    - Admin_Status
    - ERO
- Additionally any further information MAY be derived from
   the objects in the received Path message from the
   forward path LSP

A

> Sent: 26 January 2015 15:05
> To: Rakesh Gandhi (rgandhi); [email-masked]; draft-ietf-teas-mpls-tp-
> [email-masked]
> Cc: Alvaro Retana (aretana); [email-masked]

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 27 Jan 2015 13:58:51 +0000

Hi Adrian,

In the WG, it was agreed that for co-routed LSPs, GMPLS signaling should
be used. This is why there is no mention of co-routed LSPs in this draft.
Given this, and the complexity of using RRO to achieve co-routed LSPs, I
prefer to keep the co-routed LSPs outside the scope of this draft.

Thanks,
Rakesh

<Snip>

>> >>>>>   If REVERSE_LSP Object is not present in the received Path
>>message
>> >>> of
>> >>>>    If REVERSE_LSP Object is not present in the received Path
>>message
>> >>> of
>> >> 2. The ERO was just an example of what was worrying me. That is,
>>that in
>> >> the
>> >> the parameters from the forward direction to govern the reverse LSP.
>>It
>> >> seems to
>> >> - MUST be in the REVERSE_LSP object or everything will fail (I
>>believe
>> >> this is
>> >> the empty set)
>> >> ERO (derived from the RRO) is either a MAY or a SHOULD depending on
>>your
>> >> thought
>> >> pattern (some people think the default should be that the two LSPs
>>fate
>> >> share).
>> >> The Session Name in the Session Attribute object seems like a MAY
>>(noting
>> >> that
>> >> I'm open to being persuaded that this collapses to one or two
>>bullets.
>> >> But if it
>> >> is more than one bullet, I think there is work to be done to list it
>>out.
>> >> And

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jan 2015 09:04:11 -0500

Rakesh,
	Let's take a stab (off line) at language that addresses Adrian's
comment and captures (our understanding) of the intent of the existing
language, and then pass it around for review by all.  If you can take a
stab at it and send it to me that would be best.

Adrian,
	Give us a little time, say a day or two to get back to you.

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Jan 2015 22:22:31 -0000

> stab at it and send it to me that would be best.

That sounds like a fine idea because Rakesh's latest email sounds like "the
reverse path LSP MUST NOT follow the same path as the forward path LSP" and I am
sure that you don't want to say that!

A