Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
draft-ietf-mpls-mldp-in-band-signaling-08

[Ballot comment]

  The Gen-ART Review by Suresh Krishnan on 13-Nov-2012 raised a
  non-blocking question:  The draft has the pre-5378 boilerplate
  but it is unclear to me why. I went through the older versions
  to find draft-wijnands but that was submitted first in 2009.
  Is this really necessary?

[Ballot comment]

(1) and (2) were originally discusses, I've left in the text but
added comments from the mail exchange below each.

(1) I'm skeptical that there are no security considerations
beyond those in 5036. As I read it, you are taking addresses
and masks from PIM messages and maybe creating LSPs based on
those, so its hard to believe there's no way to muck with PIM
messages to create a new bad effect for the MPLS n/w.  Can you
point me at where the WG considered this and concluded that
there is in fact nothing new here? 

  So if badness can happen to the PIM n/w when it connects
  via MPLS, it'd be good to describe that.

(2) RFCs 4607 and 4601 seem to depend on IPsec as a
countermeasure, and I'm not sure that e.g. LSR (D) in figure 1
would be able to see anything much if ESP were in use to
protect PIM messages, or is AH really used here? If AH is not
used, but ESP is, or if IPsec is not used at all, that would
seem to imply that all of the security considerations of 4607
and 4601 also come into play but without being able to depend
on IPsec as a useful countermeasure, which'd imply that more
text is needed here (or somewhere).  Am I right there? (It
could be that expectations when 460[17] were written were
optimistic, but if that's the case we ought recognise reality
and not depend on what turned out to be bad predictions.) RFCs
5294 and 5796 (which updates 4601) might also have relevant
security considerations - were those taken into account here?

  Turns out it wasn't clear to me that (D) in figure 1 has
  to be a PIM speaker and part of the IPsec SA with (B)
  which, if true, means that ESP would be fine. If that's
  right then making it clear would be good, e.g. say that
  (D) has to share an IPsec SA with (B) if PIM security
  based on IPsec is to be of use.

--- original comment below


- typo: speccial

- section 3, is opaque really a good term here when you're
defining the internal structure? If that's inherited from
elsewhere maybe just say that they're not opaque in this
context. Or perhaps s/transit opaque/transit-opaque/ is right?

- 3.3 & 3.4 - can't you specify a max for Mask Len for each of
these? Why not do that?

[Ballot comment]
A very small point, which you can absolutely ignore if you don't think there's anything wrong:
In newspaper parlance, one would say that the Abstract "buries the lede".  The key point -- what this document is about -- doesn't come until the last sentence, only after a bunch of "suppose you have this," and "after this happens," and so on.  Can you find a way to lead with the last sentence, and re-cast the abstract from there?

-- Section 3 --
In the figures in these subsections... maybe this is just me, maybe this is how all the MPLS diagrams are, and maybe it's not a problem at all.  In which case, just ignore this also.  But look at 3.1, for example:

  Type:  3 (to be assigned by IANA).
  Length:  8 octets
  Source:  IPv4 multicast source address, 4 octets.
  Group:  IPv4 multicast group address, 4 octets.

You say "8 octets" for "Length", and "4 octets" for "Source"... but you mean two different things.  For Source, you mean that the field is 4 octets in size.  For Length, you mean that the *value* in the field is 8 -- the field itself is 2 octets in size.  That inconsistency bothers me.  Might it be better to do it somewhat like this?:

NEW - choice 1
  Type:  3 (to be assigned by IANA).
  Length:  8 (octet size of Source and Group fields)
  Source:  IPv4 multicast source address, 4 octets.
  Group:  IPv4 multicast group address, 4 octets.

NEW - choice 2
  Type:  3 (to be assigned by IANA).
  Length:  8 (octet size of the remainder of the TLV)
  Source:  IPv4 multicast source address, 4 octets.
  Group:  IPv4 multicast group address, 4 octets.

...and similarly for Sections 3.2 thru 3.4.

[Ballot discuss]

Sorry for such vague discuss-discuss points, but I don't know
much about either PIM or MPLS. OTOH, I have seen lots of cases
where sticking things back-to-back does cause new headaches.
However, I'll clear quickly when we've discussed this,
promise:-)

(1) I'm skeptical that there are no security considerations
beyond those in 5036. As I read it, you are taking addresses
and masks from PIM messages and maybe creating LSPs based on
those, so its hard to believe there's no way to muck with PIM
messages to create a new bad effect for the MPLS n/w.  Can you
point me at where the WG considered this and concluded that
there is in fact nothing new here? 

(2) RFCs 4607 and 4601 seem to depend on IPsec as a
countermeasure, and I'm not sure that e.g. LSR (D) in figure 1
would be able to see anything much if ESP were in use to
protect PIM messages, or is AH really used here? If AH is not
used, but ESP is, or if IPsec is not used at all, that would
seem to imply that all of the security considerations of 4607
and 4601 also come into play but without being able to depend
on IPsec as a useful countermeasure, which'd imply that more
text is needed here (or somewhere).  Am I right there? (It
could be that expectations when 460[17] were written were
optimistic, but if that's the case we ought recognise reality
and not depend on what turned out to be bad predictions.) RFCs
5294 and 5796 (which updates 4601) might also have relevant
security considerations - were those taken into account here?

[Ballot comment]


- typo: speccial

- section 3, is opaque really a good term here when you're
defining the internal structure? If that's inherited from
elsewhere maybe just say that they're not opaque in this
context. Or perhaps s/transit opaque/transit-opaque/ is right?

- 3.3 & 3.4 - can't you specify a max for Mask Len for each of
these? Why not do that?

IANA has reviewed draft-ietf-mpls-mldp-in-band-signaling-07 and has
the following comments:

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

In the LDP MP Opaque Value Element basic type name space in the Label
Distribution Protocol (LDP) Parameters registry located at:

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

four new Elements are to be added as follows:

Value: 3
Name: Transit IPv4 Source TLV type
Reference: [ RFC-to-be ]

Value: 4
Name: Transit IPv6 Source TLV type
Reference: [ RFC-to-be ]

Value: 5
Name: Transit IPv4 Bidir TLV type
Reference: [ RFC-to-be ]

Value: 6
Name: Transit IPv6 Bidir TLV type
Reference: [ RFC-to-be ]

IANA understands that this is 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Multipoint LDP in-band signaling for Point-to-Multipoint and
  Multipoint- to-Multipoint Label Switched Paths'
  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 2012-11-09. 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

  Consider an IP multicast tree, constructed by Protocol Independent
  Multicast (PIM), needs to pass through an MPLS domain in which
  Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-
  Multipoint Labels Switched Paths (LSPs) can be created.  The part of
  the IP multicast tree that traverses the MPLS domain can be
  instantiated as a multipoint LSP.  When a PIM Join message is
  received at the border of the MPLS domain, information from that
  message is encoded into mLDP messages.  When the mLDP messages reach
  the border of the next IP domain, the encoded information is used to
  generate PIM messages that can be sent through the IP domain.  The
  result is an IP multicast tree consisting of a set of IP multicast
  sub-trees that are spliced together with a multipoint LSP.  This
  document describes procedures how IP multicast trees are spliced
  together with multipoint LSPs.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-signaling/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-in-band-signaling/ballot/


No IPR declarations have been submitted directly on this I-D.
However, an IPR declaration against draft-wijnands-mpls-mldp-in-band-signaling
that this I-D replaced can be seen at:

  https://datatracker.ietf.org/ipr/1305/

AD Review
===
Hi,

I have done my AD review of your draft prior to sending it to IETF last
call and subsequent IESG evaluation. There are a number of small nits
that I hope you can mop up, and a few questions that we should be able
to resolve through discussion or with a new revision of the I-D.

I will change the state of the draft in the data tracker to show
"revised I-D needed", but please feel free to debate these points if you
want to convince me that no change is needed.

Cheers,
Adrian

---


Please fix the idnits as indicated in the shepherd write-up

> The idnits-tool flags three "problems"
>
> 1. There are three outdated references
>
> 2. There is a disclaimer for pre-RFC5378 work, that is not
>    really needed.
>
> 3. Some of the references are to older version of the referenced
>    document

In particular, note RFC 6388.

---

Abstract is fine in what it says, but it should also have a short
second sentence "This document..." saying whatever it is that this
document does.

---

Afraid that you need to expand acronyms on first use in the body text
because it is assumed to be stand-alone from the Abstract.

But some are already well-known and don't need to be expanded. (PIM,
BGP, MPLS, IP)


I see...

mLDP
LSP
FEC
LSR

---

Section 1
s/enduser/end-user/  twice

---

Section 1

  Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
  the MPLS network.  This type of service works well if the number of
  LSPs that are created is under control of the MPLS network operator,
  or if the number of LSPs for a particular service are known to be
  limited in number.

This paragraph gives me cause to wonder. Does the service work badly if
neither of these conditions holds? What would badly mean?

I suspect you are hinting that there is a scaling issue here. Do you
think you should bring that out? I don't think it would damage your work
if you did so because clearly you believe there are advantages to this
approach of direct mapping when the numbers are under control.

---

s/draft/document/
- Section 1 twice
- Section 2.1
- Section 6

---

Section 1.2
s/an source/a source/
s/An P2MP/A P2MP/

---

Section 1.2

  IP multicast tree :  An IP multicast distribution tree identified by
      an source IP address and/or IP multicast destination address, also
      refered to as (S,G) and (*,G).

I think you and/or is wrong. The G is always present and the S is
optionally present. You have written that at least one of S and G must
be present.

Also, why do you call it "destination address" not "group"? The text
later (e.g. Section 2) uses "group".

Oh, and s/refered/referred/

---

Section 1.2

  MP2MP LSP:  An LSP that connects a set of leaf nodes, acting
      indifferently as ingress or egress.

"indifferently" is beautiful in this usage.
Suggest:

  MP2MP LSP:  An LSP that connects a set of leaf nodes that may each
      independently act as ingress or egress.

---

Section 1.2

  Ingress LSR:  Source of the P2MP LSP, also referred to as root node.

Doesn't "ingress" have a meaning in the context of an MP2MP LSP?

---

Section 2 really would benefit from at least one figure, but maybe more.
It is not a requirement to add them, but they don't cost anything and
they are really easy to add.

---

Section 2

  Suppose an LSR, call it D, is attached to a network that is capable
  of MPLS multicast and IP multicast

I suspect from the text that follows (e.g. ""the IP multicast tree needs
to travel through the MPLS network") that D is attached to two networks
one of which is capable of MPLS multicast, and the other is capable of
IP multicast. Is that what you meant?

---

Section 2.3

  Bidirectional IP multicast trees [RFC5015] MUST be transported across
  a MPLS network using MP2MP LSPs.

I am trying to work out how this "MUST" is to be applied.

Obviously you don't mean that every time you have a bidir IP mcast tree
you have to go out and find an MPLS network to transport it across :-)

But are you trying to say that when a bidir IP mcast tree needs to be
carried over an MPLS network it MUST be carried by an MP2MP LSP? Is that
a. really true
b. enforceable by the IETF
c. something that this protocol spec can state?

Are you actually saying:

  When a bidirectional IP multicast tree [RFC5015] is carried over an
  MPLS network using the in-band signaling described in this document,
  it is supported using an MP2MP LSP.

---

Section 3.1

Figure seems to be missing row ends.

---

Sections 3.1 and 3.2

Shouldn't you say how to encode (*,G)? What value goes in the Source
field in the TLV?

---

4.  Security Considerations

  The same security considerations apply as for the base LDP
  specification, as described in [RFC5036].

Isn't this a little bit of a stretch?
The fact is that there is now a new way to trigger behavior inside the
MPLS network (viz. by hacking a PIM network). And a new way to disrupt
a PIM network (viz. by hacking an MPLS network).

At the very least, this means policy needs to be carefully configured
at the edge LSRs. You need to talk about this in this section.

---

I find two important topics missing from this document:
1. manageability
2. backward compatibility

For the first of these, I should have liked to have some discussion of
what things need to be configured to make this process work. What should
be configurable in an implementation (you mention "under control of the
MPLS network operator" in Section 1) and how should an operator use the
knobs?

For the second, I think you need to describe what happens when a transit
or an ingress is unaware of the meaning of the opaque TLVs. The transit
is easy, I think - it should not examine the opaque info so it won't
matter... you can just make this statement and point at the appropriate
section of RFC 6388. The ingress is more interesting: will it barf,
release the label, or ignore the unknown opaque TLV? If it ignores it,
how will you ever know that your mcast flow has not been set up (except
you never receive traffic)?

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The MPLS working group request that:

  Multipoint LDP in-band signaling for Point-to-Multipoint and
            Multipoint-to-Multipoint Label Switched Paths

              draft-ietf-mpls-mldp-in-band-signaling-06

  is published as an RFC on the standards track.

  Since this is an extension to mLDP, (a standard track document),
  it also need to be on the standards track. There are service
  provider looking to use this solution in production networks.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Sometimes an IP multicast tree, constructed by Protocol Independent
  Multicast (PIM), needs to pass through an MPLS domain in which
  Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-
  Multipoint Labels Switched Paths (LSPs) can be created. The part of
  the IP multicast tree that traverses the MPLS domain can be
  instantiated as a multipoint LSP. When a PIM Join message is
  received at the border of the MPLS domain, information from that
  message is encoded into mLDP messages.  When the mLDP messages reach
  the border of the next IP domain, the encoded information is used to
  generate PIM messages that can be sent through the IP domain.  The
  result is an IP multicast tree consisting of a set of IP multicast
  sub-trees that are spliced together with a multipoint LSP.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

  The MPLS working group has a few non-MPLS-TP documents that fell
  into the cracks when we were allocating almost all of our time to
  wrapping up the MPLS-TP documents. This document is one of them.
  Version -04 of the document was working group last called in
  October 2011, it was updated based on on comments during working
  group last call. After that the shepherd fumbled and left the
  draft without attention for almost 6 months.

  When we finally go around to pau attention to the document again
  the document shepherd re-reviewed it and found there were no
  reason to re-issue a working group last call. The draft is stable.

  This document has a strong support in the working group
  and has been well reviewed. We had good discussions both
  on the mailing list and at the f2f meetings.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

  We know of existing implementations and intentions to implement
  this specification.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Loa Andersson is the document shepherd.

  Adrian Farrel is/will be the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd have reviewed the document several times,
  e.g. before issueing to poll to see if there were support to make
  it a working hroup document, before the WG last call, and recently
  when deciding to progress the document without a new working
  group last call.


  The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such concerns!

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Before requesting publication the working group chairs did an IPR poll
  in the working group and the authors, asking any members of the working
  group to speak up if they were aware of IPRs. The same poll required 
  the authors either to indicate if they were aware of IPRs or say that
  they were not.

  All the authors said they were not aware of any IPRs, other than the
  previously filed IPR claim (ID #1305).

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  There is one IPR claim filed for this document (ID #1305).

  The IPR was original filed against the individual "ancestor"
  document draft-wijnands-mpls-mldp-in-band-signaling-02.

  The filing is no longer visible from the mpls working group web
  page, but hs been brought to the attention of the working.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The working group is behind this document. It has been well discussed
  and reviewed. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The idnits-tool flags three "problems"

  1. There are three outdated references

  2. There is a disclaimer for pre-RFC5378 work, that is not
      really needed.

  3. Some of the references are to older version of the referenced
      document

  The authors will be required to fix this if a new version is
  needed or it will be captured in a RFC Editors note.

  No other nits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There are no such formal review criteria.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There is one normative reference that point to an Internet Draft,
  but this this draft has however been published as an RFC.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document requests four standards action values from "LDP MP
  Opaque Value Element basic type" a registry defined in RFC 6388.
  The requests for IANA allocation are clearly written.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries that requires expert review.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No formal language.