The MPLS WG Archive

["Philip Matthews" <philipma@nortelnetworks.com>]

I know that I have missed the last call deadline for comments on this draft,
but I hope the authors will consider the following comments.
Even if it is too late for them to be considered for the draft,
I would still very much appreciate answers to the various questions 
that are interspersed with the comments.

- Philip


2.6. Path MTU
  The text says "The following algorithm applies to all unlabeled IP datagrams
  and to any labeled packets which the node knows to be IP datagrams ...".
  Could the draft be a bit more specific about the rules for determining
  when a labeled packet is an IP datagram? Specifically, could the draft
  explicitly include the case where the labeled packet was received on an
  LSP whose L3PID value is IPv4?
  Also, does this procedure apply to IPv6 datagrams?
  

4.1. Label Object
  The packet format says "(top label)". This seems to be a carry-over
  from when multiple labels could be carried. Suggest replacing this
  by just "Label".


4.1.1.1. Downstream
  The text says "A node is expected to send a Resv message before its
  refresh timers expire if the contents of the LABEL object change."
  When could this happen? Once an LSP is set up, is the downstream node
  allowed to change the LABEL object in a Resv refresh?

  Also, there is a typo: "cooresponding" instead of "corresponding"
  (ditto in section 4.1.1.2)


4.1.1.2. Upstream
  This section says that one way a received LABEL object can be
  unacceptable is if "the implicit null label was assigned, 
  but the node is not capable of doing a penultimate pop for the
  associated L3PID".
  How does the downstream node know if the upstream node is capable
  of doing PHP?
 

4.3.4.1. Selection of the Next Hop
  Three items here:
  1) When selecting the next hop when the next subobject is a loose subobject,
     must the next hop be on the _SHORTEST_ path to the next abstract node,
     as specified by the routing table?
     In particular, in the following example, must C be selected as the next hop,
     even though the path will fail, while the path through B would work?
                                B
                              /   \
                        X -- A      D -- Y
                              \   /
                                C
     [Here X has specified a loose route to Y. Link A -- C is on the shortest path,
      but has insufficient bandwidth. Link A -- B and B -- D have sufficient bandwidth,
      but IGP metrics may this path more expensive]

  2) When selecting the next hop when the next subobject is a strict subobject,
     are there any rules about which links must be selected?
     In particular, some vendors today require that a strict hop to an interface address
     arrive on that interface, while a strict hop to a loopback address can arrive
     on any interface.

  3) Could this section describe what happens to a loosely routed LSP
     when the routing table changes? In particular, does a node just stop
     sending Path messages to the old NHOP and start sending them to the
     new NHOP?


4.4.1.3. Subobject 0x03, Label
  Here the text uses the term "global label" where the architecture draft used the term
  "platform-wide label". 

  Also, there seems to be a conflict here with the sentence in section 4.1.1 which states
  "Labels received in Resv messages on different interfaces are always
   considered to be different even if the label value is the same."
  Could the draft be more precise as to when a label is interface-specific and when
  it is platform-wide?


4.4.3. Handling RRO
  The text states "The initial RRO contains only one subobject - the
  sender's IP addresses." 
  I believe that the text meant to say just "address" (not "addresses"),
  and that the description below about how to select the address in the
  transit case also applies here. Could this be made clear?

  Also, could the draft be explicit on what address to use in this subobject
  in the case where the outgoing link is unnumbered?


4.5. Processing RRO
  The text says "The Label Record subobject is pushed onto the RECORD_ROUTE object
  prior to pushing on the node's IP address."
  Which label is pushed: the label for the upstream link or the label for the
  downstream link?


4.7.4. Reroute and Bandwidth Increase Procedure
  Could this section mention the "Ingress node may reroute" flag in the
  SESSION_ATTRIBUTE object?


4.8.1. Format without Resource Affinities (for SESSION_ATTRIBUTE object)
  Under the "Ingress node may reroute" flag, the text says "A tunnel egress node
  SHOULD use the SE Style when responding with a Resv message."
  Doesn't this "SHOULD" have to be a "MUST" in order
  a) for the reroute and bandwidth increase procedure to work, AND
  b) to correctly verify that bandwidth exists along the path when 
     processing the Path message as described in section 2.2?

  Also, when this flag is not set, doesn't the text need to specify whether
  the egress node should use FF or SE style for reason (b)?


4.8.3. Procedures applying to both C-Types
  There are some missing words in the sentence "Since the Label subobject is not needed
  for all applications of the it is ...".


4.8.4. Resource Affinity Procedures
  There is a incomplete sentence: "If the test fails a error message".


General
  Could the draft specify what is allowed to change in a Path or Resv refresh?
  In particular, are the following objects allowed to change:
    - LABEL
    - LABEL_REQUEST
    - EXPLICIT_ROUTE
    - SESSION_ATTRIBUTE
    - SENDER_TSPEC
  What should the receiving node do if one or more of these objects change?