Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 13 Apr 2011 18:37:04 +0100

L3VPNers & IDRers,

This e-mail is the start of a joint L3VPN & IDR WG Last Call for draft-ietf-l3vpn-ibgp-02.

Feedback should be provided to the mailing list(s) and/or the authors.

The Last Call ends midnight PDT 27th April 2011.

You can view the draft here:
http://tools.ietf.org/id/draft-ietf-l3vpn-ibgp-02.txt

Thanks
Ben (on behalf of the L3VPN & IDR chairs)

---

From: <[email-masked]>
Date: Tue, 26 Apr 2011 18:37:00 +0200

Hi Pedro, all,

1) May be some additional text discussing the interaction with inter-AS
option A could be useful. E.g.:
	- I guess both VPN SP should now configure the customer AS on
their ASBR (instead of their own AS number). Or maybe this depend on
whether both ASes support this extension.
	- how SP load balancing between multiple ASBRs is affected
(given that SP LOCAL_PREF is not used anymore by ingress PE)

2) "In all cases where a route containing the ATTR_SET attribute is
   imported, attributes present on the VPN route other than the NEXT_HOP
   attribute are ignored, both from the point of view of route selection
   in the VRF Adj-RIB-in and route advertisement to a CE router. "

The document mostly talks about PE. Could the document explicitly define
how the ATTR_SET attribute is handled by VPN Route Reflector and ASBR
option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR
option B ?

3) In section 8 "Deployment considerations", IMHO it could be helpful
for SP readers to indicate that in a given VPN, some sites can use iBGP
while other sites can use eBGP. 

Thanks,
Best regards,
Bruno

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Niven-Jenkins
> Sent: Wednesday, April 13, 2011 7:37 PM
> To: [email-masked]; [email-masked]
> Subject: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
> 
> L3VPNers & IDRers,
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Pedro Marques <[email-masked]>
Date: Tue, 26 Apr 2011 10:25:19 -0700

Bruno,
Answers inline.

> whether both ASes support this extension.

I'm not sure Inter-AS option A is relevant to this document. By
definition option The document doesn't propose any modification in
operation of option A.
It does define procedures of how routes from a VRF in the customer AS
interops with a VRF in the SP AS, such as the ones used in option A.

> (given that SP LOCAL_PREF is not used anymore by ingress PE)

The ATTR_SET attribute allows a solution to preserve the customer
LOCAL_PREF; it doesn't and shouldn't (imho) prescribe policy
mechanisms that may overwrite that LOCAL_PREF.

The ATTR_SET attribute along with the ability of running VRFs on
different ASes (e.g. the customer AS) are intended to address a
particular set of scenarios which tend to be disjoint, as far as i
know, from the scenarios where option A is used.

The first is intended to allow customer managed inter-as route
exchanges, while the later is a provider managed solution. They should
inter-operate but not necessarily overlap for the same customer.

Unless you do have a scenario in mind where it would be helpful to use
ATTR_SET for SP managed inter-as with option A.... If so please
describe the issue you are trying to address. I'd be more than happy
to try to make the mechanism more useful but at the moment i'm not
aware of an application.

The only scenario i can think of is one where a provider is internally
using multiple ASes and would like to make that irrelevant to the
customer; but in that scenario option A has a significant number of
issues which are beyond the scope of what we can address with this
document, imho. By the time one addresses these you get option B, for
which this document is relevant.

> option B? e.g. ATTR_SET is not to be considered by VPN RR and ASBR

The ATTR_SET attribute is transparent to VPN Route Reflectors and ASBRs.

> while other sites can use eBGP.

They could as a transition mechanism, specially. Section 7 describes
how this would work from a protocol standpoint.

If you have concrete applications, i'd be happy to highlight them. In
abstract i'm not sure that we would be adding value just by stating
that one could have both iBGP (in customer-as VRFs) and eBGP (in
provider-as VRFs) without the context of "why would that be a good
idea ?"...

---

From: <[email-masked]>
Date: Wed, 27 Apr 2011 11:21:47 +0200

Pedro,

Thanks for your answer. Comments inline.

> definition option The document doesn't propose any modification in

How do you handle the following topology: ?

AS1 |    AS10     |    AS11     | AS1
CE1---PE1---ASBR1---ASBR2---PE2---CE2	

CE1-PE1 and CE2-PE2 are iBGP sessions.
ASBR1 use inter AS option A. Should they use an iBGP session compliant with this document or a regular eBGP session? In the latter case, the ATTR_SET attribute will be dropped by ASBR and hence will not be propagated from PE1 to PE2.

> LOCAL_PREF;

Ok for the preservation. But in my understanding it goes beyond preservation:
 
" In all cases where a route containing the ATTR_SET attribute is
   imported, attributes present on the VPN route other than the NEXT_HOP
   attribute are ignored, both from the point of view of route selection
   in the VRF Adj-RIB-in and route advertisement to a CE router.  In
   order words, the information contained in ATTR_SET attribute
   overrides the VPN route attributes on "vrf-import". "

I read that the PE does not use the VPN/SP LOCAL_PREF but the customer one. Hence a SP could not influence the load balancing across its ASBR option B.

> it doesn't and shouldn't (imho) prescribe policy

Let's take a SP A that cooperates with SP B to increase the geographic coverage of its VPN service (in a cost effective way given that the low demand in this location does not justify extending the VPN network of SP A). SPs uses inter AS option A.

Now a customer VPN having sites connected in both SP ask for iBGP session between PE and CE.

> They could as a transition mechanism, specially. 

If you restrict this to a transition mechanism, should I understand that you do not recommend that a VPN has both a set of sites in one AS using iBGP and some other sites (in a different AS) using eBGP?

> provider-as VRFs) without the context of "why would that be a good

As for the concrete application, I guess we could have a VPN customer with multiple CE/site in one AS numbers but yet some other sites in a different AS number. E.g. sites A1...Ai in AS A and sites B1...Bj in AS B. Can a SP put all these VPN sites in the same VPN and the VPN network will transparently handle this case? (i.e. interconnect Ai & Aj using iBGP, interconnect Bi & Bj using iBGP, while interconnect Ai & Bi using eBGP). Or should this be avoided? Or do we need anything special (config / additional gateway) to handle this?
Any answer (yes/ no / yes with X) is fine. The goal of the text is simply to make it clear for SP whether such topology is in scope of the document or not. (currently I believe it is not in scope)

> Section 7 describes

"The desired result, in such a scenario is to present the internal
   peer (CE3) with a BGP advertisement that contains the same BGP Path
   Attributes received from CE1 and to the external peer (CE 2) a BGP
   advertisement that would correspond to a situation where AS 1 and 2
   have an external BGP session between them."

I agree that this is the desired result. The question is does this document achieve this?

"      When importing a route without the ATTR_SET attribute to a VRF
      that support Interior BGP mode, a PE router MUST prepend its own
      as number to the AS_PATH."

How such route is re-advertised in iBGP to the CE? Is a LOCAL_PREF attribute sent? A priori yes as per RFC 4271 ("LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers.") With which value? 

Same question when the AS number in ATTR_SET does not match the local AS configured in the VRF of the iBGP PE-CE session.

Thanks,
Regards,
Bruno

---

From: Pedro Marques <[email-masked]>
Date: Wed, 27 Apr 2011 09:19:16 -0700

Please see inline.

On Wed, Apr 27, 2011 at 2:21 AM,  <[email-masked]> wrote:
> ASBR1 use inter AS option A. Should they use an iBGP session compliant with this document or a regular eBGP session?

They should use an eBGP session.

> In the latter case, the ATTR_SET attribute will be dropped by ASBR and hence will not be propagated from PE1 to PE2.

In both cases the ATTR_SET attribute will be "poped". The ATTR_SET
attribute is only propagated as long as the route is an "inet-vpn"
route... once imported into a VRF it disappears.

> I read that the PE does not use the VPN/SP LOCAL_PREF but the customer one. Hence a SP could not influence the load balancing across its ASBR option B.

An SP can influence load balancing across option B by using local pref
in the inet-vpn space.

                             ASBR1  <====> ASBR3
    PE1 -- [ AS 1 ]                                          [ AS 2 ]
-- PE2 -- VRF
                             ASBR2  <====> ASBR4

A RD1:IP-prefix "inet-vpn" route that originates in PE1 will appear in
PE2 from both ASBR3 and 4 (assuming no reflection). Local-pref on the
SP network can be used to influence the routing decision as to which
of the paths to RD1:IP-prefix is preferable.

If there is another route injected from a PE3 with prefix
RD3:IP-prefix, it is the customer route local-pref that would
influence the decision after the inet-vpn route is imported into the
VRF and becomes an inet route.

Also note that nothing prevents a vendors from adding extra policy
mechanisms. What changes is that the customer local-pref used to
always get squashed by protocol definition (not policy).

> Now a customer VPN having sites connected in both SP ask for iBGP session between PE and CE.

I don't think the question is put correctly. I believe the question
should be: what it takes for cooperating providers to be able to
provide a completely transparent service to the customer such that the
VPN network appears as a core.

My answer would be that you can achieve that with a combination of
option B and this document. Note that with option B, ASBRs can as a
matter of local policy look at the contents of the IP packets
traversing the link if they so choose.

> If you restrict this to a transition mechanism, should I understand that you do not recommend that a VPN has both a set of sites in one AS using iBGP and some other sites (in a different AS) using…

A "virtual private network" can consist of multiple ASes. I would
recommend that one customer AS (AS 1) interconnects with iBGP with a
given VPN provider in order to receive routes from both AS 1 and other
ASes that could be ebgp interconnected.

I would not recommend that an AS, AS 1, interconnects with a VPN
provider both as iBGP and as eBGP (as AS1).

There are some assumptions of connectivity in an AS. I would recommend
that one would stick to these assumptions whenever possible. But
extranets often use a VPN provider to exchange routes between multiple
ASes with no known problems.

> As for the concrete application, I guess we could have a VPN customer with multiple CE/site in one AS numbers but yet some other sites in a different AS number. E.g. sites A1...Ai in AS A and sites B1...Bj in AS B. Can a SP put all these VPN sites in the same VPN and the VPN network will transparently handle this case?

Yes.

> (i.e. interconnect Ai & Aj using iBGP, interconnect Bi & Bj using iBGP, while interconnect Ai & Bi using eBGP). Or should this be avoided? Or do we need anything special (config / additional gateway) to handle this?

Then the text should be modified to clarify this.

> I agree that this is the desired result. The question is does this document achieve this?

By the rules specified regarding how the vrf-import stage modifies BGP
attributes.

The AS of the importing VRF is compared to the Origin AS of the
ATTR_SET attribute. CE1 and CE3 have the same "VRF AS" so the route is
imported as-is (using the original attributes preserved in ATTR_SET).
When a route from CE1 is imported into the VRF containing CE2 the VRF
ASes do not match. This results in an implicit eBGP peering between AS
1 and AS 2.

> How such route is re-advertised in iBGP to the CE?

The exact same behavior as if you had a CE that speaks to the PE using
the current mechanisms (without this document) and that CE is then
speaking iBGP to another CE (and using reflection to propagate
routes).

> Is a LOCAL_PREF attribute sent? A priori yes as per RFC 4271 ("LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers.") With which value?

The default value. LOCAL_PREF is always initialized to the default
value for an eBGP received route.

> Same question when the AS number in ATTR_SET does not match the local AS configured in the VRF of the iBGP PE-CE session.

Same answer. There is an implicit eBGP peering between the Origin AS
and the VRF AS of the importing VRF.

  Pedro.

---

From: <[email-masked]>
Date: Thu, 28 Apr 2011 14:41:36 +0200

Please see inline.

> route... once imported into a VRF it disappears.

Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after copying the BGP attributes of the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. Then the next ASBR would "push" them back in a new ATTR_SET attribute. Hence BGP attributes of the customer are propagated end to end.
 
> > I read that the PE does not use the VPN/SP LOCAL_PREF but the customer one. Hence a SP could not
> influence the load balancing across its ASBR option B.
> 

Ok. Thanks for the additional explanation.
 
> > Let's take a SP A that cooperates with SP B to increase the geographic coverage of its VPN service
> (in a cost effective way given that the low demand in this location does not justify extending the VPN
> network of SP A). SPs uses inter AS option A.
> >

Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS interconnection pre-exist when the first iBGP PE-CE customer comes. So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. That's fine for me if l3vpn-ibgp does not work with inter AS option A, but I still believe this should be indicated in the "deployment considerations" section of the document. You can also add that to be able to provide iBGP PE-CE, SP should favor inter AS option B (over A).

> > If you restrict this to a transition mechanism, should I understand that you do not recommend that a
> VPN has both a set of sites in one AS using iBGP and some other sites (in a different AS) using eBGP?
> 
> > As for the concrete application, I guess we could have a VPN customer with multiple CE/site in one
> AS numbers but yet some other sites in a different AS number. E.g. sites A1...Ai in AS A and sites
> B1...Bj in AS B. Can a SP put all these VPN sites in the same VPN and the VPN network will
> transparently handle this case?
> 
> Yes.
> 
> > (i.e. interconnect Ai & Aj using iBGP, interconnect Bi & Bj using iBGP, while interconnect Ai & Bi
> using eBGP). Or should this be avoided? Or do we need anything special (config / additional gateway)
> to handle this?
> > Any answer (yes/ no / yes with X) is fine. The goal of the text is simply to make it clear for SP
> whether such topology is in scope of the document or not. (currently I believe it is not in scope)
> 

Ok. IMHO for some readers that would be a useful precision to add in the document. In particular, this means that the CE will receive over an iBGP session both "valid"/AS policy compliant BGP attributes, and default BGP attributes (ala eBGP) that may need to be policed by a routemap.
 
> > Is a LOCAL_PREF attribute sent? A priori yes as per RFC 4271 ("LOCAL_PREF is a well-known attribute
> that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal
> peers.") With which value?
>

---

From: Pedro Marques <[email-masked]>
Date: Thu, 28 Apr 2011 13:29:38 -0700

Bruno,

> Yes. With iBGP, the ATTR_SET attribute will be "poped" but only after copying the BGP attributes of the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes. Then the next ASBR would "pu…

But that wouldn't be inter-as option A, would it ? Option A is defined
as using eBGP on a per VRF basis.

I believe that one needs to consider what is the design of the
"customer" AS... while their may be topologies where you can get away
with the scenario you suggest, i'm now aware of a generic scenario
where this would work correctly.

>
> Given that l3vpn-ibgp comes after inter AS, I would assume that inter AS interconnection pre-exist when the first iBGP PE-CE customer comes.

> So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face it. That's fine for me if l3vpn-ibgp does not work with inter AS option A

There is no way i'm aware off to achieve VPN network transparency when
the provider interconnect is based on converting VPN routes to IP
route passing it through an eBGP peering and back.

The motivation to do iBGP is to provide VPN network transparency. In
inter-as cases to achieve transparency iBGP is not the only
requirement. You also need to exchange this customer routes via option
B (or C).

>, but I still believe this should be indicated in the "deployment considerations" section of the document. You can also add that to be able to provide iBGP PE-CE, SP should favor inter AS option B (over A).
>

Will do.

  Pedro.

---

From: <[email-masked]>
Date: Fri, 29 Apr 2011 19:14:08 +0200

Pedro,

Thanks for the clarification text that you have added on inter AS VPN.
New draft (-04) addresses all my comments.

Thanks,
Regards,
Bruno

> From: Pedro Marques [mailto:[email-masked]]
> 
> Bruno,
> 
> > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only
after copying the BGP attributes of
> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes.
Then the next ASBR would "push"
> them back in a new ATTR_SET attribute. Hence BGP attributes of the
customer are propagated end to end.
> > Given that l3vpn-ibgp comes after inter AS, I would assume that
inter AS interconnection pre-exist
> when the first iBGP PE-CE customer comes.
> 
> 
> > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face
it. That's fine for me if l3vpn-
> ibgp does not work with inter AS option A
> 
> >, but I still believe this should be indicated in the "deployment
considerations" section of the
> document. You can also add that to be able to provide iBGP PE-CE, SP
should favor inter AS option B
> (over A).