Subject: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 3 Jan 2015 14:34:14 -0000

Thank you for recognising the use of the Administratively Down bit for
LI. It's good to see existing mechanisms being adapted to new uses.

I've done my usual AD review to try to catch any issues before IETF
last call. I've found a few issues, the first two of which will need
discussion in the working group, I think. The remaining issues are
relatively minor.

While we wait for you to discuss these issues and possibly issue a new
revision, I will put the document into "Revised I-D Needed" state.

Thanks for the work,
Adrian

---

You want to use a bit in the Attribute Flags TLV to indicate Loopback
and propose including that TLV in the HOP Attributes ERO subobject as
defined in draft-ietf-ccamp-lsp-attribute-ro.

Please note that that draft is now draft-ietf-teas-lsp-attribute-ro.

However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes
Flags TLV is not allowed in the HOP Attributes ERO subobject. I think 
this is for a good reason that many (all?) of bits defined so far have
no meaning if targeted at a specific transit LSR.

---

I think you need to describe what happens if a LB instruction is
received when the LSP is not admin down. Similarly, what happens when
an LSP is moved from admin down to admin up when a LB instruction is in
force. Is there an implication that transit nodes need to inspect the
Admin Status flags?

======

idnits shows

  == Unused Reference: 'RFC4783' is defined on line 312, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4872' is defined on line 315, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4974' is defined on line 320, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC5852' is defined on line 324, but no explicit
     reference was found in the text

---

In 3.2 you talk about reporting the LB in the RRO on the corresponding
Resv. What about the RRO on the Path that is forwarded downstream?

---

I think that Section 5 should refer to the security considerations 
section of draft-ietf-teas-lsp-attribute-ro to pick up any concerns with
the use of that mechanism.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 6 Jan 2015 02:36:23 +0000

Dear Adrian, 

Thanks a lot for your review, please see my replies inline.

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Saturday, January 03, 2015 10:34 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb
> 
> Thank you for recognising the use of the Administratively Down bit for LI. It's
> good to see existing mechanisms being adapted to new uses.
> 
> I've done my usual AD review to try to catch any issues before IETF last call. I've
> found a few issues, the first two of which will need discussion in the working
> group, I think. The remaining issues are relatively minor.
> 
> While we wait for you to discuss these issues and possibly issue a new revision, I
> will put the document into "Revised I-D Needed" state.
> 
> Thanks for the work,
> Adrian
> 
> ---
> 
> You want to use a bit in the Attribute Flags TLV to indicate Loopback and
> propose including that TLV in the HOP Attributes ERO subobject as defined in
> draft-ietf-ccamp-lsp-attribute-ro.
> 

Thanks for pointing out this, will update the reference in a new revision. 

> However, draft-ietf-teas-lsp-attribute-ro defines that the Attributes Flags TLV is
> not allowed in the HOP Attributes ERO subobject. I think this is for a good
> reason that many (all?) of bits defined so far have no meaning if targeted at a
> specific transit LSR.

I guess there may be some confusion about this. Section 5.3.1 of draft-ietf-teas-lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, which says it is "Allowed on LSP attribute ERO subobject". And in section 5.1, the "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute Subobject", thus my understanding is that the "Attributes Flags TLV" is allowed in the "ERO HOP Attribute subobject". 

> I think you need to describe what happens if a LB instruction is received when
> the LSP is not admin down. Similarly, what happens when an LSP is moved from
> admin down to admin up when a LB instruction is in force. Is there an
> implication that transit nodes need to inspect the Admin Status flags?

Agree that we can add some description about these cases. 

Since the lock and loopback requests are originated by the ingress node, maybe we can specify that the ingress node must not send LB instruction before putting the LSP into admin down state, also must not move the lsp to admin up when the lsp is in still loopback mode?

For the transit nodes, my understanding is they could inspect the Admin Status flags to know the status of the LSP. As section 7.2 of RFC 3473 says: 

  "The Admin_Status object is used to notify each node along the path of the status of the LSP. "

>      reference was found in the text

Thanks for catching this. They were referenced in a previous version. Will clean up this in a new revision. 

> 
> In 3.2 you talk about reporting the LB in the RRO on the corresponding Resv.
> What about the RRO on the Path that is forwarded downstream?

My feeling is the RRO on the Path message MAY carry this information to downstream, while this does not impact the signaling procedure of loopback.

> ---
> 
> I think that Section 5 should refer to the security considerations section of
> draft-ietf-teas-lsp-attribute-ro to pick up any concerns with the use of that
> mechanism.

Agreed. Will add the reference in a new revision. 

Many thanks,
Jie

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Jan 2015 12:43:20 -0000

Hi Jie,

Thanks for the prompt response.

> I guess there may be some confusion about this. Section 5.3.1 of
draft-ietf-teas-
> lsp-attribute-ro-00 gives the rules of using Attributes Flags TLV, which says
it is
> "Allowed on LSP attribute ERO subobject". And in section 5.1, the "ERO HOP
> Attribute Subobject" is also called "ERO LSP Attribute Subobject", thus my
> understanding is that the "Attributes Flags TLV" is allowed in the "ERO HOP
> Attribute subobject".

OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to have
changed a bit.

The WG needs to work this through (no need to involve me :-).
If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs to
change.
If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change.

> Since the lock and loopback requests are originated by the ingress node, maybe
> we can specify that the ingress node must not send LB instruction before
putting
> the LSP into admin down state, also must not move the lsp to admin up when the
> lsp is in still loopback mode?

Saying what must happen is good, and I think you already do that in the
document.

> For the transit nodes, my understanding is they could inspect the Admin Status
> flags to know the status of the LSP. As section 7.2 of RFC 3473 says:
> 

Good reference. Thanks.

So all you need to describe is the error cases. What does a transit node or
egress do when the ingress screws up?

> My feeling is the RRO on the Path message MAY carry this information to
> downstream, while this does not impact the signaling procedure of loopback.

Any of the three options (MUST NOT, MAY/SHOULD, or MUST) work for me. You need
to decide and document.

Probably, it is a SHOULD because it is information about the path.

Cheers,
Adrian

---

From: Lou Berger <[email-masked]>
Date: Wed, 07 Jan 2015 11:59:08 -0500

[resend]

Adrian (all),

> If this I-D is correct, then draft-ietf-teas-lsp-attribute-ro needs to change.

I this document is correct, and think you've identified a few issues
with draft-ietf-teas-lsp-attribute-ro (which has also been submitted for
publication) and I'll start a new thread on these.

> egress do when the ingress screws up?
So you are asking for a new sentence in paragraph 3 of section 3.2.
Perhaps something like:
 OLD
   On receipt of this Path message, the target LSR of the loopback
   request SHOULD try to put the LSP into loopback mode.  If the node
   puts the LSP into loopback mode successfully, it MUST set the
NEW
   On receipt of this Path message, the target node of the loopback
   request MUST check if the LSP is in lock mode by verifying that the
   Administratively down (A) bit is set in the ADMIN_STATUS object.
   If the bit is not set, the loopback request MUST be ignored.  If the
   bit is set the node
   SHOULD try to put the LSP into loopback mode.  If the node
   puts the LSP into loopback mode successfully, it MUST set the

> Any of the three options (MUST NOT, MAY/SHOULD, or MUST) work for me. You need

How about:
OLD
   If the node
   puts the LSP into loopback mode successfully, it MUST set the
   Loopback (B) bit in the Record Route Object (RRO) Attribute subobject
   [RFC5420] and push this subobject onto the RRO object in the
   corresponding Resv message.
NEW
   If the node
   puts the LSP into loopback mode successfully, it MUST set the
   Loopback (B) bit if it adds, per [RFC5420], an Attribute subobject
   to the RECORD_ROUTE object of a Path or Resv message.

> Probably, it is a SHOULD because it is information about the path.

One additional comment of my own.  For consistency, only LSR or node
should be used -- they are currently used about equally.  I suggest
replacing "LSR" with "node" .  (Sorry, I thought we did this for this
document already, but clearly I missed this due too much eggnog.)

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 07 Jan 2015 12:00:00 -0500

[resend]

All,
    I believe Adrian has identified a few issues with
draft-ietf-teas-lsp-attribute-ro in his review of
draft-ietf-teas-rsvp-te-li-lb, see below for context.  In particular:

1) In the IANA section, the document states that Attribute Flags cannot
be carried in a LSP Hop Attributes subobject. It looks like this was a
cut&paste bug introduced in rev 01 when translating the expanded
directions into table form.  The old -00 text in section 5.3.1 said:
   o  Allowed on LSP attribute ERO subobject
so the following change should be made.
OLD:
           1 Attribute Flags       Yes   Yes    No    [RFC5420]
NEW
           1 Attribute Flags       Yes   Yes    Yes    [RFC5420]

2) Adrian points out that many existing flags really don't make sense in
in the LSP attribute ERO subobject and I think this should be
documented. To do this fully, I think we can either preclude usage of
existing flags or allow for specific flags (I could see allowing it for
MIP, SRLG collection, but am okay either way).  Either way there should
be an explicit statement on this, as well as a new column in the IANA
table (with a new IANA section describing this change).

For the explicit statement, how about adding the following to the end
of  section 2.2:

    The Attribute Flags TLV defined in [RFC5420] MAY be carried in an
    ERO Hop Attributes Subobject.  Flags set in the an Attribute Flags
    TLV [RFC5420] carried in a ERO Hop Attributes Subobject SHALL be
    interpreted in the context of the received ERO. Only a subset of
    defined flags are defined as valid for use in Attribute Flags TLV
    carried in a ERO Hop Attributes Subobject. Invalid  flags SHALL be
    silently ignored. Unknown flags SHOULD trigger the generation of
    a PathErr with Error Code "Unknown Attributes Bit" as defined in
    [RFC5420] Section 5.2.

And
4.3. Existing Attribute Flags

   IANA manages the "Attribute Flags" registry  as part of the
"RSVP-TE PARAMETERS" registry located at
   http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-
   parameters.xml.  A new column in the registry is introduced
   by this document.  This column indicates if the flag is permitted to be
   used in a Attribute Flags TLV carried in the ERO Hop Attributes
   Subobject.  The column uses the heading "ERO" and the registery is
   to be updated as follows:

Bit Name                   Attribute Attribute RRO ERO Reference
                           FlagsPath FlagsResv
  0  End-to-end re-routing    Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 1  Boundary re-routing      Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 2  Segment-based re-routing Yes        No     No  No [RFC4920]
                                                      [RFC5420]
 3  LSP Integrity Required   Yes        No     No  No [RFC4875]
 4  Contiguous LSP           Yes        No     Yes No [RFC5151]
 5  LSP stitching desired    Yes        No     Yes No [RFC5150]
 6  Pre-Planned LSP Flag     Yes        No     No  No [RFC6001]
 7  Non-PHP behavior flag    Yes        No     Yes No [RFC6511]
 8  OOB mapping flag         Yes        No     Yes No [RFC6511]
 9  Entropy Label Capability Yes        Yes    No  No [RFC6790]
10  OAM MEP entities desired Yes        Yes    Yes No [RFC7260]
11  OAM MIP entities desired Yes        Yes    Yes No [RFC7260]
12  SRLG collection Flag     Yes        Yes    Yes No [draft-ietf-
   (TEMPORARY - registered                             ccamp-rsvp-
    2014-09-11, expires                                te-srlg-
    2015-09-11)                                        collect]

   New allocation requests to this registry shall indicate the value to
be used in the ERO column.

3) the discussion also caught one naming inconsistency:
s/4.1. ERO LSP Attribute Subobject/4.1 ERO Hop Attributes Subobject

I think that's it.  Comments?

Lou

On 1/6/2015 1:02 PM, Lou Berger wrote:
> Adrian (all)
> ...

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 8 Jan 2015 02:26:12 +0000

Hi Lou, Adrian, 

Thanks a lot for your suggestions. We will revise the document following your guidance and submit a new revision soon. 

Best regards,
Jie

> From: Lou Berger [mailto:[email-masked]]
> Sent: Thursday, January 08, 2015 12:59 AM
> To: [email-masked]; Dongjie (Jimmy); [email-masked]
> Cc: [email-masked]
> Subject: Re: [Teas] AD review draft-ietf-teas-rsvp-te-li-lb
> 
> [resend]
> 
> Adrian (all),
> 
> >>> You want to use a bit in the Attribute Flags TLV to indicate
> >>> Loopback and propose including that TLV in the HOP Attributes ERO
> >>> subobject as defined in draft-ietf-ccamp-lsp-attribute-ro.
> 
> >>> However, draft-ietf-teas-lsp-attribute-ro defines that the
> >>> Attributes Flags
> > TLV is
> >>> not allowed in the HOP Attributes ERO subobject. I think this is for
> >>> a good reason that many (all?) of bits defined so far have no
> >>> meaning if targeted
> > at a
> >>> specific transit LSR.
> >> "Allowed on LSP attribute ERO subobject". And in section 5.1, the
> >> "ERO HOP Attribute Subobject" is also called "ERO LSP Attribute
> >> Subobject", thus my understanding is that the "Attributes Flags TLV"
> >> is allowed in the "ERO HOP Attribute subobject".
> > OK, well, draft-ietf-teas-lsp-attribute-ro is now at -01 and seems to
> > have changed a bit.
> >
> > If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D needs
> > to change.
> I this document is correct, and think you've identified a few issues with
> draft-ietf-teas-lsp-attribute-ro (which has also been submitted for
> >>> received
> > when
> >>> the LSP is not admin down. Similarly, what happens when an LSP is
> >>> moved from admin down to admin up when a LB instruction is in force.
> >>> Is there an implication that transit nodes need to inspect the Admin Status
> flags?
> >> Since the lock and loopback requests are originated by the ingress
> >> node, maybe we can specify that the ingress node must not send LB
> >> instruction before
> > putting
> >> the LSP into admin down state, also must not move the lsp to admin up
> >> when the lsp is in still loopback mode?
> > Saying what must happen is good, and I think you already do that in
> > the document.
> >
> >> For the transit nodes, my understanding is they could inspect the
> >> Admin Status flags to know the status of the LSP. As section 7.2 of RFC 3473
> says:
> >>
> > So all you need to describe is the error cases. What does a transit
> > node or egress do when the ingress screws up?
>    puts the LSP into loopback mode successfully, it MUST set the NEW
> Resv.
> >> My feeling is the RRO on the Path message MAY carry this information
> >> to downstream, while this does not impact the signaling procedure of
> loopback.
> > Any of the three options (MUST NOT, MAY/SHOULD, or MUST) work for me.
> > You need to decide and document.
> 
> How about:
> OLD
>    If the node
> One additional comment of my own.  For consistency, only LSR or node should
> be used -- they are currently used about equally.  I suggest replacing "LSR" with
> "node" .  (Sorry, I thought we did this for this document already, but clearly I
> missed this due too much eggnog.)
> 
> Thanks,
> Lou

---

From: Ben Wright <[email-masked]>
Date: Thu, 8 Jan 2015 10:51:36 +0000

Thanks Lou. I agree with your points.  

On point 2)
- Section 2.2 changes, the text here looks good to me.  I'd add "The set of valid flags are defined in section 4.3" as a forward reference to make life easier for the reader. 

- On the MIP and SRLG collection flags: I don't really see a requirement for allowing them to be included in the LSP Hop Attributes subobject in the ERO.  In both cases I'd expect a network admin would always want to enable the function on all nodes on the path of an LSP.  If someone has a good use case for allowing these to be set differently on different hops, then it would be straightforward to raise a separate draft to describe the use case and change this position.  

On point 3) agree. 

Other folks?  Cyril - if you agree, are you OK to make these changes?

Ben

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 07 January 2015 17:00
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb)

[resend]

All,
    I believe Adrian has identified a few issues with draft-ietf-teas-lsp-attribute-ro in his review of draft-ietf-teas-rsvp-te-li-lb, see below for context.  In particular:

1) In the IANA section, the document states that Attribute Flags cannot be carried in a LSP Hop Attributes subobject. It looks like this was a cut&paste bug introduced in rev 01 when translating the expanded directions into table form.  The old -00 text in section 5.3.1 said:
   o  Allowed on LSP attribute ERO subobject so the following change should be made.
OLD:
           1 Attribute Flags       Yes   Yes    No    [RFC5420]
NEW
           1 Attribute Flags       Yes   Yes    Yes    [RFC5420]

2) Adrian points out that many existing flags really don't make sense in in the LSP attribute ERO subobject and I think this should be documented. To do this fully, I think we can either preclude usage of existing flags or allow for specific flags (I could see allowing it for MIP, SRLG collection, but am okay either way).  Either way there should be an explicit statement on this, as well as a new column in the IANA table (with a new IANA section describing this change).

For the explicit statement, how about adding the following to the end of  section 2.2:

And

   IANA manages the "Attribute Flags" registry  as part of the "RSVP-TE PARAMETERS" registry located at

   New allocation requests to this registry shall indicate the value to be used in the ERO column.

Lou

On 1/6/2015 1:02 PM, Lou Berger wrote:
>>>> not allowed in the HOP Attributes ERO subobject. I think this is 
>>>> for a good reason that many (all?) of bits defined so far have no 
>>>> meaning if targeted
>> at a
>>>> specific transit LSR.
>> If draft-ietf-teas-lsp-attribute-ro-01 is correct, then this I-D 
>> needs to change.

---

From: Steve Balls <[email-masked]>
Date: Thu, 8 Jan 2015 16:07:38 +0000

Similarly thanks Lou - I agree with Ben and have nothing to add.
Steve

-----Original Message-----
From: Ben Wright [mailto:[email-masked]] 
Sent: 08 January 2015 10:52
To: labn - Lou Berger; [email-masked]; [email-masked]; [email-masked]; Cyril Margaria
Subject: RE: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb)

On point 2)

On point 3) agree. 

Ben

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: 07 January 2015 17:00
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Issues with draft-ietf-teas-lsp-attribute-ro (was: AD review draft-ietf-teas-rsvp-te-li-lb)

[resend]

All,

And

Lou

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 9 Jan 2015 14:15:10 +0000

from my side, same feeling as Ben here

Cheers
G