Subject: [Idr] draft-litkowski-idr-rtc-interas-00

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jul 2014 16:21:05 +0200

Hi Stephane,

So how about we fix this issue by enabling orignator rewrite by RRs for all
paths not only those which are local ?

You mentioned the need to be per AS selective ... sure this also can be
knobbed on the RR if required.

What do you think ?

Thx,
R.

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 14:32:43 +0000

Hi Robert,

I don’t really see how originator rewrite can help in this …
The issue is that RR takes only best path into account when NLRI origin-AS is different from local AS to establish the distribution tree.

Could you illustrate your proposal ?

Thanks,

Stephane

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:21
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas-00

Hi Stephane,

So how about we fix this issue by enabling orignator rewrite by RRs for all paths not only those which are local ?

You mentioned the need to be per AS selective ... sure this also can be knobbed on the RR if required.

What do you think ?

Thx,
R.

_________________________________________________________________________________________________________________________

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: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jul 2014 16:50:28 +0200

My point is that if RR will reorignate the RTC route it will not be
filtered by any of the PEs hence should be propagated between adjucent ASes
as sort of "third" path .. resulting in all RTC filters to be propagated
and installed properly across.

In fact that is the only different I see between two implementations you
were referring two :)

Best,
R.

On Tue, Jul 22, 2014 at 4:32 PM, <[email-masked]> wrote:

> The issue is that RR takes only best path into account when NLRI origin-AS
> is different from local AS to establish the distribution tree.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, July 22, 2014 10:21
> *To:* LITKOWSKI Stephane SCE/IBNF
> *Cc:* idr wg
> *Subject:* draft-litkowski-idr-rtc-interas-00
>
>
>
> Hi Stephane,
>
>
>
> So how about we fix this issue by enabling orignator rewrite by RRs for
> all paths not only those which are local ?
>
>
>

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 14:54:16 +0000

Hmm … the issue is not in RTC filter propagation, but it is on RTC filter setup on the RR. RR authorize route sending VPN routes only to a single PE.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:50
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00

My point is that if RR will reorignate the RTC route it will not be filtered by any of the PEs hence should be propagated between adjucent ASes as sort of "third" path .. resulting in all RTC filters to be propagated and installed properly across.

In fact that is the only different I see between two implementations you were referring two :)

Best,
R.

On Tue, Jul 22, 2014 at 4:32 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Thanks,

Stephane

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 10:21
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: draft-litkowski-idr-rtc-interas-00

Hi Stephane,

What do you think ?

Thx,
R.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jul 2014 17:01:05 +0200

Well RT filter should be installed on all peers it has been received from
regardless what type of RTC route it is. Removing the filter from the peer
only based on particular best path chosen seems a bit wrong implementation
to me :)

The below section:

2.  [RFC4684] Section 3.2 :

    "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}.

refers to inter-as behaviour not local RT installation on any BGP speaker
within the AS.

So if this is your main issue then perhaps we have a bug ....

rgs,
r.

On Tue, Jul 22, 2014 at 4:54 PM, <[email-masked]> wrote:

>  Hmm … the issue is not in RTC filter propagation, but it is on RTC
> filter setup on the RR. RR authorize route sending VPN routes only to a
> single PE.
>
>
>
> *Sent:* Tuesday, July 22, 2014 10:50
>
> *Subject:* Re: draft-litkowski-idr-rtc-interas-00
>
>
>
>
>

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 18:55:41 +0000

I think there is no consensus on this reading of the RFC.

Especially Jeff and John already replied on the list that RT filter is only installed to best path peer. I would tend to agree with their reading of the RFC.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 11:01
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00

Well RT filter should be installed on all peers it has been received from regardless what type of RTC route it is. Removing the filter from the peer only based on particular best path chosen seems a bit wrong implementation to me :)

The below section:

refers to inter-as behaviour not local RT installation on any BGP speaker within the AS.

rgs,
r.

On Tue, Jul 22, 2014 at 4:54 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hmm … the issue is not in RTC filter propagation, but it is on RTC filter setup on the RR. RR authorize route sending VPN routes only to a single PE.

Best,
R.

Thanks,

Stephane

Hi Stephane,

What do you think ?

Thx,
R.

Thank you.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jul 2014 21:03:52 +0200

Hi,

Well I would tend to disagree.

The reasons are that fast connectivity restoration requires presence of
multiple VPN paths.

And that is both intra and inter-as.

If peer asks for routes with given RT it should get those routes.
Regardless of what RTC best path is I am going to send further.

Otherwise many things will break really bad.

Best,
r.

On Tue, Jul 22, 2014 at 8:55 PM, <[email-masked]> wrote:

> Especially Jeff and John already replied on the list that RT filter is
> only installed to best path peer. I would tend to agree with their reading
> of the RFC.
>
>
>
>
>
> *Sent:* Tuesday, July 22, 2014 11:01
>
> Hmm … the issue is not in RTC filter propagation, but it is on RTC filter
> setup on the RR. RR authorize route sending VPN routes only to a single PE.
>
>
>

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 19:11:10 +0000

This is a position that I cannot go against ☺
But anyway as everytime with BGP , there is two way :

-          Limiting number of paths states and so delaying convergence

-          Augmenting number of paths states (ADD PATH, best external …), to speed up convergence.

From a design point of view, (it’s my personal position, I was not involved in RTC initial discussion), I would tend to say that RTC must by default provide the more efficient route distribution (limiting as much as possible states). But yes, I agree that if there is a need of fastconvergence you may want to disable path pruning.

I know from private discussion with Keyur that he shares also your point of view.

Maybe the first step before discussing about a solution would be to agree on what is the expected behavior of the current specification. It seems that there is no consensus on the reading of the RFC4684.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:04
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00

Hi,

The reasons are that fast connectivity restoration requires presence of multiple VPN paths.

If peer asks for routes with given RT it should get those routes. Regardless of what RTC best path is I am going to send further.

Best,
r.

On Tue, Jul 22, 2014 at 8:55 PM, <[email-masked]<mailto:[email-masked]>> wrote:
I think there is no consensus on this reading of the RFC.

The below section:

rgs,
r.

Best,
R.

Thanks,

Stephane

Hi Stephane,

What do you think ?

Thx,
R.

Thank you.

Thank you.

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jul 2014 21:17:42 +0200

Hi,

>From a design point of view, (it’s my personal position, I was not involved
in RTC initial discussion), I would tend to say that RTC must by default
provide the more efficient route distribution (limiting as much as possible
states).

Well as I was involved from day one with Pedro on the RTC design the main
goal was not to limit states "as much as possible".

The main goal was not to send information where there is no use for it. As
a side effect yes you limit the state but no more then you should.

RTC can't be used to kill redundancy and that should not really be
negotiable.

If you would follow that model for intra-as and only install locally
originated RT routes on RR for one PE of multihomed site one PE would not
get VPN routes it is asking for. Same for ASBRs of dual connected AS.

In fact during my last project one vendor added ebgp multipath for RTC as
it was not implemented day one :)

Best,
R.

On Tue, Jul 22, 2014 at 9:11 PM, <[email-masked]> wrote:

>  This is a position that I cannot go against J
>
> From a design point of view, (it’s my personal position, I was not
> involved in RTC initial discussion), I would tend to say that RTC must by
> default provide the more efficient route distribution (limiting as much as
> possible states). But yes, I agree that if there is a need of
> fastconvergence you may want to disable path pruning.
>
>
>
> Maybe the first step before discussing about a solution would be to agree
> on what is the expected behavior of the current specification. It seems
> that there is no consensus on the reading of the RFC4684.
>
>
>
>
>
> *Sent:* Tuesday, July 22, 2014 15:04
>

---

From: <[email-masked]>
Date: Tue, 22 Jul 2014 19:23:09 +0000

> RTC can't be used to kill redundancy and that should not really be negotiable.

I don’t think that you are killing redundancy … when the primary RTC path will go down, the distribution tree will be established on the backup path, and the routes will be sent to backup ASBRs. But I completely agree that this is a slow convergence process … (sort of BGP path hiding).

I would be interested by point of view of more people (including other co-authors) on the basic spec.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 22, 2014 15:18
To: LITKOWSKI Stephane SCE/IBNF
Cc: idr wg
Subject: Re: draft-litkowski-idr-rtc-interas-00

Hi,

From a design point of view, (it’s my personal position, I was not involved in RTC initial discussion), I would tend to say that RTC must by default provide the more efficient route distribution (limiting as much as possible states).

Well as I was involved from day one with Pedro on the RTC design the main goal was not to limit states "as much as possible".

The main goal was not to send information where there is no use for it. As a side effect yes you limit the state but no more then you should.

RTC can't be used to kill redundancy and that should not really be negotiable.

If you would follow that model for intra-as and only install locally originated RT routes on RR for one PE of multihomed site one PE would not get VPN routes it is asking for. Same for ASBRs of dual connected AS.

In fact during my last project one vendor added ebgp multipath for RTC as it was not implemented day one :)

Best,
R.

On Tue, Jul 22, 2014 at 9:11 PM, <[email-masked]<mailto:[email-masked]>> wrote:
This is a position that I cannot go against ☺
But anyway as everytime with BGP , there is two way :

Hi,

Best,
r.

The below section:

rgs,
r.

Best,
R.

Thanks,

Stephane

Hi Stephane,

What do you think ?

Thx,
R.

Thank you.

Thank you.

Thank you.

Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Jul 2014 15:18:52 -0400

[choosing this one message since I think it hits the core of the discussion]

Robert,

> So if this is your main issue then perhaps we have a bug ....

The issue is not that we're limiting the distribution of the RT-C routes on
any BGP speaker.  They're being installed everywhere that you'd expect.
We're running into another related pieces.  Also from RFC 4684:

[Section 3.1]
:  Using RT membership information that includes both route-target and
:  originator AS number allows BGP speakers to use standard path
:  selection rules concerning as-path length (and other policy
:  mechanisms) to prune duplicate paths in the RT membership information
:  flooding graph, while maintaining the information required to reach
:  all autonomous systems advertising the Route Target.

So, standard route selection is occuring.  The question can be framed by
where the pruning is done: Only at e-bgp edges or in the i-bgp mesh.  In
JUNOS, this is currently happening everywhere, including i-bgp.  This
provides some consistency with the idea that the number of paths that a
given VPN RT is distributed along is AS-wide.  (Default path count is 1, but
can be adjusted via knob.)

In the case where the pruning is enforced only at e-bgp edges, then it is
much more difficult to enforce AS-wide path pruning.  A simplified example:

+---+
|   |--- A 
|   |   / \
| Z |--B---C---D
|   | / 
|   |/ 
+---+

Z is in an external AS.  A..F are our AS.
Presume each internal link has an identical IGP cost and that the BGP and
forwarding topologies are congruent.

A is single-homed to Z.
B is dual-homed to Z. The top link to Z is best.
C is a route reflector for our AS.

The AS-wide path count is set to 1.

For some RT-C distributed by Z to our AS:
At A, routes that are local to A will obviously be distributed.
At B, routes that are local to B will obviously be distributed to the top link.

At C, we have two paths to Z.  Since the paths are otherwise equal, we
tie-break on router-id and choose A as active.  For VPN route distribution
purposes, we may either:
1. Always distribute along the i-bgp mesh and not prune.
2. Limit our paths, perhaps only choosing the best path (A).

The implications of this are:
1 - We realize no savings in our i-bgp with regard to the path state we're
    keeping.  Routes go everywhere.
2 - We limit our paths and don't use memory for what are otherwise
    duplicate routes from Z's perspective.

Observe also that B can make a similar choice with regard to it's internal
link with A.  The implications of the above at B are:
1 - A will have a consistent view of the VPN routes and thus Z at A will
    have all routes present.
-or-
2 - VPN routes that may be local to B will only be distributed to Z at B.

While this consistency issue is quirky, the presumption is that Z is able to
be internally consistent due to its own iBGP rules being followed.

------

The implications of this behavioral difference aren't catastrophic, but are
worth clarifying.  If you have both behaviors present, I'm not able to come
up with a scenario where this is a problem.  The clarification would come
simply as to where the pruning occurs.

I'm personally a fan of consering internal resources.  Some amount of
redundancy for fast failover can happen simply by tuning the number of paths
that you prune to.  But for Stephane's original scenario, the desire is to
stop treating the named ASes for pruning purposes at all.  And I think that
applies even for the case where pruning happens even at ebgp.  For example,
an even terser form of Stephane's issue:

+---+
|   |\
|   | \ 
| Z |--A---B
|   | /
|   |/
+---+

When A is a PE and Z is a single AS, pruning to the single path is not a
problem.  But if Z is really:

+---+
|Z1 |\
+---+ \ 
|Z2 |--A---B
+---+ /
|Z3 |/
+---+

Then we still have the issue.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Jul 2014 21:45:19 +0200

Jeff,

To me path prooning means you select best from N and advertise single path
out.

However path prooning does not mean you do not install received
routes/filters from either IBGP or EBGP peers. Those should be IMO always
installed even if they are not best paths.

You seems to be equating those two which IMHO is not rigth with filters
like RTC (or flow spec for that matter).

Best,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Jul 2014 15:51:05 -0400

Robert,

> To me path prooning means you select best from N and advertise single path

This doesn't make any sense to me.  If we were discussing an add-path
enabled version of RT-C, it might make some sense.  But that's not what I'm
talking about.

> installed even if they are not best paths.

The RT-C routes are always accepted and installed.

The filter state that is generated from the received routes is where the
pruning is happening.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 28 Jul 2014 21:56:45 +0200

> The RT-C routes are always accepted and installed.

That is not what Stephane is observing and I do not have setup running with
Junos to try it out myself.

He said this:

"The issue is that RR takes only best path into account when NLRI origin-AS
is different from local AS to establish the distribution tree."

"it is on RTC filter setup on the RR. RR authorize route sending VPN routes
only to a single PE."

"Especially Jeff and John already replied on the list that RT filter is
only installed to best path peer."

And the last sentence is clearly in odds to what I consider proper
behaviour regarding filter handling.

Best,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Jul 2014 16:04:13 -0400

> behaviour regarding filter handling.

In the JUNOS implementation, the "filtering state" is built from the
received RT-C routes.  We accept all of the routes.  We build filtering
state for the external paths (different from the local AS) based on a path
count for the external paths traversed in internal route order.

To offer a very coarse analogy, when an interface in multicast is subscribed
to a group, it doesn't mean that the upstream will necessarily send traffic
to it.  Other mechanisms may impact that.

And thus, for our VPN route distribution filtering state, just because we
have an eligible path to use, it doesn't mean that we'll distribute to that
path; we prune externals that exceed the path count.

I'm starting to think this issue has gone a bit too far "into the weeds".
If it weren't for the fact that similar implementations may run into this
problem based on a reading of 4684, it'd be easier to just fix this locally
(as we're going to do) to cover our interpretation of the RFC.

-- Jeff