Subject: More comments on Bypass Label draft

From: "Philip Matthews" <[email-masked]>
Date: Mon, 09 Apr 2001 21:16:25 -0400

Robert, George:

Below are some more comments on "RSVP Label Allocation for Backup Tunnels".
These comments here are mainly editorial in nature.

- Philip

------------

* "Global label space"
  In section 2, the draft states that, if the merge node uses a "global
  label space", then it will recognize and properly process packets arriving on
  an interface other than the one the LSP has been signalled on.
  Though I understand what the draft is trying to say, I think this point requires
  some clarification. A node could allocate RSVP labels from a platform-wide
  label space (in the sense that it would not reuse the same label on different
  interfaces), but only program the label on the expected ingress interface.
  In that case, the technique described here would not work.
  I suggest adding a paragraph describing exactly what behaviour you are assuming.

* More on "global label space"
  Where does the term "global label space" come from?  If I remember correctly,
  the MPLS Architecture document uses the term "platform-wide label space".
  Perhaps consistency with the Architecture doc might be a good thing.

* "One to many" vs "Many to one"
  In some places, the draft uses the term "one to many" backup,
  and in other places, the term "many to one" backup.
  Could one term be used consistently?

* Section 3.1
  It is really necessary to repeat verbatum the definition of the fields in the SESSION
  and SENDER_TEMPLATE objects? Perhaps a pointer to [RSVP-TE] would suffice.

* Missing double line
  In the figure on page 4, I believe the link between R2 and R6
  should have a double line, not a single line.

* "effecting global repair"
  Suggest using "achieving global repair" instead.

* Typos
  - "repair to when" on page 3
  - "if," (rather than "If,") on page 5
  - "case the, an" on page 7