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

[Eric Rosen <[e-mail]>]

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

In the case of Ingress Replication, the Leaf A-D routes are very useful, as
they allow an egress PE to assign distinct MPLS labels for each ingress PE.
This in turn allows the egress PE to apply the "discard packets from the
wrong PE" procedure of RFC6513 section 9.1.1.

So the draft should point out that the sender-only attribute is only useful
with Ingress Replication in deployments where Single Forwarder Selection is
used.

Jeffrey> In case of Ingress Replication, there is no core state

Section 3 of the draft talks about P-tunnels causing "unnecessary
control plane states in the core", and doesn't make clear that that applies
only to RSVP-TE P2MP P-tunnels.

Eric> Note that if VRF2 is attached to a site with senders, the procedures
Eric> in the draft will add VRF1 to the P-tunnel rooted at VRF2 even if VRF1
Eric> does not have interest in any C-flow from any of VRF2's senders.

Jeffrey> That's a argument for I-PMSI vs. (C-*,C-*) S-PMSI. The context of
Jeffrey> this proposal is that I-PMSI is used anyway

The draft (in section 1) provides two reasons for using the sender-only
attribute:

   o  to reduce unnecessary RSVP control plane states in the network

   o  to reduce inefficient network resource utilization.

The (C-*,C-*) S-PMSI scheme does a better job of addressing these issues.
By the criteria that the draft itself sets out, the solution proposed in the
draft is not as good as the existing (C-*,C-*) S-PMSI solution.  

Perhaps the draft should just position itself as a simpler but less optimal
technique that might be useful in certain deployments.