Subject: [Idr] Clarification required on RFC4684

From: <[email-masked]>
Date: Tue, 17 Jun 2014 15:11:34 +0000

Hi Folks,

During some testing, we detected some deprecancies in implementations leading to different behaviors in a single multi-network.

The setup is as follows :

Consider the following setup (to simplify)

CE1 ----- (mpebgp+rtc) ---- PE1
                                                                \
                                                                RR
                                                             /
CE2 -----(mpebgp+rtc) ----- PE2

CE1 and CE2 are in the same AS(65000) and are both originating an RTC update (65000:2:1:1)
PE1 and PE2 are sending the external RTC update to RR

RR has two path for the RTC NLRI 65000:2:1:1 (from PE1 & PE2). Let's consider that PE1 is the best path, here comes the issue :

-          In Implementation #1, only PE1 receives VPNv4 routes associated with RT 1:1

-          In implementation #2, both PEs are receiving VPNv4 routes

Implementation #1 is causing us some issue but sounds to be inline with the RFC, where the specification tries to find out the shortest path to the AS to establish the flooding tree :

"As indicated above, the inter-AS VPN route distribution graph, for a

   given route-target, is constructed by creating a directed arc on the

   inverse direction of received Route Target membership UPDATEs

   containing an NLRI of the form {origin-as#, route-target}.

   Inside the BGP topology of a given autonomous-system, as far as

   external RT membership information is concerned (route-targets where

   the as# is not the local as), it is easy to see that standard BGP

   route selection and advertisement rules [4<http://tools.ietf.org/html/rfc4684#ref-4>] will allow a transit AS

   to create the necessary flooding state.

"

There is also in Section 3.2 some ambiguity introduced :

"Inside the BGP topology of a given autonomous-system, as far as

   external RT membership information is concerned (route-targets where

   the as# is not the local as), it is easy to see that standard BGP

   route selection and advertisement rules [4<http://tools.ietf.org/html/rfc4684#ref-4>] will allow a transit AS

   to create the necessary flooding state.

"

Then

"Route Target membership information that is originated within the
   autonomous-system, however, requires more careful examination.

"

Implementation #2 applies 3.2 behavior to external informations (originas <> localas), while implementation #1 applies 3.2 behavior only to locally originated routes.

Your thoughts on this ? What is the expected behavior ?

I think we would need to fix the specification to have a more clear behavior described for such situation.

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert NoF
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 17 Jun 2014 12:27:41 -0400

Stefane,

> PE1 and PE2 are sending the external RTC update to RR
[...]
> Your thoughts on this ? What is the expected behavior ?

I'll publicly own up to working on an implementation that applies the
external checks within a route reflector. :-)
(And IDR is a fine place to discuss what we should do for interop.)

My interpretation is that this behavior is correct.  Here are the premises
that I'm working from that lead to this conclusion:
1. The fact that the received RT-C route is from the same source AS (65000)
2. The expectation in BGP that routing is internally consistent for a given AS.
3. A route reflector is expected to effectively be transparent.

In detail:
1/2.
If you surrounded CE1 and CE2 in the diagram by the usual picture of an
AS-cloud, you'd normally expect a route received at the ingress for PE1 to
be available internally at CE2 via internal propagation.

3.
If PE1/RR/PE2 were a single router, the behavior you would expect is that
one path is selected and some router (PE3, e.g.) would have its routes flow
over a single path.

Since the motivation was to reduce the amount of flooding, I would expect
that once we have one or more RRs involved, we're effectively selecting a
single flooding path to 65000 throughout the AS.

-----

The above said, you still have a legitimate issue.

If CE1 and CE2 aren't really "in the same AS" because the sites are
disconnected and we just happen to be using BGP as the PE-CE protocol, then
the premise of 1/2 above isn't helpful.

One option to address this is, for a given AS (by configuration), do not
enforce the path pruning.  Perhaps don't enforce it by default for private
AS# paths, but that might be a incorrect observation based on the example
AS# above.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 17 Jun 2014 13:49:39 -0400

Jeff, Stephane,

On Jun 17, 2014, at 12:27 PM, Jeffrey Haas <[email-masked]> wrote:

> My interpretation is that this behavior is correct. 

Mine too, for the reasons you gave. I also remember discussing this (the multi-AS behavior, not the CE behavior) with the authors when it was in draft. Both my reading of the spec and my recollection of the authors' intent says this is working as designed.

> The above said, you still have a legitimate issue.

Yes, and as you note, it exists because EBGP as a PE-CE protocol doesn't fit so well into the normal BGP paradigm. I'll add that also, it's not part of the usual L3VPN paradigm to have the CE dynamically signal the PE with its RT interests -- the usual paradigm is for it to be provider-provisioned. For that matter, the PE-CE connection doesn't typically use a VPN address family, and RTC only applies to VPN address families -- though admittedly RFC 4684 is also a bit ambiguous there. But still:

   This mechanism is applicable to any BGP NLRI that controls the
   distribution of routing information by using Route Targets, such as
   VPLS [9].

That said, it seems quite reasonable to add support for the use case (which might need a little more explanation), and the approach you describe sounds fine (though I haven't thought through any alternatives.  

> I think we would need to fix the specification to have a more clear behavior described for such situation.

Seems as though a short draft that updates 4684 to cover this use case would be a good approach.

Thanks,

--John

---

From: <[email-masked]>
Date: Wed, 18 Jun 2014 07:49:37 +0000

Hi John, and Jeff,

Thanks for your feedback ...
The fact is that with DC interconnection to VPN network, MPLS VPN interconnection with CE is more and more used and as you pointed, CE in VPN environments may use the same private AS numbering even if not really part of the same AS.

I will initiate a short draft to describe this use case.

Best Regards,

Stephane

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 19:50
To: Jeffrey Haas; LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: [Idr] Clarification required on RFC4684

Jeff, Stephane,

Thanks,

--John

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 18 Jun 2014 09:02:47 +0000

Hi Stephane, John and Jeff, 

Agree that a short draft is needed to clarify this. And if the CEs use the same private AS number, then AS substitution may be needed to make sure the RT membership route is not discarded by the CE so that VPN routes can be received by all the PEs.

And a similar case can happen in networks with hierarchical RRs, as shown in the figure below:

PE1---RR2
         \
          \    
PE1-       RR1
    \     /
     \   /
      RR3
     /
    /
PE2-

RR1 is level-1 RR, and RR2 and RR3 are level-2 RRs.

1. All the PEs advertise RTC route of RT-X to their connecting RRs.
2. RR2 and RR3 select the best RTC route, add their cluster_id to the cluster_list and advertise the RTC route to RR1 respectively. 
3. RR1 selects one RTC route as best (let's say RTC route from RR2), adds its cluster_id into the cluster_list and advertises it to RR2 and RR3. 
4. Then RR2 would receive the RTC route from RR1 with its own cluster_id in the cluster_list and will drop this RTC route.
5. As a result, RR2 will not advertise VPN routes with RT-X to RR1. 

We are working on a short draft to update the RTC behavior to cover this hierarchical RR case.

Best regards,
Jie

> From: Idr [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, June 18, 2014 3:50 PM
> To: John G. Scudder; Jeffrey Haas
> Cc: [email-masked]
> The fact is that with DC interconnection to VPN network, MPLS VPN
> interconnection with CE is more and more used and as you pointed, CE in VPN
> environments may use the same private AS numbering even if not really part of
> the same AS.
> 
> Mine too, for the reasons you gave. I also remember discussing this (the
> multi-AS behavior, not the CE behavior) with the authors when it was in draft.
> Both my reading of the spec and my recollection of the authors' intent says this
> is working as designed.
> 
> Yes, and as you note, it exists because EBGP as a PE-CE protocol doesn't fit so
> well into the normal BGP paradigm. I'll add that also, it's not part of the usual
> L3VPN paradigm to have the CE dynamically signal the PE with its RT interests --
> the usual paradigm is for it to be provider-provisioned. For that matter, the
> PE-CE connection doesn't typically use a VPN address family, and RTC only
> applies to VPN address families -- though admittedly RFC 4684 is also a bit
> ambiguous there. But still:
> 
> That said, it seems quite reasonable to add support for the use case (which
> might need a little more explanation), and the approach you describe sounds
> fine (though I haven't thought through any alternatives.
> 
> ________________________________________________________________
> _________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Thu, 19 Jun 2014 08:58:21 +0000

Here is our draft proposal :

A new version of I-D, draft-litkowski-idr-rtc-interas-00.txt
has been successfully submitted by Stephane Litkowski and posted to the IETF repository.

Name:		draft-litkowski-idr-rtc-interas
Revision:	00
Title:		Inter Domain considerations for Constrained Route distribution
Document date:	2014-06-18
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-litkowski-idr-rtc-interas-00.txt
Status:         https://datatracker.ietf.org/doc/draft-litkowski-idr-rtc-interas/
Htmlized:       http://tools.ietf.org/html/draft-litkowski-idr-rtc-interas-00

Abstract:
   [RFC4684] defines Multi-Protocol BGP (MP-BGP) procedures that allow
   BGP speakers to exchange Route Target reachability information in
   order to limit the propagation of Virtual Private Networks (VPN)
   Network Layer Reachability Information (NLRI).

   [RFC4684] addresses both intra domain and inter domain distributions.
   Based on operational deployments, the current distribution model
   defined in [RFC4684] may cause some issue in specific scenarios.

   This document refines the route distribution rules for inter domain
   NLRIs in order to address these specific scenarios.

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2014 19:50
To: Jeffrey Haas; LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: [Idr] Clarification required on RFC4684

Jeff, Stephane,

Thanks,

--John