Re: draft-ietf-l3vpn-mvpn-considerations-05 / Appendix A / ASM

[Thomas Morin <[e-mail]>]

Eric, working group,

Eric Rosen:
 >
 > Another methodological error is the fact that the analysis focuses 
heavily
 > on the Source-Specific Multicast mode,
[...]

You made this comment in June, and the document has since precisely been 
revised to cover ASM (section A.1.2).
Still claiming that "the analysis focuses heavily on the Source-Specific 
Multicast mode" is just misleading.

The only reason why A.1.2 (on ASM) it is smaller than A.1.1 (on SSM) is 
because it avoids being redundant, for the portion of the procedures for 
the setup and maintenance of one (S,G) SPT state or one (*,G), that are 
common with one (S,G) SSM state.


 > [...] To support the recommendations of section
 > 3.3, the analysis needs to focus on scenarios that relevant to actual
 > deployments. Some of the analysis of SSM also applies to the ASM 
procedures
 > for joining/pruning source trees, but this is not made clear, and it's
 > difficult for a reader to know how much of the analysis is relevant to
 > actual deployments.

I think that the introduction of A.1.2 is clear on this:

   PEs will generally have to maintain one shared tree, plus one source
   tree for each source sending toward G; each tree resulting in an
   amount of processing and state maintenance similar to what is
   described in the scenario in Appendix A.1.1,

We can make it even clearer by adding :
- in the start of section A.1.2 (ASM):

      The conclusion in A.1.1 are reused in this section, for the parts 
that are
      common to the setup and maintenance of states related to a source 
tree
      or a shared tree.

- in the introduction of section A.1.1 (on SSM):

       For all options provided for C-multicast routing, the procedures 
to setup
       and maintain a shortest path tree toward the source of an SSM 
group are
       the same than the procedures used to setup and maintain a 
shortest path
       tree toward an RP or a non-SSM source ; the results of this 
section are
       thus re-used in section A.1.2.



 >
 > [...] In addition to the time spent on the virtually irrelevant SSM 
scenario, [...]
 >

This statement looks to me as totally abusive:
- SSM by itself is certainly not an "irrelevant scenario" ; 
one-to-many-receivers applications certainly are part the applications 
of enterprise VPN customers (look at section 4.1 and 4.1.1 of RFC4834) ; 
at the very least you'd need to support such a claim with actual data...
- as explained above, many results from the SSM case are reused in the 
ASM case, the behavior related to the maintenance of a tree on the the 
shortest path to a source or RP being common

So, this "time" is not spent unwisely...


 >
 > Now let's look specifically at the ASM case.
 >
 > One of the features of the BGP solution is that there is no way, in BGP,
 > to represent the PIM operation of "prune source S off the (*,G) tree".
 > To compensate for this, every PE in a given VPN is forced to keep 
track of
 > every (S,G) stream for which any PE in that VPN has receivers.  This 
is done
 > by means of the Source Active A-D routes.
 >
 > There are two options that can be used.  In one option, where "inter-site
 > shared trees are not used", each PE functions as a C-RP, and then all 
the PE
 > of a given VPN must exchange information on all the (S,G) streams 
that they
 > see locally.  This option uses BGP to do something that is very 
similar to
 > what MSDP is used for today.  Let me quote from Pekka Savola's review of
 > this procedure:
 >
 >          Active source BGP messages.  This is a duplication of a
 >          similar mechanism in MSDP (RFC3618) which has caused
 >          much grief in Internet.  Does this meant that when a
 >          host does 'nmap -sU 224.0.0.0/4' at a VPN site, this
 >          will result in about 268 million BGP active source
 >          updates being sent (2^28) in the SP backbone?
 >
 > The only answer to this was to beef up the Security Considerations with
 > some required procedures that will prevent the PE from melting down 
entirely
 > in this case.  Of course, Appendix A's methodology of only considering a
 > single (S,G) prevents it from seeing that this particular BGP option
 > uses a mechanism whose scalability is already known to be poor and which
 > the multicast WGs have decided not even to bring forward to IPv6.

Let me note that the potential security issues of this way of supporting 
ASM with BGP-based C-multicast routing, is one of the reasons identified 
in section 4 of the document that lead us to make the recommendation 
that this approach should not be the only one implemented.

Do you want us to remind this in Appendix A.1.2 ?

( The other claim you have that the scaling analysis in Appendix A 
should be extended to look at more than a single (S,G) : I will address 
this in a separate email. )



 > In the other, more sensible option, a PE originates a Source Active A-D
 > route for an (S,G) only when it receives a C-multicast Join route for 
that
 > (S,G).  However, the Source Active A-D route goes to all the PEs in 
the VPN,
 > not just to those that have receivers for that (S,G).  I believe this 
means
 > that the amount of state a given PE maintains in the BGP scheme is
 > proportional to the number of (S,G) flows for which any PE in the VPN has
 > receivers.  Actually, since the SA route contains the RD of the 
originating
 > PE, the situation is a bit worse; if (S,G) traffic is sent over the 
backbone
 > by more than one PE, the other PEs in the same VPN must maintain an 
(S,G) SA
 > A-D route for each such PE.
 >
 > In the BGP solution, even if a PE has only (*,G) receivers, or even if it
 > has no receivers for G at all, it must maintain state for all the 
(S,G)s in
 > the MVPN, multiplied by the average number of upstream PEs per source.


You are correct that for each source sending to a group, there may be 
one S-A A-D route per PE upstream for this source.

I will update the text accordingly.

Let's also note that this won't change the orders of magnitude.

(What you say in the rest of your comment is already mentioned in A.1.2.)




 > Strangely, this scaling issue is considered to be insignificant by 
Appendix
 > A, for the following reasons:


Your claim that this scaling issue would be "considered insignificant" 
is not supported.  Your "following reasons" is only followed by stuff 
related to PIM, and I find nothing in A.1.2 indicating we would downplay 
the dependency of BGP of the number of sources  (and not either for PIM 
actually).



 >
 >         when PIM-based C-multicast routing is used there are
 >         ... possible control plane state transitions triggered by
 >         the reception of (S,G) packets ; such events would induce
 >         processing on all PEs joined to G
 >
 > Control plane state transitions triggered by the reception of data 
packets
 > have not even been mentioned to this point, and no analysis has been 
given
 > to show whether or not they cause a scaling issue, or whether any such
 > scaling issue is mitigated by the use of BGP.  I also really don't 
see what
 > this has to do with the issue at hand, namely the added state overhead of
 > the Source Active A-D routes.


When saying "I also really don't see what this has to do with the issue 
at hand" and mentioning Source Active A-D routes you are attempting to 
redefine the scope of the section you comment.

To avoid confusion, I will address your claims on the overhead of 
per-source routes or messages in a separate message.


 > Certainly there is no analysis provided that
 > would show the SA A-D routes trade off in a favorable manner against the
 > data-driven state changes.
 >
 >       when PIM-based C-multicast routing is used there are ...
 >       possible PIM Assert messages specific to (S,G) ; this would
 >       induce a message processing on each PE of the VPN for each
 >       PIM Assert message
 >
 > It is true that the Source Active A-D routes eliminate the need for 
Assert
 > messages.  The implication is that this is favorable for BGP; 
however, there
 > does not appear to be any analysis showing that.


I don't share with you that what we state implies that the comparison 
with the corresponding mechanisms in PIM would be "favorable for BGP".

The goal for this section is to thoroughly assess the load put on BGP or 
PIM as C-multicast routing protocols in the ASM case.

The hard part is to find a way to compare very distinct mechanisms in 
PIM and BGP (as you said, one relies on dataplane driven events where 
the other does not, and one relies on an Assert mechanisms where the 
other does not, and one does not rely on BGP S-A A-D messages where the 
other does not). And the key is to get something meaningful in the 
context of A.1 (scalability wrt. number of PEs) taking into account the 
mechanisms in play for both PIM and BGP protocols, with hypothesis that 
are relevant for an operator trying to choose between the two.

I think that the section properly explains why the orders of magnitude 
for a increased number of PEs are essentially the same for ASM than the 
one found for SSM.

That said, precise suggestions to amend this subsection are still welcome.

( However, note that we would be wrong to give too much weight to the 
scenario your focus on right above ("if a PE has only (*,G) receivers, 
or if it has no receivers for G at all") as it is not that useful for an 
operator willing chose a C-multicast routing option for a deployment, 
and looking at the PE-PE scalability and dimensioning aspect of the 
issue, because you cannot count on some PEs on the MVPN not having  
(*,G) state or having (*,G) state but no (S,G) state, since this depends 
on customer multicast policy and activity.  )


 > The new material on ASM does not appear to contain any analysis at 
all, just
 > unsupported assertions.

I don't think this is true, and your comments certainly don't support 
this claim.
(But without anything more explicit from you, your claim is just not 
refutable...)

That said, we can possibly make A.1.2 better, and all suggestions are 
welcome.
(easier if we don't get an artificial 6 month delay before we get some 
usable feedback)

-Thomas