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

From: Eric Rosen <[email-masked]>
Date: Thu, 09 Jul 2009 13:06:55 -0400

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.

---

From: Thomas Morin <[email-masked]>
Date: Fri, 10 Jul 2009 19:04:07 +0200

Eric, working group,

Taking a bit perspective, let me try to summarize why we pursue this thread:
- the possible P-tunnel aggregation doable with the segmented inter-AS 
approach is currently *not* mentioned in the document (and thus not a 
"claim" of the document as you suggest below)
- you brought up this point about P-tunnel aggregation and debate on the 
associated scaling benefits, this is indeed an additional potential 
argument for the segmented approach, and thus only tipping the balance 
just slightly further in favor of that approach (thus, not in the 
direction of changing the conclusions)

 From there we have two choices:
a - do not talk about this additional potential advantage of the 
segmented approach
b - talk about it and identify the conditions when it provides an 
advantage for the segmented approach and on what ASBRs need to do for 
this benefit to happen, and evaluate when the advantage is big or small

For sake of completeness, I guess we should go the (b) way and 
consolidate the different observations made to add content in section 3.5.

Other opinions are welcome.

That said, a few elements with reference to the points you brought up:
- on whether or not aggregation benefits S-PMSI: P-tunnel aggregation in 
the segmented approach is not only provided for I-PMSI, but also for 
S-PMSI, and described in section 12.2.1 of draft-ietf-2547bis-mcast-bgp
- on whether or not you can avoid sending traffic uselessly in other 
ASes : this is mentioned in section 9.2.3.6 of 
draft-ietf-2547bis-mcast-bgp (the whole supersection is on I-PMSI route 
processing, but the text in 9.2.3.6 would apply equally well to S-PMSIs, 
possibly an improvement to bring there)
- some other questions you ask me are answered, or should be answered in 
draft-ietf-2547bis-mcast and/or draft-ietf-2547bis-mcast-bgp: if they 
are not, the fix would be supposed to be made there, and not in 
draft-ietf-l3vpn-mvpn-considerations

-Thomas

---

From: Eric Rosen <[email-masked]>
Date: Tue, 14 Jul 2009 12:10:34 -0400

> on whether or not you can avoid sending traffic uselessly [on S-PMSIs] in other 

I thought the policy of the  "considerations" draft was to take account only
of  what is  written  in the  base  specs, not  of "possible  improvements".
Obviously this policy is not being applied in an even-handed manner.  

Even if  we grant that  9.2.3.6 could be  applied to S-PMSIs,  there doesn't
seem to be anything in the  existing specs that prevents an S-PMSI A-D route
from creating intra-AS segments connecting the ASBRs in all ASes of the VPN,
whether or not the multicast flow or flows bound to the PMSI are needed. 

The procedure of 9.2.3.6 allows an ASBR to dynamically create a set of <S,G>
filters for each P-tunnel, based  on the C-multicast routes that are passing
through  the  ASBR.  (This  seems  to  make  certain assumptions  about  the
deployment.)  Then these filters have to be applied to data packets arriving
on  that  P-tunnel.  Creating  LSP  tunnels  that  aren't needed,  and  then
applying IP-based filtering to the  MPLS packets traveling on those tunnels,
does not seem to me to be a particularly good scaling technique.  

But let me guess, S-PMSI scaling is out of scope, right? ;-)

> you brought up this point about P-tunnel aggregation and debate on the 
> argument for the segmented approach

Sure, just  explain how one does  it in practice,  and why it can't  also be
done with the non-segmented approach.

> some other questions you ask me are answered, or should be answered in 
> draft-ietf-2547bis-mcast and/or draft-ietf-2547bis-mcast-bgp

No doubt those issues are all out of scope ;-)

---

From: Thomas Morin <[email-masked]>
Date: Wed, 15 Jul 2009 09:58:44 +0200

Hi Eric, working group,

> Obviously this policy is not being applied in an even-handed manner.

Not at all, my comment that you quote was a contribution to the 
discussion you started about P-tunnel aggregation, which is not yet 
covered by the draft.  If we find that this point has to be covered, 
like for the rest of the document, we'll only talk about stuff that is 
described in WG specifications.

> But let me guess, S-PMSI scaling is out of scope, right? ;-)
[...]
>
> No doubt those issues are all out of scope ;)

As co-editor of the document, I would greatly appreciate if you could 
extend the scope of *your* comments beyond irony and smileys, to include 
constructive and motivated propositions to amend the document.

For what relates to the discussion in this thread (inter-AS and P-tunnel 
aggregation):
- whether you find something in the document that you disagree with ; if 
yes, then please quote and explain what you find incorrect
- or you think that something is missing, and then ideally a 
contribution would be the best, or at least guidelines on what we should 
add along with a rationale on why it is important to cover

Thank you,

-Thomas