Subject: Re: Last Call: draft-ietf-l3vpn-2547bis-mcast (Multicast in MPLS/BGP IP VPNs) to Proposed Standard

From: Eric Rosen <[email-masked]>
Date: Mon, 19 Oct 2009 10:44:52 -0400

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.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Oct 2009 09:31:40 +0300 (EEST)

I'll only comment on a couple of followups below. I think I've 
described my POV and I probably won't do further follow-ups.

> section 7.4.2.2 is incomplete in this respect.

Do you intend to correct this?  One could argue that this does not 
fulfill the requirements for PS as it stands.

> for the SP and the customer to determine.

Do you intend to spell this out more clearly?  This seems like a major 
configuration and O&M issue?  Unfortunately this does not have good 
solutions, and I suppose those ones that do exist do not have rough 
consensus in the community.  As it stands it seems like the spec chose 
to punt an issue that is required to be resolved in order to operate 
the protocol.

> VRF results in limiting the number of Source Active routes.

I may be missing something but it's not clear why you say so.  At 
least in regular PIM-SM, source state can be created without creating 
receiver state.  S 10.1.2.2 seems to imply that AD routes would be 
generated based on the receipt of Register messages, at which point 
there is not yet necessarily any join state.

>   originated. This SHOULD be provided on a per PE, per MVPN granularity."

While this is on a different spec, experience with MSDP has shown that 
SHOULD is insufficient; these requirements are a MUST from O&M 
perspective.

> building the P-tunnels is completely independent of the multicast technology

Ok, that is what I wanted to hear.  Maybe it was clear enough but I 
wasn't 100% sure.

> for delivery to one or more other CEs."

Agreed.  This underlines the need for "ability", not that it actually 
happens.  I was referring to the degenerate case where all MVPN's 
sources and receivers would (at that point in time) happen to be 
behind the same PE.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings