Eric, Thanks for your review and comments. Please see below.
> -----Original Message----- > From: Eric Rosen [mailto:[email protected]] > 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
