Last Call comments draft-ietf-mpls-seamless-mcast-15.txt

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

As part of my AD review of this document I found a number of small editorial
issues that I am raising now as Last Call comments.

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?

> -----Original Message-----
> From: IETF-Announce [mailto:[e-mail]] On Behalf Of The
> IESG
> Sent: 20 January 2015 01:04
> To: IETF-Announce
> Cc: [e-mail]
> Subject: Last Call: <draft-ietf-mpls-seamless-mcast-15.txt> (Inter-Area P2MP
> Segmented LSPs) to Proposed Standard
> 
> 
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> - 'Inter-Area P2MP Segmented LSPs'
>   <draft-ietf-mpls-seamless-mcast-15.txt> 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
> [e-mail] mailing lists by 2015-02-02. Exceptionally, comments may be
> sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>    This document describes procedures for building inter-area point-to-
>    multipoint (P2MP) segmented service LSPs by partitioning such LSPs
>    into intra-area segments and using BGP as the inter-area routing and
>    label distribution protocol. Within each IGP area the intra-area
>    segments are either carried over intra-area P2MP LSPs, using P2MP LSP
>    hierarchy, or instantiated using ingress replication.  The intra-area
>    P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
>    replication is used within an IGP area, then (multipoint-to-point)
>    LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP
>    area. The applications/services that use such inter-area service LSPs
>    may be BGP Multicast VPN, VPLS multicast, or global table multicast
>    over MPLS.
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast/ballot/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>    http://datatracker.ietf.org/ipr/2047/