Subject: [mpls] AD review of draft-ietf-mpls-explicit-resource-control-bundle

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 31 Oct 2010 11:16:32 -0000

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the
review is to catch any nits or issues before the document goes
forward to IETF last call and IESG review. By getting these issues
out at this stage we can hope for a higher quality review and a
smoother passage through the process.

I am having some trouble with the draft. There are a good number of
small issues of language and the like. These are easily fixed although
I confess that they are so plentiful that I have not noted them all.
More important, are the issues of content that I have noted below.

I think my comments need to be addressed for this document to stand
half a chance of getting through IESG review, and I would like you to
have a look and see whether you can work to improve the text before I
take it forward. Perhaps you should take some time to talk with the
document shepherd and WG chairs to determine what the best course of
action is. All of the comments are, of course, open for discussion.

I have moved the draft into "AD-review:Revised-ID-needed" state in
the datatracker, and I look forward to seeing the new revision which
I can put forward for IETF last call.

Thanks,
Adrian

---

I have a meta-question about this draft. Given RFC 4990 Section 6.2,
why is this extension needed? I can see it would work, but what is the
benefit of creating a second way to signal a component link in an ERO
or RRO?

---
I think you need to rewrite the Abstract. Consider that you should be
able to read the Abstract in a fair degree of isolation, so it should
give context.

At the moment you jump straight into Record Route without any hints
that you are dealing with GMPLS!

You also need to remove citations from the Abstract (you are allowed
to name the documents).

---

Please search out "draft" and replace with "document" since you hope
that it will become an RFC at some point :-)

---

Section 1 needs to include a definition of "Component Interface"

---

Section 1

   For unnumbered component links, the component link
   ID is assumed to be unique on an advertising node.

I think you might usefully reference RFC 3477 here. The definition of
an unnumbered TE link in 3477 uses this concept, and you are extending
it to be used in unnumbered component links.

I recall there was some debate about the validity of this extension.
Many people said that they wanted the component link ID to be unique in
the scope of the bundle (cf. port numbers). Of course, the component
link ID can be constructed from the rack-shelf-card-port to achieve the
necessary uniqueness, but it is far from obvious to me that the
assumption you make is universal.

So you should at least expose this a little more clearly. Perhaps there
is something in section 2.1 of RFC 4201 and section 13.12 of RFC 4204
you can reference explicitly?

---

It is usual to begin the document with the Introduction. This is
certainly the preference of the RFC Editor, and she may well ask you
to change the order of your sections. Might as well do it now!

---

Can you go through the document and expand all of the acronyms where
they are first used.

---

Section 2

s/networks [RFC3945] that deals/networks [RFC3945] that deal/

---

Section 2

   Link Bundling, introduced in [RFC4201], is used to improve routing
   scalability by reducing the amount of TE related information that
   needs to be flooded and handled by IGP in a TE network. This is
   accomplished by aggregating and abstracting the TE Link resource. In
   some cases the complete resource identification is left as a local
   decision.

I really don't think the reader will understand this.
What does "complete resource identification mean"?
Do you mean choice is left as a local decision? Because identification
is always a local decision.

---

Section 2

   In GMPLS networks [RFC3945] that deals with unbundled (being either
   PSC, L2SC, TDM or LSC) TE Links, one of the types of resources that
   an LSP originator can control and would like to record are the TE
   Link interfaces used by the LSP. The resource control and recording
   is done by the use of an explicit route, i.e., Explicit Route (ERO)
   Object and record Route, i.e., Record Route Object (RRO) object,
   respectively.

   Link Bundling, introduced in [RFC4201], is used to improve routing
   scalability by reducing the amount of TE related information that
   needs to be flooded and handled by IGP in a TE network. This is
   accomplished by aggregating and abstracting the TE Link resource. In
   some cases the complete resource identification is left as a local
   decision. However, as described above there are cases when it is
   desirable for a non-local (e.g., LSP head-end) node to identify
   completely or partially the LSP resources.  In either case, and for
   administrative reasons, it is required to know which component link
   within a bundled TE link has been used for a given LSP.

I don't think you can get away without actually saying what the reason
for wanting to know/control this information is? Why does an LSP
originator want to control the component links? You need to set out
the requirements and problem description better.

---

Section 2

   Link Bundling, introduced in [RFC4201], is used to improve routing
   scalability by reducing the amount of TE related information that
   needs to be flooded and handled by IGP in a TE network. This is
   accomplished by aggregating and abstracting the TE Link resource. In
   some cases the complete resource identification is left as a local
   decision. However, as described above there are cases when it is
   desirable for a non-local (e.g., LSP head-end) node to identify
   completely or partially the LSP resources. In either case, and for
   administrative reasons, it is required to know which component link
   within a bundled TE link has been used for a given LSP.

"In either case"?
What is the other case?

---

Section 2

   When link bundling is used to aggregate multiple component links into
   a TE link, label is not the only resource that needs to be identified
   and recorded.

But this is the first time you have mentioned recording labels.

---

Try to remove things like "RRO objects" because the "O" in "RRO" means
"object".

---

Section 3.2

I don't think this section makes it crystal clear whether, on Resv RRO
processing, a node pushes the upstream or downstream component link
identifier. Yes, this follows Resv RRO processing for the normal case
(i.e., the node always pushes the downstream interface ID), but you
could help make this clear.

---

Section 4.1

   The following SHOULD result in "Bad EXPLICIT_ROUTE object" error
   being sent upstream by a node processing an ERO that contains the
   Component Interface ID sub-object:

   o) The first component interface identifier subobject is not
      preceded by a sub-object containing an IPv4 or IPv6 address, or
      an interface identifier [RFC3477], associated with a TE link.

and later...

   Inferred from above, the interface subobject should never be the
   first subobject in a newly received message.  If the component
   interface subobject is the first subobject in a received ERO, then it
   SHOULD be treated as a "Bad strict node" error.

These seem to contradict each other.

---

Section 5

5. Forward Compatibility Note

Isn't this section actually about backward compatibility?

---

Section 6

Don't you think that revealing additional information about component
links and allowing additional control is an additional security risk?
Therefore, the implementation of this I-D increases the need to consider
implementing and deploying RSVP-TE security mechanisms.

You should make reference to RFC 5920.

---

Section 7

It would be really helpful if you named the registries from which you
want assignments made so that IANA can work it out.

---

Section 7

   o) A new "Component Link Recording desired" flag (value TBD)
      of the LSP_ATTRIBUTES object [RFC5420]

The registry requires that you supply...

  Bit No
  Name
  Attribute Flags Path
  Attribute Flags Resv
  RRO