Subject: Re: draft-ietf-l3vpn-ibgp

From: Derick Winkworth <[email-masked]>
Date: Fri, 27 May 2011 08:36:15 -0700 (PDT)

All:

I see no mention of peering to a CE device using the provider's global AS.  I 
see potential use cases for this where a service-provider puts a non-MPLS aware 
device in between PEs.  For instance, a firewall with an "inside VRF" and an 
"outside VRF."  

The service-provider owns and manages this device.  The device supports BGP and 
whatever service it is providing, routes are passed through it (either PE to PE 
or the device itself reflects the routes from one PE to another). This could be 
WAAS, IPS, firewall, a router performing NAT services, etc.

I think this possibility should be addressed as there are issues with the 
"service PEs" on either side of a device peering with an MP-BGP route-reflector. 
 Specifically, as routes pass from MP-BGP to regular inet iBGP back into the 
opposite PE, it may be desirable to remove cluster and originator ID info.

Derick

---

From: Pedro Marques <[email-masked]>
Date: Fri, 27 May 2011 09:10:27 -0700

Derick,
Your email is rather vague in terms of the scenario that your are
trying to address. You refer to service appliances such as
firewall/nat. These are often deployed with a Hub & Spoke
configuration in which spoke sites are not allowed to communicate
directly and must traverse a Hub site.

Hub & spoke configurations can be achieved by using 2 route target per
VPN: an hub route target (exported by the hub site and imported by the
spoke PEs) and a spoke RT (exported by the spoke sites and imported by
the hub). There is no need to explicitly have the service appliance
participate in routing in order to accomplish this.

If you do wish the appliance to be an active component to the routing
infrastructure that can also be achieved using two different VPNs
(i.e. different route targets) for the "inside" and "outside"
partition (these RTs can actually use the same customer as#).

Using what is currently specified in this document it is possible to
have a non BGP/MPLS VPN device be the Route Reflector between
different clusters (such as an "inside" cluster and an "outside"
cluster). These clusters have their routing information conveyed over
a BGP/MPLS VPN. I'm not aware of any additional functionality required
to make this happen other than what is already specified.

BGP is a generic and flexible mechanism used in a very wide range of
scenarios. With this document there is a standard to allow an iBGP
cloud to use BGP/MPLS VPN as its internal connectivity. It maintains
the same service model as iBGP over plain vanilla internal
connectivity. I don't believe it would be useful to deviate from that.

regards,
  Pedro.

On Fri, May 27, 2011 at 8:36 AM, Derick Winkworth <[email-masked]> wrote:
> All:
> I see no mention of peering to a CE device using the provider's global AS.
>  I see potential use cases for this where a service-provider puts a non-MPLS
> aware device in between PEs.  For instance, a firewall with an "inside VRF"
> and an "outside VRF."
> The service-provider owns and manages this device.  The device supports BGP
> and whatever service it is providing, routes are passed through it (either
> PE to PE or the device itself reflects the routes from one PE to another).
> This could be WAAS, IPS, firewall, a router performing NAT services, etc.
> "service PEs" on either side of a device peering with an MP-BGP
> route-reflector.  Specifically, as routes pass from MP-BGP to regular inet
> iBGP back into the opposite PE, it may be desirable to remove cluster and
> originator ID info.
> Derick
>
>

---

From: Derick Winkworth <[email-masked]>
Date: Fri, 27 May 2011 09:35:00 -0700 (PDT)

Well, let me put it a different way.

If you use the SP's global AS to peer via iBGP to a "CE" device and that route 
passes to another PE in the same provider AS, and that other PE VRF has a 
different RD and route-targets, is it not a different route at that point?  I 
guess what I'm suggesting is that in the case of using the service-provider's AS 
in a PE-CE peering the passing of route-reflector info should be optional as it 
may be desirable to pass the route back into the same cluster but "originating" 
from the second PE with different RD/RT.

I think this would actually be simpler than maintaining multiple clusters with 
redundant RRs.  Technically, a RR-client should not peer to more than one 
cluster anyway. What if VRF "A" on a PE wants transitivity to VRF "B" on the 
same PE through such a device?  

The route would pass from VRF "A" on PE1 into MP-BGP, through RR "A" to the 
inside VRF PE, through the device, to the outside VRF PE, then to RR "B" (if the 
cluster-id is the same on RRs "A" and "B" the route dies here), and then back to 
the PE hopefully to be imported into VRF "B."  The originator ID would prevent 
this.

________________________________
From: Pedro Marques <[email-masked]>
To: Derick Winkworth <[email-masked]>
Cc: [email-masked]
Sent: Fri, May 27, 2011 11:10:27 AM
Subject: Re: draft-ietf-l3vpn-ibgp

Derick,

regards,
  Pedro.

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 27 May 2011 13:17:30 -0400

If the cluster ID is the same (and the AS is the same),
then it's the same cluster.
If the AS is not the same, then the cluster list got removed
on an ebgp hop.

I'm confused.
Can you draw a diagram?

--
Jakob Heitz.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Derick Winkworth
Sent: Friday, May 27, 2011 9:35 AM
To: Pedro Marques
Cc: [email-masked]
Subject: Re: draft-ietf-l3vpn-ibgp

If you use the SP's global AS to peer via iBGP to a "CE" device and that route passes to another PE in the same provider AS, and that other PE VRF has a different RD and route-targets, is it not a different route at that point?  I guess what I'm suggesting is that in the case of using the service-provider's AS in a PE-CE peering the passing of route-reflector info should be optional as it may be desirable to pass the route back into the same cluster but "originating" from the second PE with different RD/RT.

I think this would actually be simpler than maintaining multiple clusters with redundant RRs.  Technically, a RR-client should not peer to more than one cluster anyway. What if VRF "A" on a PE wants transitivity to VRF "B" on the same PE through such a device?

The route would pass from VRF "A" on PE1 into MP-BGP, through RR "A" to the inside VRF PE, through the device, to the outside VRF PE, then to RR "B" (if the cluster-id is the same on RRs "A" and "B" the route dies here), and then back to the PE hopefully to be imported into VRF "B."  The originator ID would prevent this.

Derick,

regards,
  Pedro.

---

From: Pedro Marques <[email-masked]>
Date: Fri, 27 May 2011 10:59:20 -0700

I'm not able to follow. Please see inline.

On Fri, May 27, 2011 at 9:35 AM, Derick Winkworth <[email-masked]> wrote:
> If you use the SP's global AS to peer via iBGP to a "CE" device and that
> route passes to another PE in the same provider AS, and that other PE VRF
> has a different RD and route-targets,

It is unclear which AS#s are involved in your scenario and whether the
peering sessions are internal or external.

> is it not a different route at that point?

<smile>
That sounds like one of those existential questions such as "what is
the meaning of life ?".
</smile>

>  I guess what I'm suggesting is that in the case of using the
> service-provider's AS in a PE-CE peering

The draft in question is intended to allow the use of the customer AS
is PE-CE peering.

> the passing of route-reflector info
> should be optional as it may be desirable to pass the route back into the
> same cluster but "originating" from the second PE with different RD/RT.

I'm not sure if you are referring to VPN route attributes or to the
customer route attributes.

> I think this would actually be simpler than maintaining multiple clusters
> with redundant RRs.  Technically, a RR-client should not peer to more than
> one cluster anyway. What if VRF "A" on a PE wants transitivity to VRF "B" on
> the same PE through such a device?

I don't understand the issue you are trying to point out. It is
unclear to me whether you are referring to the status quo before this
document or the document support for extranets. The document does have
a section on extranet support. I'm not aware of an issue with the
mechanism.

> inside VRF PE, through the device, to the outside VRF PE, then to RR "B" (if
> the cluster-id is the same on RRs "A" and "B" the route dies here), and then
> back to the PE hopefully to be imported into VRF "B."  The originator ID
> would prevent this.

It may be preferable to describe a specific scenario that you are
trying to validate. It would then be possible to evaluate that
scenario against the current set of standards (minus this doc) and
this proposal.

  Pedro.

---

From: Derick Winkworth <[email-masked]>
Date: Fri, 27 May 2011 11:59:23 -0700 (PDT)

##############
################

Ok, then my concern is not relevant to the draft.  Nevertheless, I'll clarify 
with a diagram.  I did this ascii diagram in courier new size 8... I hope the 
list-server doesn't mangle it.

 _______
/PE2    \
|  ___  |
| /   \ |
| | C | |--------\
| \___/ |         \
\___|___/          \
    |              |           _______
    |              |          /PE1    \
 ___|____       ___|____      |  ___  |
/        \     /        \     | /   \ |
|  iBGP  |     |  iBGP  |     | | A |-+---[10.1.1.0/24]
|  ipv4  |     | vpn-v4 |-----| \___/ |
|   RR   |     |   RR   |     |  ___  |
\________/     \________/     | /   \ |
    |              |          | | B |-+---[10.2.2.0/24]
    |              |          | \___/ |
 ___|___           |          \_______/
/  _|_  \          /
| /   \ |         /
| | D | |--------/
| \___/ |
|       |
\PE3____/       

All depicted devices are using the same ASN.  The "ipv4 RR" device is the 
firewall/IPS/WAAS etc.  This device could be a pass-thru L2 device that does not 
actually run BGP.  In that case the the "C" and "D" VRFs peer directly with each 
other.  Either way, the problem is the same.

10.1.1.0/24 is learnt by PE1 in VRF "A" and this route is reflected via the 
"vpnv4 RR" to PE2 where VRF "C" imports it.  The route is then advertised down 
to the "ipv4 RR" device via regular ipv4 iBGP.   Again, the device is using the 
same ASN as the service-provider's global ASN.  

This route is then reflected down to VRF "D" on PE2.  Here the route is exported 
to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where hopefully VRF "B" 
will import it.

What I'm proposing is that in this scenario the transmission of cluster-list and 
originator ID info to the "ipv4 RR" device be optional.  Actually exactly where 
this information gets stripped is irrelevant to me.  It could be when VRF "C" 
imports the route from the global table of PE2.  

We are essentially converting the route from a VPNv4 route to an IPv4 route and 
then back again but with a different RD and route-targets.  This is what I mean 
when I say that the route at this point is essentially a new route, and 
therefore the cluster-list and originator ID info that were attached to the 
route when it was reflected from PE1 to PE2 no longer applies or is relevant.

---

From: Pedro Marques <[email-masked]>
Date: Fri, 27 May 2011 15:25:47 -0700

Derick,
The diagram came out just fine. Thanks for the effort you put in
clarifying your scenario for us.

The scenario you describe is traditionally referred to as Hub and Spoke.

There are two variants:
  A. appliance does not participate in routing (most common since the
network people wouldn't trust the secops guys to be involved in
routing or vice-versa);
  B. the appliance does participate in routing.

In scenario A, the typical configuration is:
  - define 2 RTs per customer: customer-spoke, customer-hub.
  - In VRF C, advertise a default route with the customer-hub RT.
  - Configure the service appliance to send all traffic from C to D.
  - In VRF D, import customer-spoke routes.
  - In VRF A, B import customer-hub routes and export customer-spoke.

This is widely used and rather unrelated with the document being discussed.

Lets go to scenario B. The difference to the scenario above is that
instead of advertising a default route from VRF C, the
box-in-the-middle is configured as an RR and advertises routing
information between the 2 VRFs.

Without this document, one can assume that the PE-CE peering is EBGP
and that all IBGP attributes do get dropped, at the edges. The only
drawback is that the AS used for the box-in-the-middle shows up again
in the AS_PATH.

With this document it is possible to have the box-in-the-middle be
part of the customer AS. Since it would be configured as an RR, the
cluster ID it imposes on routes would be maintained (a good thing in
case of loops). But that would not in any way prevent this scenario
from working.

I hope that the text above is reasonably clear.

Given the clarifications above do you have objections to the
publication of this document ?

thanks,
  Pedro.

On Fri, May 27, 2011 at 11:59 AM, Derick Winkworth <[email-masked]> wrote:
> Ok, then my concern is not relevant to the draft.  Nevertheless, I'll
> clarify with a diagram.  I did this ascii diagram in courier new size 8... I
> hope the list-server doesn't mangle it.
>  _______
> /PE2    \
> |  ___  |
> | /   \ |
> | | C | |--------\
> | \___/ |         \
> \___|___/          \
>     |              |           _______
>     |              |          /PE1    \
> firewall/IPS/WAAS etc.  This device could be a pass-thru L2 device that does
> not actually run BGP.  In that case the the "C" and "D" VRFs peer directly
> with each other.  Either way, the problem is the same.
> "vpnv4 RR" to PE2 where VRF "C" imports it.  The route is then advertised
> down to the "ipv4 RR" device via regular ipv4 iBGP.   Again, the device is
> using the same ASN as the service-provider's global ASN.
> This route is then reflected down to VRF "D" on PE2.  Here the route is
> exported to MP-BGP and reflected by the "vpn-v4 RR" back to PE1 where
> hopefully VRF "B" will import it.
>
>
> What I'm proposing is that in this scenario the transmission of cluster-list
> and originator ID info to the "ipv4 RR" device be optional.  Actually
> exactly where this information gets stripped is irrelevant to me.  It could
> be when VRF "C" imports the route from the global table of PE2.
> We are essentially converting the route from a VPNv4 route to an IPv4 route
> and then back again but with a different RD and route-targets.  This is what
> I mean when I say that the route at this point is essentially a new route,
> and therefore the cluster-list and originator ID info that were attached to
> the route when it was reflected from PE1 to PE2 no longer applies or is
> relevant.
>
>
>
>
>
>
>
>
>

---

From: Derick Winkworth <[email-masked]>
Date: Fri, 27 May 2011 19:57:48 -0700 (PDT)

Pedro:

I am OK with the document as it is.  There are two ways to look at "iBGP between 
the PE and CE."  One is as you describe it, using the Customer's AS.  The other 
is using the service-provider's AS.  The document in question only addresses the 
first variant.

I am quite familiar with hub and spoke topologies.  What I have drawn here looks 
similar, but its use is not the same.  At any rate, I'd say the scenario I 
described is not relevant to to the document.  It is, however, relevant to this 
working-group.

In the scenario I described the device that is providing the service is owned by 
the service-provider and provides some function "in-the-cloud" and traffic is 
mapped to it via route-targets. 

We do this now in production without the route-reflector.  We don't use eBGP 
because of the AS-PATH issue you describe.  We really wish we could strip the 
cluster-list and originator ID before we export the route from the PE on the 
"other" side of the device (in the diagram I provided, before the route is 
exported to MP-BGP from VRF D on PE3).  The fact of the matter is that even 
though its all the same AS, its a different route when it comes out of PE3 and 
should not have the vpnv4-RR info that was attached to it when the route 
propagated from PE1 to PE2. I also want to stress that there are cases where 
there is no intermediate device between PE2 and PE3 that can participate in BGP. 
 For instance, a wide-area acceleration device, or an IPS, or a switch that 
port-mirrors traffic to a sniffer.  In this case PE2 and PE3 peer directly with 
one another in VRFs "C" and "D."  The issue is still the same.

Another option is to not use BGP at all, but to redistribute into an IGP and 
then back again.  However, I think we really would rather not do this and stick 
with BGP. We have an irrational attachment to BGP. :-)

I got a little excited when I realized the document in question was out there 
because I thought I might be able to get some agreement on making the passing of 
the RR info optional when using iBGP and the service-provider's global AS... 
 perhaps a separate proposal could be generated.

Thanks for your time!

Derick

Sent: Fri, May 27, 2011 5:25:47 PM

Derick,

There are two variants:

thanks,
  Pedro.

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 27 May 2011 23:36:37 -0400

Derick,

VRF B forwards a packet to 10.1.1.0, what path should the packet take?
Does VRF D or VRF C need to see the packet at all? 

-- 
Jakob Heitz.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Derick Winkworth
	Sent: Friday, May 27, 2011 7:58 PM
	To: [email-masked]
	Subject: Re: draft-ietf-l3vpn-ibgp

	Pedro:

	I am OK with the document as it is.  There are two ways to look at "iBGP between the PE and CE."  One is as you describe it, using the Customer's AS.  The other is using the service-provider's AS.  The document in question only addresses the first variant.

	I am quite familiar with hub and spoke topologies.  What I have drawn here looks similar, but its use is not the same.  At any rate, I'd say the scenario I described is not relevant to to the document.  It is, however, relevant to this working-group.

	In the scenario I described the device that is providing the service is owned by the service-provider and provides some function "in-the-cloud" and traffic is mapped to it via route-targets. 

	We do this now in production without the route-reflector.  We don't use eBGP because of the AS-PATH issue you describe.  We really wish we could strip the cluster-list and originator ID before we export the route from the PE on the "other" side of the device (in the diagram I provided, before the route is exported to MP-BGP from VRF D on PE3).  The fact of the matter is that even though its all the same AS, its a different route when it comes out of PE3 and should not have the vpnv4-RR info that was attached to it when the route propagated from PE1 to PE2. I also want to stress that there are cases where there is no intermediate device between PE2 and PE3 that can participate in BGP.  For instance, a wide-area acceleration device, or an IPS, or a switch that port-mirrors traffic to a sniffer.  In this case PE2 and PE3 peer directly with one another in VRFs "C" and "D."  The issue is still the same.

	Another option is to not use BGP at all, but to redistribute into an IGP and then back again.  However, I think we really would rather not do this and stick with BGP. We have an irrational attachment to BGP. :-)

	I got a little excited when I realized the document in question was out there because I thought I might be able to get some agreement on making the passing of the RR info optional when using iBGP and the service-provider's global AS...  perhaps a separate proposal could be generated.

	Thanks for your time!

	Derick

	
	Derick,

	There are two variants:

	

	

	thanks,
	  Pedro.

---

From: Derick Winkworth <[email-masked]>
Date: Fri, 27 May 2011 21:13:34 -0700 (PDT)

The packet would travel to PE3, out of VRF "D" up through the device, into VRF 
"C"...

________________________________
From: Jakob Heitz <[email-masked]>
To: Derick Winkworth <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Fri, May 27, 2011 10:36:37 PM
Subject: RE: draft-ietf-l3vpn-ibgp

Derick,

-- 
Jakob Heitz.

    From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Derick Winkworth
    Sent: Friday, May 27, 2011 7:58 PM
    To: [email-masked]
    Subject: Re: draft-ietf-l3vpn-ibgp

    Pedro:

    I am OK with the document as it is.  There are two ways to look at "iBGP 
between the PE and CE."  One is as you describe it, using the Customer's AS.  
The other is using the service-provider's AS.  The document in question only 
addresses the first variant.

    I am quite familiar with hub and spoke topologies.  What I have drawn here 
looks similar, but its use is not the same.  At any rate, I'd say the scenario I 
described is not relevant to to the document.  It is, however, relevant to this 
working-group.

    In the scenario I described the device that is providing the service is 
owned by the service-provider and provides some function "in-the-cloud" and 
traffic is mapped to it via route-targets. 

there is no intermediate device between PE2 and PE3 that can participate in 
BGP.  For instance, a wide-area acceleration device, or an IPS, or a switch that 

    I got a little excited when I realized the document in question was out 
there because I thought I might be able to get some agreement on making the 
passing of the RR info optional when using iBGP and the service-provider's 
global AS...  perhaps a separate proposal could be generated.

    Thanks for your time!

    Derick

    
    Derick,

    There are two variants:

    

    

    thanks,
      Pedro.