Re: [mpls] MPLS working group last call on draft-ietf-mpls-lsp-ping-relay-reply

["Adrian Farrel" <[e-mail]>]

Hi,

Just being a good citizen and reviewing this I-D during WG last call.
I didn't have much time so I only found a number of nits most of which
are probably not significant.

Cheers,
Adrian

---

idnits notes the presence of a pre-RFC5378 disclaimer. Do you really 
need that?

---

Abstract


You expand "LSR" correctly, but not on first use.

---

Abstract

   a replying LSR may not have the available route to the
   initiator

s/the/an/

---

Section 1

You need to expand "LSR" on first use.

---

Section 1

   This document describes the extensions to the Label Switched Path
   (LSP) Ping as specified in [RFC4379], by adding a relayed echo reply
   mechanism which could be used to detect data plane failures for the
   inter autonomous system (AS) and inter-area LSPs. 

s/the extensions/extensions/
s/detect/report/ ???
s/for the/for/

---

Section 1

Delete "The extensions are to update the [RFC4379]." as it duplicates
the previous sentence.

---

Section 1

   may not have the available route

s/the/an/

---

Section 2

   LSP Ping [RFC4379] defines a mechanism to detect the data plane
   failures and localize faults. 

s/the data/data/

---

Section 2

OLD
   using an UDP packet with
   the IPv4/IPv6 address of the originating LSR
NEW
   using a UDP packet with
   the IPv4/IPv6 destination address set to an address of the
   LSR that originated the Echo Request.

---

Section 2

OLD
   IP addresses reachability are allowed
NEW
   IP address reachability is allowed

---

Section 2

OLD
   In fact, it
   is almost uniformly the case that in inter-AS scenarios, it is not
   allowed the distribution or direct routing to the IP addresses of any
   of the nodes other than the ASBR in another AS.
NEW
   In fact, it
   is almost always the case that in inter-AS scenarios the only node in
   one AS to which direct routing is allowed from the other AS is the 
   ASBR, and routing information from within one AS is not distributed 
   into another AS.

---

Section 2

   Figure 1 demonstrates a case where one LSP is set up between PE1 and

s/one/an/

---

Section 2

You should expand "AN" on first use.

---

Section 3

   A new TLV named Relay Node Address Stack TLV is defined in this
   document, to carry the IP addresses of the possible relay nodes for
   the replying LSR.

In what way are they "possible" relay nodes? The description of the
mechanism seems to say that these addresses must be used an in the
supplied order.

---

Section 3.1 and onwards

It would help IANA if you distinguished your two instances of "TBD" by
using "TBD1", "TBD2", and "TBD3".

---

Section 3.2

It looks to me that you intend that the address list can include 
addresses of mixed types (otherwise you would not need the address
type in each entry). However, your offset is provided as a counter
and that means that each time this list is processed, the list must
be walked from top down since each entry may be of a different length.
Thus, while the stack is optimized for stripping unwanted addresses 
from the end of the TLV, it is as suboptimal as you could have made it
for parsing because every node that processes the TLV must scan every
entry in the list.

Why not replace the count of addresses with a count of octets to enable
quicker access into the list?

---

Section 3.2

   K bit: if the K bit is set to 1, then this sub-TLV MUST be kept in
   Relay Node Address Stack during TLV compress process described in
   section 4.2.

The address stack entry is not a sub-TLV.

I am inferring from this text that set to 0 the K bit indicates that the
address stack entry can be kept in or left out at will, but actually 4.2
gives some considerably more complex rules for stripping or not 
stripping when k=0. Perhaps you need...

   K bit: if the K bit is set to 1, then this address stack entry MUST
   NOT be stripped from the Relay Node Address Stack during processing
   described in Section 4.2. If the K bit is clear, the entry might be
   stripped according to the processing described in Section 4.2.

---

Section 3.3 seems very "sudden". It doesn't seem to be related to this
document in particular. It is true that the presence of a Relay Node 
Address Stack TLV increases the size of the Echo Reply (or Relayed
Echo Reply) message, but presumably the problem with exceeding the
MTU is only exacerbated by, not caused by, this TLV.

Furthermore, section 3.3 talks about dropping TLVs (or sending them 
with length zero), but gives no hints about which should or can be 
dropped to get the MTU down to size. For example, dropping the Relay
Node Address Stack TLV would presumably be frowned upon.

Lastly, I cannot understand how the new return code is handled when
some other return code is also demanded.

Maybe there is text missing from section 4. All I could find was the
last paragraph of 4.2.

---

Section 4.1

   In addition to the procedures described in section 4.3 of [RFC4379],
   a Relay Node Address Stack TLV MUST be carried in the Echo Request
   message to facilitate the relay functionality.

This is ambiguous. The update to 4379 is not that the new TLV must be 
included in the echo request in order to facilitate the relay 
functionality. I think you mean that you have defined an optional TLV
that can be included in an echo request message to facilitate the relay
functionality, and that where that functionality is needed in order to
relay echo reply messages, the new TLV must be included in the echo
request message.

---

Section 4.1

   The source UDP port field MUST be set
   to the source UDP port.

There is no "source UDP port" field. Perhaps the "Initiator Source Port"
field?

But also, this text is quite confusing. The text in 3.2 is much clearer.

---

Section 4.1 appears to lack guidance about how to construct a Relay Node
Address Stack TLV to include in an Echo Request message. One may cross-
reference to 4.6 and then a lot becomes clear (including the processes 
in 4.2 that otherwise appear convoluted!).

I believe that what you have in mind is that before you can do end-to-
end LSP ping, you must perform a traceroute in order to collect and
construct the full Relay Node Address Stack TLV. Shouldn't the document
make this clear?

---

Section 4.2

   An LSR that does not recognize the Relay Node Address Stack TLV,
   SHOULD ignore it as per section 3 of [RFC4379].

You are not seeking to change 4379 behavior here, so using 2119 SHOULD
is confusing. Indeed, you cannot change legacy behavior in this 
document. 

I think you need...
                                                                
   The Type of the Relay Node Address Stack TLV is chosen from the range
   32768 to 49161 so that (per section 3 of [RFC4379]) an LSR that does
   not recognize the TLV knows that the TLV is optional and can safely
   ignore it.

---

I tried to work out how things would pan out if two ASes on the path 
used the same address space within their AS. Would an address appear in
the stack and seem to be routable when it is really an address in the
other AS?

---

4.3 has

   If the first IP address in the Relay Node Address Stack TLV is not
   the next relay node address

There are two questions that follow:
- You have a "SHOULD" to resolve this "if". What are the conditions for
  varying that behavior?
- You don't say what to do if this "if" is not satisfied. Presumably, in
  this case it sends an Echo Reply and you can address my question with
  a pointer to 4.5.

Similarly, 4.4 has:

   If the next relay node address is not the first one in the address
   list, i.e., another intermediate relay node, the relay node MUST send
   an Relayed Echo Reply message to the determined upstream node with
   the payload unchanged other than the Relay Node Address Stack TLV.

If this "if" does not hold, what does the implementation do? Again, a 
pointer to 4.5 may be enough.

---

The third case in 4.5 is when the receiver does not understand the TLV
and ignores it. In this case it will send an Echo Reply without itself
including the TLV.

---

Section 6 should note that the new TLV provides a way for Echo Reply
messages to be diverted so that information can be collected. For
example, if a stack entry can be inserted, the Echo Reply messages can
be caused to transit another AS unrelated to the LSP under test. Since
the Echo Reply reveals path information about the LSP, this is a
valuable attack.  Having said that, you can say how this TLV is 
protected in the Echo Reply message.
> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: 27 May 2015 10:21
> To: [e-mail]; [e-mail]; draft-ietf-mpls-lsp-ping-relay-
> [e-mail]; BRUNGARD, DEBORAH A
> Subject: [mpls] MPLS working group last call on
draft-ietf-mpls-lsp-ping-relay-
> reply
> 
> Working Group,
> 
> This is to initiate a two week working group last call on
> draft-ietf-mpls-lsp-ping-relay-reply.
> 
> Please send your comments to the mpls wg mailing list ([e-mail]).
> 
> There are two IPR disclosures against this document. All the authors
> and contributors have stated on the working group mailing list that
> they are not aware of any other IPRs that relates to this draft.
> 
> This working group last call ends June 10, 2015.
> 
> A little bit of background. We requested publication for this draft
> earlier, but very late in the process it was discovered that the
> document needed more work - and it was returned to the working group.
> Document has been updated, and you can find a diff:
> 
> https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-lsp-ping-relay-reply-
> 05&url2=draft-ietf-mpls-lsp-ping-relay-reply-09
> 
> A discussion on the updates can be found at:
> http://www.ietf.org/proceedings/92/slides/slides-92-mpls-8.pdf
> 
> /Loa
> for the MPLS wg chairs
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls