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

From: Eric Rosen <[email-masked]>
Date: Mon, 15 Jun 2009 10:36:15 -0400

In  the  discussion  of inter-AS,  I  think  the  draft should  discuss  the
following issues:

- In  order to  use the  segmented inter-AS  procedures, each  ASBR  must be
  pre-configured with the  MVPNs whose trees pass through  it.  (See section
  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)

- One of the most important scaling properties, that of making the number of
  P-tunnels be independent  of the number of PEs in other  ASes, may be more
  theoretical than real,  at least in the shorter  term.  A segmented S-PMSI
  carries traffic from only one PE, so the number of S-PMSIs used by an MVPN
  is still limited only by the total number of PEs in the MVPN.

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

These issues  seem relevant  to a discussion  of whether  segmented inter-AS
P-tunnels should be mandatory.

---

From: Thomas Morin <[email-masked]>
Date: Fri, 19 Jun 2009 18:01:58 +0200

Hi Eric, folks,

>   8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)
If this is true that it has to be pre-configured and that 
auto-configuration is precluded for some reason, we can mention this 
point in the comparison.

(I don't think that would cancel the advantages of the segmented 
approach, though)

>   is still limited only by the total number of PEs in the MVPN.
I don't get your point:
- without considering S-PMSIs, there is already a big scaling advantage 
compared to the non-segmented approach (number of I-PMSI tunnels in an 
AS independent of the number of PEs in the remote ASes)
- your sentence about S-PMSI is strange : since when "the number of 
S-PMSIs used by an MVPN"
would be limited "by the total number of PEs in the MVPN" ? Whatever the 
choice of segmented vs non-segmented, and even in intra-AS, there is no 
such limitation, the only limit is virtually the number of C-multicast 
streams... (???)
>   upstream-assigned labels.
I think that these are two bogus claims:
- aggregation of multiple tunnels into one tunnel does not require 
upstream assigned labels, except possibly if the tunnels are shared 
between distinct VPNs, but in that case you need upstream assigned 
labels even in intra-AS, without even considering 
segmented/non-segmented or aggregation
- it doesn't seem to me that something would preclude automation of the 
merging, this is a purely local decision matter   (you could also say 
that there is no spec of a method for deciding to put traffic on an 
S-PMSI; but that wouldn't be relevant, even though strictly speaking true)

-Thomas

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 23 Jun 2009 05:59:08 -0700

Eric,

>  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast.)

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

Here are the relevant quotes:

>From  8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast-08.txt:

      a. A Route Distinguisher for the MVPN. For a given MVPN each ASBR
         in the AS must use the same RD when advertising this
         information to other ASBRs. To accomplish this all the ASBRs
         within that AS, that are configured to support the MVPN, MUST
         be configured with the same RD for that MVPN. This RD MUST be
         of Type 0, MUST embed the autonomous system number of the AS.

>From 9.2.1 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt:

     + The route carries a single MCAST-VPN NLRI with the RD set to the
       RD configured for that MVPN on the ASBR, and the Source AS set to
       the Autonomous System number of the ASBR.

>From 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt:

     + If the ASBR originates an Inter-AS I-PMSI A-D route for a
       particular MVPN present on some of the PEs within its own AS, the
       ASBR MUST be (auto-)configured with an RD for that MVPN. It is
       RECOMMENDED that one of the following two options be used:

       (1) To allow more aggregation of Inter-AS I-PMSI A-D routes it is
       recommended that all the ASBRs within an AS that are configured
       to originate an Inter-AS I-PMSI A-D route for a particular MVPN
       be configured with the same RD (although for a given MVPN each AS
       may assign this RD on its own, without coordination with other
       ASes).

       (2) To allow more control over spreading MVPN traffic among
       multiple ASBRs within a given AS it is recommended for each ASBR
       to have a distinct RD per each MVPN, in which case such an RD
       SHOULD be auto-configured.

With all the above in mind it is clear that the only item that
involves configuration on ASBRs is the RD. With this in mind let's
look at the issue of configuring RDs on ASBRs.

>From the above quotes it should be clear that section 8.2.1.1 of
draft-ietf-l3vpn-2547bis-mcast-08.txt that you referred to in your
e-mail is at best incomplete (and at worse incorrect), as it only
covers option (1) from 9.2 of draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt,
but does *NOT* cover option (2). While option (1) does involve
configuring RDs, option (2) explicitly states that RDs "SHOULD be
auto-configured."

Thus, your claim above that "ASBR  must be pre-configured with the
MVPNs whose trees pass through it" totally ignores the fact that
it applies only to one particular option (option (1) above). Your
claim is *incorrect* in the context of option (2). What is correct
though is that section 8.2.1.1 that you refers to is incomplete/incorrect.

Yakov.

---

From: Thomas Morin <[email-masked]>
Date: Tue, 23 Jun 2009 17:53:43 +0200

Yakov, Eric, folks,

Ok, so if I understand correctly, with for inter-AS segmented approach 
we have:
- option (1), which requires pre-configuration, and allows the highest 
level of aggregation (one tunnel per source AS per mVPN)
- option (2), that does not require pre-configuration (and in fact for 
which autoconfig is recommended), and that allows aggregation to some 
degree (one tunnel per mVPN per ASBR per source AS)
And for the non-segmented approach: no pre-configuration is required in 
any case, and no aggregation is possible (one tunnel per source PE  per 
mVPN).

My take would be as follows:
- we can certainly add the requested precision into the draft on how 
pre-config is needed to have the maximum level of aggregation
- since pre-config is not needed for option (2) which still allows a 
level of aggregation of an order of magnitude higher than the 
non-segmented approach, I don't think that we have rationale to change 
the conclusions of the section (the weight of the updated point is still 
significant in the comparison, and its only one among others)

Feedback is welcome,

-Thomas

(PS: is there some way section 8.2.1.1 of draft-ietf-l3vpn-2547bis-mcast 
can be updated ?)