Subject: [mpls] AD review of draft-ietf-mpls-seamless-mcast

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Jan 2015 22:03:57 -0000

Hello authors,

I have conducted my usual AD review of this document to attempt to
catch issues that would otherwise show in IETF last call or IESG
evaluation.

There are number of small nits listed below. None of these needs
delay the document and you should feel free to debate the points with
me rather than blindly accepting my view.

I will start the IETF last call and enter these as last call comments.
You can then address them together with any other review comments you 
receive during last call.

Thanks for the work.

Adrian

===

idnits reveals that the copyright year needs to be 2015. Please update
that if you revise the document.

idnits also points out that you probably don't need the boilerplate for
pre-RFC5378 work. unless you are sure you need it, please take it out.

---

I think that the RFC Editor will need your help expanding some of the
abbreviations that are not listed as "well known" in the list at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
You might kick this off by doing a scrub yourselves.

---

Section 3 line 1
s/suppose/assumed/

---

5.1.2 and 5.2.2 titles

s/re-advertise/re-advertised/                                      

---

5.1.3 has

   To avoid requiring ABRs to participate in the propagation of C-
   multicast routes, this document requires ABRs NOT to modify BGP Next
   Hop when re-advertising Inter-AS I-PMSI A-D routes.

"NOT" is not a 2119 term in its own right.
Suggest you rephrase as

   To avoid requiring ABRs to participate in the propagation of C-
   multicast routes, this document specifies that ABRs MUST NOT  
   modify BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes.

---

In 6.1.2

   If the application is global table multicast, then the unicast routes
   to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended
   Community [RFC6514] where the IP address in the Global Administrator
   field is set to the IP address of the PE or ASBR advertising the
   unicast route.

I wondered about this "SHOULD". Trying to decide why we might decide to
vary that and what the consequences would be.

Similarly one para later...

   Further, if the application is global table multicast, then the BGP
   unicast routes that advertise the routes to the IP addresses of
   PEs/ASBRs/ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop
   Extended Community.

---

7.2.2.1

   This section applies only if it is desirable to send a particular (S,
   G) or (*, G) global table multicast flow only to those egress PEs
   that have receivers for that multicast flow.

Is this s/desirable/desired/ ?
If not then some guidance as to how to judge when it is desirable.
If so, then perhaps you could be a little less passive-voice: who 
desires it?

---

7.2.2.2

   It may be desirable for an ingress PE to carry multiple multicast
   flows associated with the global table multicast over the same inter-
   area P2MP service LSP.

Can you give guidance as to why it might be desirable?
Or possible (as above) s/desirable for/desired that/ also adding some
explanation about who has the desire (and possible why).

---

7.2.3

   To allow the egress PE
   to determine the sender upstream node, the intra-area P2MP LSP must
   be signaled with no PHP, when the mapping between the inter-area P2MP
   service LSP for global table multicast service and the intra-area
   P2MP LSP is many-to-one.

The lower case "must" jumped out. Probably upper case?

---

Section 14

Is the term "transport LSP" introduced by this document?
If so, a little more definition would be nice (just a few words to make
it clear that you are defining the term).
If not, can you supply a reference.

---

After 38 pages of spec you have just five lines of security
considerations. You don't even mention BGP security directly.

I confess that I don't see anything obvious that is missing, but are
there no specific risks associated with this approach? No amplification
through mcast?