Subject: [mpls] AD review of draft-ietf-mpls-ldp-gtsm

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 30 Apr 2012 13:49:42 +0100

Hello authors of draft-ietf-mpls-ldp-gtsm,

I have conducted my usual AD review of your draft in response to the
publication request from the WG. This, of itself, is not reason to
induce panic :-)

My review has yielded a number of questions and nits. All of the
points are open for discussion and I am not mandating changes. But
I think that there are enough issues here to warrant a new revision.

I have put the document into "revised I-D" state and look forward to
a new version or a lively email debate.

Thanks,
Adrian

---

I am confused by whether you propose GTSM to be enabled by default. 

Section 1 says...
   GTSM specifies that it SHOULD NOT be enabled by default in order to
   remain backward-compatible with the unmodified protocol

Section 1.2 says...
   GTSM and will require (statically or dynamically) disabling GTSM.
   See Section 3.

Section 3 says...

   The reason GTSM is enabled for Basic Discovery by default

Indeed, 5082 says...

   3.  Use of GTSM is OPTIONAL, and can be configured on a per-peer
       (group) basis.

In fact, I don't think GTSM is enabled by default in your document. I
think what you have is that the desire to use GTSM (i.e., the
negotiation to use it) is enabled by default in implementations of your
spec. But this is subtly different from what the text says.

---

Can you tidy the English in Section 1. Suggested...

OLD
   GTSM specifies that it SHOULD NOT be enabled by default in order to
   remain backward-compatible with the unmodified protocol; this
   document specifies having a built-in dynamic GTSM capability
   negotiation for LDP to suggest the use of GTSM, provided GTSM is not
   enabled unless both peers can detect each others' support for GTSM
   procedures and agree on its usage as described in this document.
NEW
   GTSM specifies that it should not be enabled by default; this
   facilitates backward-compatibility with the unmodified protocol. This
   document specifies a dynamic negotiation for the an LDP peer to 
   suggest the use of GTSM.  GTSM will be used as specified in this
   document provided both peers on an LDP session can detect each
   others' support for GTSM and agree to use it.
END

Note the change s/SHOULD NOT/should not/. This text in Section 1 is not
defining any protocol behavior and comes before the citation of RFC 
2119. It doesn't need to use upper case.

---

You need to do some work to expand acronyms on first use if they are not
listed with an asterisk at:

http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

I found:

LSR

---

Is it time to define an IANA registry for the common Hello parameters
bit fields? Had one existed, you would not have needed to update 5036.
If you create one now, future bit users will not have to update your
RFC.

---

Section 2.1

   The G flag is meaingful only if T and R flags are set to 0 (which
   must be the case for Basic Discovery), otherwise, the value of G flag
   SHOULD be ignored on receipt.

This is clear for the T flag: the use of GTSM is not supported for 
targeted (extended) Hellos.

Why is this the case for the R flag? The use of the R flag is making a 
request, not demanding use. It might be the normal case that you would
not set the R flag unless you were more than one hop away, but it does
not follow that this is the case, does it? As indicated in RFC 5036, a
Hello receiver that does not support targeted Hellos ignores the
request (i.e., the R flag). That would clear it to support the G flag.

---

Section 2.1

   Any LSR not supporting GTSM for LDP, as defined in this document,
   would continue to ignore the G flag, independent of T and R flags'
   value, as per Section 3.5.2 of [RFC5036].

I think you need to cover two cases. As it happens the behavior you are
asking for is the same, but I think you need to call out the two cases
separately:

1. An LSR that does not recognise the G flag.
2. An LSR that does recognise the G flag but does not support GTSM 
   (either through implementation or configuration).

---

Section 2.2

   Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello
   messages to link-level multicast address (224.0.0.2 or "all
   routers").  Such messages are never forwarded beyond one hop and
   assumed to have their IP TTL or Hop Count = 1.

This assumption is, I think, new in your document. I can't find anything
about this in 5036 (although I may have missed it).

I suspect you need to change this from an assumption to a RECOMMENDation

---

Section 2.2

   An LSR that is capable of applying GTSM procedures to the subsequent
   TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common
   Hello Parameter TLV in the LDP Link Hello message [RFC5036].

"capable" is such an interesting word :-)
And the text here is interesting. Does this cut into the discussion of
defaults above? What you are saying is that a device that has been coded
to support GTSM has to negotiate its use regardless of operator
preferences. Why?

How would the following look?

   Unless configured otherwise, an LSR that supports GTSM sets the G 
   flag (for GTSM) to 1 in Common Hello Parameter TLV in the LDP Link
   Hello message [RFC5036].

---

Section 2.2

   An LSR, upon receiving an LDP Link Hello message, would recognize the
   presence of G flag (in Common Hello Parameter TLV) only if it
   supports GTSM for LDP, as specified in this document.

This is not true :-(
You are updating 5036 so all new implementations will recognise the G 
flag whether or not they support GTSM.

---

Section 2.2

   If an LSR
   recognizes the presence of G flag with the value =1 in the received
   LDP Link Hello message, then it MUST enforce GTSM for LDP in the
   subsequent TCP/LDP peering session with the neighbor that sent the
   Hello message, as specified in Section 2.3 of this document.

Again, this does not offer the operator any control or choice in the 
matter. Why is the use of GTSM not configurable?

---

Section 2.2

   If an LSR that has sent the LDP Link Hello with G flag = 1, then the
   LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP
   Transport Connection(s) with that neighbor (e.g., LSR2).  Please see
   Section 2.3 for more details about the TCP transport connection
   specifics.

Why is this MUST? What if the peer has responded with G=0 indicating it
doesn't support (or want to use) GTSM? Surely, in that case, the local
LSR can set any TTL.

BTW Why is this paragraph in Section 2.2?

---

I think the mentions of "LSR2" in sections 2.2 and 2.3 are a little 
unnecessary.

---

Are we missing a discussion of what happens if the value of G changes on
a subsequent Hello?

---

Section 3

Typo

s/en the third case/In the third case/

---

Section 5

Suppose I touch the setting of the G flag in transit?

That means that LDP Hello security is more important, right?

---

Section 5

Shouldn't you make reference to the security section of 5082. In 
particular, you need to highlight the things GTSM does not protect 
against.

---

I believe your document should give stronger hints than the generic
comments in 5082 about what should be done with an LDP message that
"fails" a GTSM TTL check. This is appropriate because you are writing
a protocol-specific application of GTSM.