[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 ?)


Yakov Rekhter wrote:
Eric,

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.)
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.