Comments on draft-jain-mvpn-bgp-sitetype-attribute-00.txt

[Eric Rosen <[e-mail]>]

I have a few comments on draft-jain-mvpn-bgp-sitetype-attribute-00.txt.

This draft seems to assume the following combination of circumstances:

1. Each VRF of a given MVPN originates an Intra-AS I-PMSI A-D route.

2. Each such route contains a PMSI Tunnel attribute specifying a tunnel of
   type "RSVP-TE P2MP LSP" or of type "Ingress Replication".

3. Some of the VRFs are connected only to sites that have multicast senders
   but no multicast receivers.  (It is not clear from the draft whether this
   is supposed to be known by provisioning, or learned dynamically.)

According to the procedures of RFC6514, each such VRF will become the root
of an inclusive P-tunnel (e.g.,an RSVP-TE P2MP LSP), and will add the other
VRFs as leaf nodes.  This draft proposes that if a VRF, say VRF1, has no
receivers, it should add a "sender-only attribute" to its Intra-AS I-PMSI
A-D route.  Then if another VRF, say VRF2, imports VRF1's Intra-AS I-PMSI
A-D route, VRF2 will know not to add VRF1 to the inclusive P-tunnel of which
VRF2 is the root.

The draft does not actually point out that its applicability is limited to
the case where the tunnel type is RSVP-TE or Ingress Replication, but its
procedures do not make any sense otherwise.  The draft also fails to point
out that its applicability is restricted to the case where the inclusive
P-tunnels are not segmented, though this may be inferred from the fact that
there are no procedures given for Inter-AS I-PMSI A-D routes.  The draft
also needs to point out that its procedures will not work properly if PIM is
the C-multicast protocol.

The proposed new attribute has three values ("sender only", "receiver only",
"both"), and lots of extra bits, but as far as I can tell the attribute has
no effect at all unless it is set to "sender only".

In any event, I don't believe this mechanism is needed, as the problem
addressed by the draft can already be solved, using the existing standards,
as follows:

- All VRFs originate the Intra-AS I-PMSI A-D routes without including a PMSI
  Tunnel attribute.

- All VRFs attached to sites with senders Originate a (C-*,C-*) S-PMSI A-D
  route (RFC6625) with a PMSI Tunnel Attribute.  (VRFs attached to sites
  without senders should not originate the wildcard route.)

Then the existing procedures from RFCs 6514 and 6625 already ensure that
VRF1 will not get added to a P-tunnel rooted at VRF2 unless VRF1 actually
has interest in a C-flow from VRF2.  Problem solved, no new standards
needed.

Note that if VRF2 is attached to a site with senders, the procedures in the
draft will add VRF1 to the P-tunnel rooted at VRF2 even if VRF1 does not
have interest in any C-flow from any of VRF2's senders.  If the goal is to
optimize the amount of tunnel state in the core, the use of the wildcard
S-PMSI is more optimal than the procedures proposed in the draft.