Re: LC comment on "considerations" inter-AS section

[Eric Rosen <erosen at cisco.com>]

Thomas> without considering S-PMSIs, there is already a big scaling
Thomas> advantage compared to the non-segmented approach (number of I-PMSI
Thomas> tunnels in an AS independent of the number of PEs in the remote
Thomas> ASes)

If one is using one of the options that does not use I-PMSIs, this "big
scaling advantage" disappears entirely.  So if this is your main basis for
requiring segmented P-tunnels, the requirement should be restricted to
deployments that use I-PMSIs.

By the way, can you explain how, if you use segmented I-PMSIs, you apply the
procedures of section 9.1.1 of draft-ietf-l3vpn-mcast-08?

Eric> A segmented S-PMSI carries traffic from only one PE, so the number of
Eric> S-PMSIs used by an MVPN is still limited only by the total number of
Eric> PEs in the MVPN.

Thomas> the only limit is virtually the number of C-multicast streams.

I was assuming that all the streams from a given PE/MVPN would be
aggregated, but you are correct to point out that that is not necessarily
the case.  This just further supports my point, the segmented inter-AS
P-tunnel scheme does not provide any scalability advantage for S-PMSIs.

Thomas> aggregation of multiple tunnels into one tunnel does not require 
Thomas> upstream assigned labels, except possibly if the tunnels are shared 
Thomas> between distinct VPNs

If a number of tunnels (even from the same VPN) are aggregated into a single
tunnel when going from the entry ASBR to the exit ASBR of a given AS, please
explain how the tunnels are deaggregated at the exit ASBR.

In the case of S-PMSIs traversing an intermediate transit AS, an entry ASBR
might want to aggregate all the S-PMSIs of a given MVPN into a single
P-tunnel that reaches a set of exit ASBRs.  However, that should not require
each exit ASBR in the set to forward all the traffic of all the S-PMSIs.
After all, a given S-PMSI might not have receivers downstream of a given
exit ASBR.

(Actually, it is not completely clear to me that the spec for segmented
S-PMSIs gives you a way to prevent the S-PMSI's data packets from going to
each AS containing its MVPN, even in the absence of aggregation, whether or
not that AS has any receivers for those data packets.  However, that would
seem to be a desirable, even essential, feature, that might be a valid
"consideration".)

Eric> To get the desired scaling improvement, one must aggregate a number of
Eric> intra-AS segments of inter-AS tunnels into a single intra-AS P-tunnel.
Eric> I don't believe there is a specification of the method for doing this
Eric> in a fully automated fashion.

Thomas> you could also say that there is no spec of a method for deciding to
Thomas> put traffic on an S-PMSI; but that wouldn't be relevant

Indeed, that wouldn't be relevant, so I'm not sure why you brought it up.

Thomas> it doesn't seem to me that something would preclude automation of
Thomas> the merging, this is a purely local decision matter 

The point is that there are scalability claims that are purely theoretical,
in that is it not actually known how to achieve them.  This seems like
something worth mentioning when lauding the alleged scalability of a
particular scheme.

Yakov> Let's examine your claim that "in order to use the segmented inter-AS
Yakov> procedures, each ASBR must be preconfigured with the MVPNs whose
Yakov> trees pass through it". 

Yakov> it is clear that the only item that involves configuration on ASBRs
Yakov> is the RD

The configuration in question is the association of an RD with a particular
MVPN.  The spec doesn't say exactly how you do this, presumably it means
providing an RD and then providing a list of RTs, such that, by default at
least, the RD is to be used when an Inter-AS I-PMSI A-D route aggregates a
set of Intra-AS I-PMSI A-D routes that each carry that exact set of RTs.

Yakov> your claim above that "ASBR must be pre-configured with the
Yakov> MVPNs whose trees pass through it" totally ignores the fact that
Yakov> it applies only to one particular option (option (1) above). Your
Yakov> claim is *incorrect* in the context of option (2).

I stand corrected, there is indeed an option that does not require the
above-mentioned configuration on each ASBR.  When that option is used,
multiple non-comparable Inter-AS I-PMSI A-D routes may be advertised for a
given I-PMSI, which would lead to the use of multiple P-tunnels for that
I-PMSI.  So the correct statement would be:  "the goal of having a single
Inter-AS I-PMSI A-D route per MVPN per source AS cannot be met without
preconfiguring the ASBRs".  I think the corrected statement should be
mentioned in any discussion of the scalability of the segmented P-tunnel
scheme.

Yakov> What is correct though is that  section 8.2.1.1 that you refer to is
Yakov> incomplete/incorrect. 

It's hard to believe this wasn't picked up during the extensive review that
the docs got during last call.  Certainly this needs to be fixed.  I'll see
if we can get the co-authors to agree on some replacement text.

BTW, speaking of things that should have been picked up during last call,
section 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07 is a bit confusing, as
it does contain the statement:

       "An ASBR MUST be configured with a set of (import) Route Targets
       (RTs) that specifies the set of MVPNs supported by the ASBR."

This could easily be interpreted as meaning that an ASBR must be configured
with a set or RTs specifying the set of MVPNs supported by the ASBR ;-)
Later in the paragraph it says:

       "instead of being configured, the ASBR MAY obtain this set of
       (import) Route Targets (RTs) by using Route Target Constrain"

I think the intention is probably that the ASBR MUST be configurable with
the abovementioned set of RTs, but that configuration of the RTs is only
required if RT Constrain has not been deployed for those RTs.  If that is
the actual intention, it should be stated more clearly.  There are other
paragraphs in that section that use the term "(auto-)configured", and do not
make it very clear as to just what the conditions are under which explicit
configuration is required.  This should be taken into account by the
"considerations" document.

Also, the following two paragraphs of section 9.2.1 of mcast-bgp-07 would
seem to be worth noting in the "considerations" draft:

     + The default policy for aggregation of Intra-AS I-PMSI A-D routes
       into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI
       A-D route aggregates only the Intra-AS I-PMSI A-D routes that
       carry exactly the same set of RTs (note that this set may have
       just one RT). In this case an Inter-AS I-PMSI A-D route
       originated by an ASBR carries exactly the same RT(s) as the RT(s)
       carried by the Intra-AS I-PMSI A-D routes that the ASBR
       aggregates into that Inter-AS I-PMSI A-D route. An implementation
       MUST support the default policy for aggregation of Intra-AS I-
       PMSI A-D routes into an Inter-AS I-PMSI A-D route.

     + The default policy for aggregation could be modified via
       configuration on the ASBR. An implementation MAY support such
       functionality.  Modified policy MUST include rules for
       constructing RTs carried by the Inter-AS I-PMSI A-D routes
       originated by the ASBR.

I think this means the following: if the Intra-AS I-PMSI A-D routes of a
given MVPN do not all have exactly the same set of RTs, then the ASBRs must
be explicitly configured with the "modified policy" for that MVPN.  So if
there are Inter-AS extranets, Inter-AS Hub and Spoke MVPNS, or any Inter-AS
"non-vanilla" MVPNs, explicit configuration on the ASBRs is required for
segmented P-tunnels but not for unsegmented P-tunnels.  This also seems like
something worth noting in the "considerations" draft.