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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Eric,

Thanks for your review and comments. Please see below.

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

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.

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

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.

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

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

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