Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)
draft-ietf-teas-lsp-attribute-ro-05

[Ballot comment]
Similar to Brian's comment:

2.2:

s/One or more TLVs MAY be present in each object/Each object MAY contain one or more TLVs

s/The Attribute Flags TLV defined in [RFC5420] MAY be carried in an ERO Hop Attributes Subobject/The Attribute Flags TLV defined in [RFC5420] are carried in an ERO Hop Attributes Subobject.

3.2.2/3.2.3: s/MAY/can

[Ballot comment]
I'll leave this as a comment. If it's important, a RTG AD can say so ...

In this text:

  If a node is processing an ERO Hop Attributes subobject and does not
  support handling of the subobject it will behave as described in
  [RFC3209] when an unrecognized ERO subobject is encountered.  This
  node will return a PathErr with error code "Routing Error" and error
  value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
  included, truncated (on the left) to the offending unrecognized
  subobject.

The behavior is a bit different from what I thought was the corresponding text in [RFC3209]:

      It is anticipated that new subobjects may be defined over time.  A
  node which encounters an unrecognized subobject during its normal ERO
  processing sends a PathErr with the error code "Routing Error" and
  error value of "Bad Explicit Route Object" toward the sender.  The
  EXPLICIT_ROUTE object is included, truncated (on the left) to the
  offending subobject.  The presence of an unrecognized subobject which
                        ^
          I'm not seeing ^ this part reproduced in the draft
                       
  is not encountered in a node's ERO processing SHOULD be ignored.  It
  is passed forward along with the rest of the remaining ERO stack.
 
I'm no RSVP-TE jockey, but I would have thought if you behaved as in [RFC3209], you would have done everything in that paragraph ... and obviously, I only compared these because the description was imported by reference AND sort-of-by value at the same time.

Maybe providing only the reference, as you do in the next couple of instances would be better?

[Ballot comment]
I'll leave this as a comment. If it's important, a RTG AD can say so ...

In this text:

  If a node is processing an ERO Hop Attributes subobject and does not
  support handling of the subobject it will behave as described in
  [RFC3209] when an unrecognized ERO subobject is encountered.  This
  node will return a PathErr with error code "Routing Error" and error
  value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
  included, truncated (on the left) to the offending unrecognized
  subobject.

The behavior is a bit different from what I thought was the corresponding text in [RFC3209]:

      It is anticipated that new subobjects may be defined over time.  A
  node which encounters an unrecognized subobject during its normal ERO
  processing sends a PathErr with the error code "Routing Error" and
  error value of "Bad Explicit Route Object" toward the sender.  The
  EXPLICIT_ROUTE object is included, truncated (on the left) to the
  offending subobject.  The presence of an unrecognized subobject which
                        ^
          I'm not seeing ^ this part reproduced in the draft
                       
  is not encountered in a node's ERO processing SHOULD be ignored.  It
  is passed forward along with the rest of the remaining ERO stack.
 
I'm no RSVP-TE jockey, but I would have thought if you behaved as in [RFC3209], you would have done everything in that paragraph ... and obviously, I only compared these because the description was imported by reference AND sort-of-by value at the same time.

Maybe providing only the reference, as you do in the following couple of instances would be better?

[Ballot comment]
Some suggested changes:

- Section 2 : s/The ERO Hop Attributes subobject MAY be carried/The ERO Hop Attributes subobject is carried/

- Section 3.1 : s/The RRO Hop Attributes subobject MAY be carried/The RRO Hop Attributes subobject is carried/

- Each requested IANA action should use a unique identifier (e.g., TBA-1, TBA-2) rather than a generic TBA.  That simplifies IANA's job.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-teas-lsp-attribute-ro-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has some questions for the requested IANA actions requested by this draft.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, in the Sub-object type - 20 EXPLICIT_ROUTE - Type 1 Explicit Route subregistry of the Resource Reservation Protocol (RSVP) Parameters registry located at:

http://www.iana.org/assignments/rsvp-parameters/

a new value will be registered as follows:

Value: [ TBD-at-Registration ]
Description: Hop Attributes
Reference: [ RFC-to-be ]

Second, in the Sub-object type - 21 ROUTE_RECORD - Type 1 Route Record subregistry of the Resource Reservation Protocol (RSVP) Parameters registry located at:

http://www.iana.org/assignments/rsvp-parameters/

a new value will be registered as follows:

Value: [ TBD-at-Registration ]
Description: Hop Attributes
Reference: [ RFC-to-be ]

IANA notes that the authors have requested that the same value be used for each of these first two, new registrations.

Third, an existing registry is to be modified. In the "Attribute Flags" subregistry of the "RSVP-TE PARAMETERS" registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/

A new column is to be added to the registry defined by the current 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 registry will be updated to look 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- Yes No No No [RFC4920]
routing
[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 Yes Yes No No [RFC6790]
Capability
10 OAM MEP entities Yes Yes Yes No [RFC7260]
desired
11 OAM MIP entities Yes Yes Yes No [RFC7260]
desired
12 SRLG collection Flag Yes Yes Yes No [I.D.draft-
(TEMPORARY - registered ietf-teas-
2014-09-11, expires rsvp-te-
2015-09-11) srlg-collect]

Question: Should this draft be listed as the second Reference in addition to RFC5420
in the registry?

Fourth, another registry is to be modified. In the Attributes TLV Space subregistry of the "RSVP-TE PARAMETERS" registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/

a new column is to be added to the registry that indicates whether allowed on LSP Hop Attributes ERO subobject.

The registry will be updated to look as follows:

The following abbreviation are used in the table:

LSP_A Whether allowed on LSP_ATTRIBUTES object.
LSP_RA Whether allowed on LSP_REQUIRED_ATTRIBUTES object.
HOP_A Whether allowed on LSP Hop Attributes subobject.

T Name LSP_A LSP_RA HOP_A Ref.
- --------------------- ----- ------ ----- --------
1 Attribute Flags Yes Yes Yes [RFC5420]
2 Service ID TLV Yes No No [RFC6060]
3 OAM Configuration TLV Yes Yes No [RFC7260]

Question: Should this draft be listed as the second Reference in addition to RFC5420
in the registry? 

Is there a range for this registry?  Is value 0 the first value of the range and should be
reserved?  What is the maximum values?  Or, this draft does not answer all those
questions?

IANA understands that these four actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (LSP Attribute in ERO) to Proposed Standard


The IESG has received a request from the Traffic Engineering Architecture
and Signaling WG (teas) to consider the following document:
- 'LSP Attribute in ERO'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  RFC5420 extends RSVP-TE to specify or record generic attributes which
  apply to the whole of the path of an LSP.  This document defines an
  extension to the RSVP ERO and RRO objects to allow it to specify or
  record generic attributes which apply to a given hop.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-teas-lsp-attribute-ro/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review
======

Hi authors,

Thanks for this document, the first from TEAS to reach me for
publication. I found it to be a simple and clear read. The IANA section
is clear and well-written.

I have done my usual AD review with the intent to catch any remaining
issues before issuing IETF last call.

I think my first three points need discussion with the working group.
The remaining points are relatively small.

While I wait for your discussion or a new revision, I'll put the draft
into "Revised I-D Needed" state.

Thanks for your work,
Adrian

---

Section 2.3 needs to describe the processing when an ERO Hop Attributes
subobject is encountered after a loose hop subobject or a strict hop
that is an abstract node?

- Is it valid?
- Is it assumed to apply to all hops in that loose hop or abstract node?
- Or in the case of a loose hop, does it just apply to the named hop
  itself?
- What about if the preceding subobject is an interface identifier or a
  label?

I wonder whether reference to 4990 would help at all.

Note that 3.2 seems to handle all the options for use in the RRO.

---

3.2.1 has

  All such 
  subobjects MUST be forwarded unmodified by transit LSRs.

That is, of course, the general rule, but I assume that there are
exceptions.

For example, an ASBR may choose to prune the information that is
forwarded in an RRO. Similarly, the UNI-N may strip information.

I think the point would be that "If a node forwards an RRO subobject
for a specific hop, it MUST forward any associated HOP Attributes
subobjects."

But even this may be too restrictive for a border node that wants to
report the chosen path but not expose how the internals of its network
are operated. In this case it may want to strip HOP Attributes
subobjects from the RRO or even modify them to mask information.

Can you add some clarification about all of this?

---

I think section 5 is a little optimistic. You are introducing a new
mechanism for the control of the behavior on certain nodes on the path
of the LSP. Since the control of those nodes may impact the behavior of
other LSPs passing the node, some care is needed. For example, setting
optical power levels for one lambda can interfere with the signals on
other lambdas. Thus, and in general, you have a mechanism that takes
control away from the node itself and puts it in the hand of the node
that signaled the LSP. This opens up three security possibilities:
1. Simple errors in the attributes of an LSP may inadvertently impact
  existing LSPs while still allowing this LSP to be set up.
2. A malign ingress may signal an LSP down a path and with attributes
  chosen to damage other LSPs from other ingresses.
3. An attacked Path message may result in damage to other LSPs.

The third of these is mitigated somewhat by existing RSVP-TE security
mechanisms. The first two (and the third in the case of a subverted
node) can only be mitigated by allowing policy to be applied at a node
that implements the HOP Attributes it receives in an ERO. A node must be
allowed to determine that satisfy the attributes would be inadvisable or
against local policy even if practically possible. In these cases the
node has a choice to either reject the Path message (but a new error
code might be helpful) or to modify the requested attribute (but in this
case it might be required to report exactly what it has done, presumably
in the RRO).

===

Please don't "propose". You intend this document to be published as an
RFC, so you should "define".

---

3.1 has

  Attributes TLVs  The processed or addition HOP Attributes, using the
      format defined in Section 2.2 .

Trying to parse this, I think you mean s/addition/additional/

---

3.2.3 has some SHOULDs and SHOULD NOTs. This always makes me wonder what
the exception cases are: under what circumstances MAY an implementation
vary from these rules?

---

In section 4.2, do you want to add a request to IANA to use the same
value as assigned in 4.1?

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up.
>
> Changes are expected over time. This version is dated 24 February 2012.
>
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Standards Track

> Why is this the proper type of RFC? 

The document defines RSVP related formats and behaviors.

> Is this type of RFC indicated in the title page header?

Yes.

>
> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary
>
>  Relevant content can frequently be found in the abstract
>  and/or introduction of the document. If not, this may be
>  an indication that there are deficiencies in the abstract
>  or introduction.


  RFC5420 extends RSVP-TE to specify or record generic attributes which
  apply to the whole of the path of an LSP.  This document proposes an
  extension to the RSVP ERO and RRO objects to allow it to specify or
  record generic attributes which apply to a given hop.

> Working Group Summary
>
>  Was there anything in WG process that is worth noting? For
>  example, was there controversy about particular points or
>  were there decisions where the consensus was particularly
>  rough?

This document moved from the CCAMP to TEAS WGs as part of the routing WG
changes.  This document has been fairly noncontroversial.

>
> Document Quality
>
>  Are there existing implementations of the protocol? Have a
>  significant number of vendors indicated their plan to
>  implement the specification? Are there any reviewers that
>  merit special mention as having done a thorough review,
>  e.g., one that resulted in important changes or a
>  conclusion that the document had no substantive issues? If
>  there was a MIB Doctor, Media Type or other expert review,
>  what was its course (briefly)? In the case of a Media Type
>  review, on what date was the request posted?

The base GMPLS protocol has been implemented.  The extensions defined in
this document are compatible with earlier implementations.  While there
have been no public statements on implementation, the authors are from
multiple vendors, and implementation is expected.  The mechanisms defined
in this document are being reused in two other extensions that have already
been submitted for publication.

> Personnel
>
>  Who is the Document Shepherd?

Lou Berger

> Who is the Responsible Area Director?

Adrian Farrel

>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

The Document Shepherd has reviewed the document as it has progressed
through the CCAMP WG, including as part of an extended WG last calls.
The Shepherd believes this document is ready for publication.

>
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed? 

No.

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization?

No.

> If so, describe the review that took place.

N/A.

>
> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No specific concerns.

>
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.

Yes, see thread at
http://www.ietf.org/mail-archive/web/ccamp/current/msg16687.html

>
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

No IPR disclosed.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with it? 

Solid among those who are interested. "strong concurrence of a few
individuals, with others being silent" is a reasonable
characterization.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No discontent seen.

>
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

The document passes ID nits.

>
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

No.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the WG considers it unnecessary.

No.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section was fully reviewed by the document shepherd and was
updated based on comments.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, etc.

N/A