Subject: Comments on draft-mpls-rsvp-lsp-tunnel-06.txt

From: "Philip Matthews" <[email-masked]>
Date: Wed, 02 Aug 2000 07:39:17 -0400

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?

---

From: David Charlap <[email-masked]>
Date: Wed, 02 Aug 2000 10:31:12 -0400

I think I can answer one of these....

Philip Matthews wrote:
>   When could this happen? Once an LSP is set up, is the downstream
>   node allowed to change the LABEL object in a Resv refresh?

Normally, a downstream node will not change the LABEL object.  But there
are scenarios where it could happen.  For example.  Imagine this
topology:

	A---B---C---D

A Path and Resv go through and an LSP is established from A to D.

Now, the inbound interface on D goes down, but the outbound interface on
C remains up.  (Perhaps it was administratively disabled - obviously,
this wouldn't happen if the fiber was disconnected.)

C thinks the link is still up and continues sending Path refreshes.  D
thinks the link is down and tears its state.

Now, before C misses enough Resv refreshes to presume link failure and
generate a PathErr, the inbound interface on D comes up again.

D receives a Path from C (one of the usual refreshes), but it sees it as
a new Path (since it no longer has the old state in memory).  So it
allocates a new LABEL (which will almost certainly be different from the
one it had before) and sends this to C in its Resv messages.

Admittedly, this is a rare (and a bit contrived) sitation, but it can
happen.

>   Could the draft specify what is allowed to change in a Path or Resv

In general, in keeping with the soft-state nature of RSVP (see RFC2205),
any parameter can change, unless explicitly stated otherwise.  In actual
practice (especially when used as a part of MPLS), most are unlikely to
actually change.

>   In particular, are the following objects allowed to change:

These shouldn't, under normal circumstances.  But, in the case where
only one side of a link goes down and later comes back up, a switch can
receive a "refresh" where these objects have changed.

>     - EXPLICIT_ROUTE

In theory.  It is, however, preferred that the ingress node use the
"make before break" procedure to effect a reroute.  While changing the
ERO would, in theory, work, it can create some race conditions - where
the new Path is established, and then another switch (which used to be
on the path) times out and sends out tear messages.

>     - SESSION_ATTRIBUTE

Again, I think it will be unlikely for this to change, but it is
possible.

>     - SENDER_TSPEC

This has always been possible (see RFC 2205).  George Swallow has
stated, however, that it is preferable to do a make-before-break reroute
in the situation where the bandwidth for an LSP must be changed.

-- David