Controlling State Advertisements of Non-negotiated LDP Applications
draft-ietf-mpls-ldp-ip-pw-capability-09

[Ballot comment]
I have no objection to the publication of this draft, but I do have a couple of non-blocking comments/questions...

1. The Length field in Section 4.1 is under-specified.  One can discern that the Length covers the S bit, the Reserved field, and any included State Advertisement Control Elements from the text, but there is no explicit definition of how to compute the Length field.  That lack of definition goes back to RFC 5561 as well.

2. Will 7or 8 App types be sufficient for future expansion? Should the type values in section 4.1 be maintained in a registry?

[Ballot comment]
I can think of a whole bunch of circumstances in which advertising my non-interest in receiving messages would be useful.

bravo on this being done.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-ldp-ip-pw-capability-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the TLV Type Name Space subregistry of the Label Distribution Protocol (LDP) Parameters registry located at:

http://www.iana.org/assignments/ldp-namespaces/

a single value is to be registered as follows:

Value: [ TBD-at-registration ]
Description: State Advertisement Control Capability
Reference: [ RFC-to-be ]
Notes/Registration Data:

IANA notes that the value for [ TBD-at-registration ] is to be the lowest available value after 0x0500.

IANA understands this to be the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Controlling State Advertisements Of Non-negotiated LDP Applications) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Controlling State Advertisements Of Non-negotiated LDP Applications'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-05-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  There is no capability negotiation done for Label Distribution
  Protocol (LDP) applications that setup Label Switched Paths (LSPs)
  for IP prefixes or that signal Point-to-point (P2P) Pseudowires
  (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP
  session comes up, an LDP speaker may unnecessarily advertise its
  local state for such LDP applications even when the peer session is
  established for some other applications like Multipoint LDP (mLDP)
  or Inter-Chassis Communication Protocol (ICCP). This document
  defines a solution by which an LDP speaker announces to its peer its
  disinterest in such non-negotiated applications, thus disabling the
  unnecessary advertisement of corresponding application state, which
  would have otherwise be advertised over the established LDP session.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability/ballot/


No IPR declarations have been submitted directly on this I-D.

AD review
=====

Hello authors of draft-ietf-mpls-ldp-ip-pw-capability,

I have done my usual AD review of your draft having received the
publication request. The purpose of my review is to remove any
issues that I can find before the document reaches IETF last call
and IESG evaluation.

Technically, this is a fine piece of work, but I'm affraid I have a
few of editorial issues. I hope they will be quick for you to fix so
we can move ahead with the IETF last call.

Please feel free to discuss/reject any of my requests.

Thanks for the work,
Adrian

===

IPoMPLS is not a common term. Fortunately you do define it quite early
in the document, but not until after you have used it a couple of times.
Could you please at least expand the acronym in the Abstract and
Introduction, and maybe give a forward pointer to the definition from
the Introduction.

But be really careful! The term "IP Label Switching" seems to be hardly
used anywhere (says Google) except:
- in this I-D
- in IOS to mean "hop-by-hop label switching" (about which I am also
  none the wiser :-)
- in old material as a synonym for MPLS.
So your definition of IPoMPLS in Section 2 doesn't actually tell us
what it is.

---

You need to take some care with acronyms on first use. You can check at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt to see
which are well known and don't need to be expanded.

I see
P2P
PW
LSR
P2MP
mLDP
FEC
L2VPN
PE

---

Are you sure you don't want IANA to manage a registry for

  State: Defines the type of application state (to be controlled). 
      The value of this field is defined as follows:
      1: IPv4 Label switching
      2: IPv6 Label switching
      3: P2P PW FEC128 signaling
      4: P2P PW FEC129 signaling
      0, 5-15: Reserved.

What does "Reserved" mean?

---

It seems (to me) odd that you require four SEC elements to disallow
all four listed states. I would have thought bit flags would be more
efficient with 1 disallows and 0 allows.

But since this is a case of "I would not have done it this way", you
do not need to make this change on my account provided the WG is OK
with what you have here.