Thank you for your review. I will try to address your technical comments.
Some of your comments are not really technical objections, but criticisms of
the way the document is constructed, or of the scope of the document, or of
the approach adopted by the WG. As the construction of the document is the
result of years of difficult negotiation and careful compromise, I will not
address those issues. Also, I will not attempt to address the
"philosophical issues" having to do with what is and is not a proper use of
BGP.
Pekka> 1) IPv6 support. The spec apparently aims to support both IPv4 and
Pekka> IPv6 because it refers to both in a couple of places. Yet, there
Pekka> is at least one explicit place in the spec (S 7.4.2.2) that's not
Pekka> compatible.
Pekka> I suspect many of the BGP attributes used, possibly
Pekka> also the MCAST-VPN BGP SAFI and others are not IPv6 compatible.
MCAST-VPN BGP SAFI is certainly IPv6 compatible; the details may be found in
draft-ietf-l3vpn-2547bis-mcast-bgp-08.text. Section 4 of that draft
discusses the use of AFI 2 (IPv6) with the MCAST-VPN SAFI, and all talk of
"VPN-IP" routes in that document is meant to indicate either VPN-IPv4 or
VPN-IPv6.
Pekka> At the minimum, the status (intent) of the spec should be
Pekka> clarified. Even better would be to improve and include the support
Pekka> here.
In general, the procedures specified in the document will enable an IPv4 SP
backbone to support customer use of IPv6 multicast. You are correct that
section 7.4.2.2 is incomplete in this respect.
Pekka> 2) RP configuration in SP network. It's not clear if SP network
Pekka> needs to know how customer sites have configured their RPs (when
Pekka> the customer provides the RP). At least traditional PIM
Pekka> signalling would require SP to know this. But if auto-rp or BSR
Pekka> is not used by the customer, how is this information learned and
Pekka> maintained? Would it require manual configuration?
A PE router does function as a PIM peer of a CE router, and hence needs some
way to get the group-to-RP mappings of the customer. How this is done is
for the SP and the customer to determine.
Pekka> 5) Active source BGP messages. This is a duplication of a similar
Pekka> mechanism in MSDP (RFC3618) which has caused much grief in
Pekka> Internet. Does this meant that when a host does 'nmap -sU
Pekka> 224.0.0.0/4' at a VPN site, this will result in about 268 million
Pekka> BGP active source updates being sent (2^28) in the SP backbone?
There are two uses of Source Active routes, described respectively in
sections 9 and 10. As used in section 9, this problem cannot arise because
the SA routes are not generated as the result of receiving data traffic.
The use described in section 10 does however need to be discussed in the
security considerations.
Pekka> This problem is not described in security considerations.
>From the Security Considerations section:
"an implementation SHOULD provide mechanisms that allow a SP to place
limitations on the following:
- total number of (C-*,C-G) and/or (C-S,C-G) states per VRF"
Since SA AD routes are generated only as a result of creating the
corresponding multicast states, limiting the number of multicast states per
VRF results in limiting the number of Source Active routes.
A more specific discussion can be found in the Security Considerations
section of draft-ietf-l3vpn-mcast-bgp:
"In conjunction with the procedures specified in Section "Supporting
PIM-SM without Inter-Site Shared C-trees" an implementation SHOULD
provide capabilities to impose an upper bound on the number of Source
Active A-D routes, as well as on how frequently they may be
originated. This SHOULD be provided on a per PE, per MVPN granularity."
Pekka> 6) PIM-BIDIR usage. May the SP use PIM-BIDIR internally even if the
Pekka> customer interface would use PIM-SM?
I'm not sure I understand exactly what you are asking. The technology for
building the P-tunnels is completely independent of the multicast technology
used by the customer.
Pekka> 7) Type 0 Route Distinguisher. The spec mandates using type 0 RD which
Pekka> embeds 16-bit AS-number.
Good catch. This is actually an error in the spec. The material in section
8.2 reflects some earlier thinking about procedures that were revised and
worked out in more detail in draft-ietf-l3vpn-2547bis-mcast-bgp. What we
will do is eliminate the text in section 8.2 and replace it with a reference
to the mcast-bgp draft.
> 3.2. P-Multicast Service Interfaces (PMSIs)
> Multicast data packets received by a PE over a PE-CE interface must
> be forwarded to one or more of the other PEs in the same MVPN for
> delivery to one or more other CEs.
Pekka> .. is this strictly accurate? doesn't this depend on where the RP is
Pekka> configured to be? This seems to assume that the RP configuration is
Pekka> always provided by the customer, never by SP? Because if RP is
Pekka> provided by the service provider, then the same packets could be
Pekka> forwarded back to the CE, without being forwarded at all to other
Pekka> PEs.
I'm not sure I see what the RP has to do with it, but it would be more
accurate to say "A PE must have the ability to forward multicast data
packets received from a CE to one or more of the other PEs in the same MVPN
for delivery to one or more other CEs."
Pekka> In 3.2,
> - PIM
>
> A PMSI can be instantiated as (a set of) Multicast Distribution
> Trees created by the PIM P-instance ("P-trees").
>
> The multicast distribution trees that instantiate I-PMSIs may be
> either shared trees or source-specific trees.
Pekka> ... I-PMSI with PIM is not really described;
The specification for instantiating PMSIs using the different tunneling
technologies is in section 6.
Pekka> this part only describes S-PMSI's.
I don't know why you think so, that's not the intention.
> FWIW, S5.2 only discusses MI-PMSI
Section 5.2 is about running C-PIM over an MI-PMSI. The material you cite
from section 3.2 is about using P-PIM to create P-tunnels that instantiate
PMSIs. These are different topics.
> 6.4.2 PIM Trees
>
> The RP or RPA
> corresponding to the P-group address is not specified. It must of
> course be known to all the PEs. It is presupposed that the PEs use
> one of the methods for automatically learning the RP-to-group
> correspondences (e.g., Bootstrap Router Protocol [BSR]), or else that
> the correspondence are configured.
Pekka> .. a clarification? Do P or PE routers need to know the RP mappings
Pekka> of C-trees, i.e., when the customer has configured one of its own
Pekka> routers as the RP, does SP need to know the IP address?
Section 6.4.2 is not about C-trees, it's about P-trees ;-)
> 6.4.5 Ingress replication
>
> This draft defines a number of optional procedures which require that
> a tunnel egress, upon receiving a tunnel packet, be able to identify
> the tunnel ingress. Unicast P-tunnel mechanisms which do not provide
> this property (e.g., multi-hop LSPs for which penultimate-hop-popping
> is done) should therefore be used with caution. In particular, such
> mechanisms MUST NOT be used unless either (a) PIM over MI-PMSI is
> being used for distributing PE-PE C-multicast routing information, or
> (b) the procedures of section 9 are being followed.
Pekka> .. who is the target audience of this 'caution' and 'MUST NOT'? An
Pekka> implementer, operator or both? It is not clear enough if this is
Pekka> actionable if it's implementer; it's not clear if this is clear
Pekka> enough if it's the operator.
I have to agree that this is a rather convoluted paragraph. I think the
following rewording may be better:
Section 9.1 specifies three different methods that can be used to prevent
duplication of multicast data packets. Any given deployment must use at
least one of those methods. Note that the method described in section
9.1.1 ("Discarding Packets from the Wrong PE") presupposes that the
egress PE of a P-tunnel can, upon receiving a packet from the P-tunnel,
determine the identity of the PE that transmitted the packet into the
P-tunnel. SPs that use ingress replication to instantiate their PMSIs are
cautioned against the use for this purpose of unicast P-tunnel
technologies that do not allow the egress PE to identify the ingress PE
(e.g., MP2P LSPs, or P2P/P2MP LSPs for which penultimate hop popping is
done). Deployment of ingress replication with such a P-tunnel technology
MUST NOT be done unless it is known that the deployment relies entirely
on the procedures of section 9.1.2 or 9.1.3 for duplicate prevention.
>12.1.2. Encapsulation in IP
>
> IP-in-IP [RFC1853] is also a viable option.
>
Pekka> .. 1853 is informational. RFC2003 is standards track version of
Pekka> IP-in-IP spec.
Fixed.
Pekka> there is no section 12.2.3, what are you referring to?
11.2.3, fixed.
> 12.4.1. MTU (Maximum Transmission Unit)
>
>
> It is the responsibility of the originator of a C-packet to ensure
> that the packet is small enough to reach all of its destinations,
> even when it is encapsulated within IP or GRE.
Pekka> I think you're refererring to the host at a customer site, right?
Pekka> Assigning "responsibility" this way is understandable, but it is in
Pekka> conflict with the IP service model, where the originator has no such
Pekka> responsibility.
That may be true in theory, but in practice the hosts do have this
responsibility.
> Security Considerations:
Pekka> ... what about BGP signalling mechanisms? Which attributes
Pekka> should/could be filtered and how?
This should be covered in the Security Considerations of RFCs 4364 and 4365
(referenced) and draft-ietf-l3vpn-2547bis-mcast-bgp (to which a reference
has been added).
> In particular, an implementation SHOULD provide mechanisms that allow
> a SP to place limitations on the following:
Pekka> ... this list should include the source active A-D routes and similar
Pekka> signalling which is triggered by a host sending into a random group.
Discussed above.
Pekka> editorial
Pekka> ---------
Pekka> In S 2.2.1, the term "C-tree" is introduced without a prior
Pekka> explanation. (An explanation of a kind appears to be in S 3.1)
Explanation added to 2.2.1.
>S 9.1.1
>
> If an I-PMSI is used for carrying the packets, the I-PMSI spans
> multiple ASes, and the I-PMSI is realized via segmented inter-AS
> P-tunnels, if C-S or C-RP is multi-homed to different PEs, as long as
> each such PE is in a different AS, the egress PE can detect duplicate
> traffic as such duplicate traffic will arrive on a different (inter-
> AS) P-tunnel.
Pekka> .. I had difficulties following this pretty long sentence, break it up?
How about:
Consider the case of an I-PMSI that spans multiple ASes and that is
instantiated by segmented Inter-AS P-tunnels. Suppose it is carrying
data this is traveling along a particular C-tree. Suppose also that
the C-root of that C-tree is multi-homed to two or more PEs, and that
each such PE is in a different AS than the others. Then if there is
any duplicate traffic, the duplicates will arrive on a different
P-tunnel.
> 12.2.2. Encapsulation in IP
> Rather than the IP-in-IP encapsulation discussed in section 12.1.2,
> we use the MPLS-in-IP encapsulation. This is specified in [MPLS-IP].
> The IP protocol number MUST be set to the value identifying the
> payload as an MPLS unicast packet. (There is no "MPLS multicast
> packet" protocol number.)
Pekka> .. the IANA registry only seems to have "MPLS-in-IP" (value 137). Is
Pekka> this the one? Given that 'unicast' is not mentioned in the registry,
Pekka> should you just say "MPLS-in-IP" and/or the decimal value here?
I think the cited text is necessary for clarity if someone actually reads
[MPLS-IP] rather than just looking at the IANA page.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf