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

From: Eric Rosen <[email-masked]>
Date: Fri, 17 May 2013 10:48:57 -0400

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.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 30 May 2013 18:35:47 +0000

Eric,

Thanks for your review and comments. Please see below.

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, May 17, 2013 10:49 AM
> To: L3VPN
> Subject: Comments on draft-jain-mvpn-bgp-sitetype-attribute-00.txt
> 
> 
> 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.

We will clarify all that.

> 
> 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".

Yes only "sender only" is really needed, and others will be removed.

> 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.

That is at the cost of extra (C-*,C-*) S-PMSI and corresponding Leaf A-D routes. With just a simple additional sender-only attribute, the same result can be achieved w/o the need of (C-*,C-*) S-PMSI and corresponding Leaf A-D routes.

> have interest in any C-flow from any of VRF2's senders.

That's a argument for I-PMSI vs. (C-*,C-*) S-PMSI. The context of this proposal is that I-PMSI is used anyway (e.g., non-segmented inter-as provider tunnel) - you can simply use the new attribute.

> If the goal is to

In case of Ingress Replication, there is no core state anyway and the saving is on the (C-*,C-*) S-PMSI AD and corresponding Leaf-AD route.

Thanks.

Jeffrey