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:ietf-announce-bounces(_at_)ietf(_dot_)org] On
Behalf Of The
IESG
Sent: 20 January 2015 01:04
To: IETF-Announce
Cc: mpls(_at_)ietf(_dot_)org
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
ietf(_at_)ietf(_dot_)org mailing lists by 2015-02-02. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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/