Subject: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

From: Tony Przygienda <[email-masked]>
Date: Sat, 9 Jul 2016 22:18:18 -0700

John, Sue, may I request a slot on IDR agenda in Berlin (10 mins should be
enough) to present
https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
 ?

thanks

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Jul 2016 22:47:55 +0200

Hi Tony,

Can you clarify what is the expected behaviour as far as per peer
filter-list when you negotiate both Refresh with options, ORF and RTC ?
Note that ORF also includes recent extension as described in RFC7543 -
would all of those be always a logical AND towards a peer which pushed
those ?

Would you always carry ORF with separate Refresh_ID value ?

If one requests full Adj_RIB_Out in the new model and sends refresh message
with new refresh_id and no options however there are ORF entries already
installed in the past would he get just the subset of routes against all
ORF entries ? In other words I think the draft should state that
Refresh_IDs have no impact to ORF ADDs or REMOVE actions - don't you think
?

As far as current types why not add regular/extended community ?

Thx,
Robert.

On Sun, Jul 10, 2016 at 7:18 AM, Tony Przygienda <[email-masked]>
wrote:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 11 Jul 2016 15:04:33 -0700

> Hi Tony,

Hey Robert, thanks for chiming in. Good questions. I speak here for myself,
other authors of the draft may have differing opinions.

> would all of those be always a logical AND towards a peer which pushed

We didn't discuss that one through but the only logical conclusion for me
is that the ORF/CP-ORF installed are respected (i.e. it's an implicit AND).
I see ORF as statefull, remote-pushed policy on the peer that is not being
flipped around all the time (albeit AFAIR there were some attempts @
non-persistent, one shot ORF but that ended up expiring?)

The motivation for this work were scenarios where a single-shot refresh is
needed, actually concurrent bunch of those based on configuration changes,
peer having dropped received routes based on specs (A-D), in policy
changes, joining VPNs, EVIs and so on. Putting ORF on a peer, refresh and
remove ORFs is significantly heavier process that may interfere on top with
normal update process going on and needs to be done one-by-one (since you
have to wait for single BoRR/EoRR pair) unless one is very smart about
combining ORF possibly & playing with the DEFER/IMMEDIATEs. As we
indicated, if the AFI/SAFI is covered by RTC and RTC is supported & one is
willing to configure RTs for each subset of routes that may need
refreshing, RT will be doing the same job just fine.

> Would you always carry ORF with separate Refresh_ID value ?

Yes, Refresh-ID# is strictly monotonic so there is never a misunderstanding
WHAT the BoRR belongs to. Observe that the draft does NOT mandate that a
request MUST be followed by according BoRR, only that BoRRs must follow
same sequence as requests (i.e. are also strictly monotonic). However, we
should probably specify that options _and_ ORF can NOT be mixed in the same
type #3 message but it's either one or the other (and anything else is
error). This will allow ORF operations like today + benefit of the Refresh
ID#  on the BoRR so the IMMEDIATE can go on @ the same time as another
request with higher Refresh ID# (de facto we allow multiple parallel
refreshes as you see).  In case of DEFER there will be simply no BoRR for
it.

>
> If one requests full Adj_RIB_Out in the new model and sends refresh
> message with new refresh_id and no options however there are ORF entries
> already installed in the past would he get just the subset of routes
> against all ORF entries ? In other words I think the draft should state
> that Refresh_IDs have no impact to ORF ADDs or REMOVE actions - don't you
> think ?
>

I agree. Yes, ORF is kind of  "permanent filter" on the peer while the
intent of this draft is to have bunch of "small refreshes" going on @ same
time possibly (if you request the refreshes from a good implementation
while low-end implementations may serialize the requests to simplify
internal logic ;-).

> As far as current types why not add regular/extended community ?

Discussion came up. Feeling was it's an immediate encroach on RT territory.
I argued for it ;-)  Ultimately, taking a more relaxed view, we chose to
wait and see what the response is and most pressing use cases people bring
to it and then we start to define bits and bytes of the options supported,
possibly borrowing to an extent from the ORF specs ;-)  As in "most sincere
form of flattery" and such ... ;-)

-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 19 Jul 2016 03:03:56 -0700

Resending ...

---------- Forwarded message ----------
From: Tony Przygienda <[email-masked]>
Date: Mon, Jul 11, 2016 at 3:04 PM
Subject: Re: [Idr] Slot request in IDR to present
https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
To: Robert Raszuk <[email-masked]>
Cc: idr wg <[email-masked]>

-- tony

-- 
*We’ve heard that a million monkeys at a million keyboards could produce
the complete works of Shakespeare; now, thanks to the Internet, we know
that is not true.*
—Robert Wilensky

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 19 Jul 2016 04:43:57 -0700

yep, sorry, I missed that I only answered ORF and not RTC

As example look at 7432 section 7.9. Box of Pandora has been opened a while
ago, route type being the other one ...

On Tue, Jul 19, 2016 at 3:03 AM, Tony Przygienda <[email-masked]>
wrote:

> Hey Robert, thanks for chiming in. Good questions. I speak here for
> myself, other authors of the draft may have differing opinions.
>
>
>>
> Yes, Refresh-ID# is strictly monotonic so there is never a
> misunderstanding WHAT the BoRR belongs to. Observe that the draft does NOT
> mandate that a request MUST be followed by according BoRR, only that BoRRs
> must follow same sequence as requests (i.e. are also strictly monotonic).
> However, we should probably specify that options _and_ ORF can NOT be mixed
> in the same type #3 message but it's either one or the other (and anything
> else is error). This will allow ORF operations like today + benefit of the
> Refresh ID#  on the BoRR so the IMMEDIATE can go on @ the same time as
> another request with higher Refresh ID# (de facto we allow multiple
> parallel refreshes as you see).  In case of DEFER there will be simply no
> BoRR for it.
>
>
>>
> Discussion came up. Feeling was it's an immediate encroach on RT
> territory. I argued for it ;-)  Ultimately, taking a more relaxed view, we
> chose to wait and see what the response is and most pressing use cases
> people bring to it and then we start to define bits and bytes of the
> options supported, possibly borrowing to an extent from the ORF specs ;-)
>  As in "most sincere form of flattery" and such ... ;-)
>
> -- tony
>
>
>
>
> --

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Jul 2016 14:24:40 +0200

Tony,

Section 7.9 only mentions that RD *MAY BE* structured to include VLAN ID
but equally well it says  that it may be locally generated.

As someone pointed at this IETF term "MAY" = "MAY NOT" hence any actions
based on that is likely to fail.

Said this while perhaps someone can use your RD type to manually query the
peer for subset of routes then for any automated action .. which is what is
really need say when you modify RT import list it will fail.

Bottom line I think we should not add elements to protocols which are not
guaranteed to work if for nothing else then to reduce operational issues in
multi vendor environments.

Thx
R.

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 19 Jul 2016 05:56:02 -0700

OK, agreed in principle on 7.9.

In fact, we were oscillating between RD (with or without prefix length)
filter + address prefix filter and just 'NLRI filter' but given NLRI we
need to add RD anyway in there. The RD filter allows you to wildcard the
RD, i.e. you can e.g. request prefix/address update from your peer without.

We can start to split hair as well that section 8.2.1 does NOT give you the
flexibility to do anything else but structure the RD ...

Overall, I think the Pandora's box is open and it's better to allow an RD
filter to at least wildcard RDs ...

--- tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Jul 2016 15:06:27 +0200

Tony

Yes you have RD *prefix* not RD fixed value there which is a good progress
;).

But you just can not use RD to even query prefixes (of those SAFIS which
use it) in any automated way simply as your PE does not know it. Human
could use it but this is I hope not the main motivation of your draft.

So if you want to query say VPN safi you need RT + NLRI not RD. In those
query you would define and use the notion of ANY_RD flag implicitely or
explicitely.

Till someone at next ietf proposes new safi to auto discover all RDs in the
network which I hope will never happen use of RD for filtering or query
should be removed.

Best,
R.

On Jul 19, 2016 2:56 PM, "Tony Przygienda" <[email-masked]> wrote:

> We can start to split hair as well that section 8.2.1 does NOT give you
> the flexibility to do anything else but structure the RD ...
>
>> Said this while perhaps someone can use your RD type to manually query
>> the peer for subset of routes then for any automated action .. which is
>> what is really need say when you modify RT import list it will fail.
>>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 19 Jul 2016 13:20:45 +0000

________________________________
发件人: Idr [[email-masked]] 代表 Robert Raszuk [[email-masked]]
发送时间: 2016年7月19日 21:06
收件人: Tony Przygienda
抄送: idr wg
主题: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Tony

Yes you have RD *prefix* not RD fixed value there which is a good progress ;).

But you just can not use RD to even query prefixes (of those SAFIS which use it) in any automated way simply as your PE does not know it. Human could use it but this is I hope not the main motivation of your draft.

So if you want to query say VPN safi you need RT + NLRI not RD. In those query you would define and use the notion of ANY_RD flag implicitely or explicitely.

[Xiaohu] In fact, this draft (https://tools.ietf.org/html/draft-xu-bess-l3vpn-prefix-orf-02) is just intended to achieve the above goal (i.e., requesting partial routes of a given VPN) .

Best regards,

Xiaohu

Till someone at next ietf proposes new safi to auto discover all RDs in the network which I hope will never happen use of RD for filtering or query should be removed.

Best,
R.

On Jul 19, 2016 2:56 PM, "Tony Przygienda" <[email-masked]<mailto:[email-masked]>> wrote:
OK, agreed in principle on 7.9.

In fact, we were oscillating between RD (with or without prefix length) filter + address prefix filter and just 'NLRI filter' but given NLRI we need to add RD anyway in there. The RD filter allows you to wildcard the RD, i.e. you can e.g. request prefix/address update from your peer without.

We can start to split hair as well that section 8.2.1 does NOT give you the flexibility to do anything else but structure the RD ...

Overall, I think the Pandora's box is open and it's better to allow an RD filter to at least wildcard RDs ...

--- tony

On Tue, Jul 19, 2016 at 5:24 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Tony,

Section 7.9 only mentions that RD *MAY BE* structured to include VLAN ID but equally well it says  that it may be locally generated.

As someone pointed at this IETF term "MAY" = "MAY NOT" hence any actions based on that is likely to fail.

Said this while perhaps someone can use your RD type to manually query the peer for subset of routes then for any automated action .. which is what is really need say when you modify RT import list it will fail.

Bottom line I think we should not add elements to protocols which are not guaranteed to work if for nothing else then to reduce operational issues in multi vendor environments.

Thx
R.

--
We’ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
―Robert Wilensky

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 19 Jul 2016 21:47:34 +0000

Hi Tony,

Please see some comments inline with [Jie]:

From: Idr [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Tuesday, July 19, 2016 6:04 PM
To: Robert Raszuk; idr wg
Subject: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Resending ...

---------- Forwarded message ----------
From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 11, 2016 at 3:04 PM
Subject: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>

On Mon, Jul 11, 2016 at 1:47 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tony,

Hey Robert, thanks for chiming in. Good questions. I speak here for myself, other authors of the draft may have differing opinions.

Can you clarify what is the expected behaviour as far as per peer filter-list when you negotiate both Refresh with options, ORF and RTC ? Note that ORF also includes recent extension as described in RFC7543 - would all of those be always a logical AND towards a peer which pushed those ?

We didn't discuss that one through but the only logical conclusion for me is that the ORF/CP-ORF installed are respected (i.e. it's an implicit AND). I see ORF as statefull, remote-pushed policy on the peer that is not being flipped around all the time (albeit AFAIR there were some attempts @ non-persistent, one shot ORF but that ended up expiring?)

[Jie] I think the attempts you mentioned here are the one-time ORF drafts: draft-zeng-idr-one-time-prefix-orf  and draft-dong-idr-one-time-ext-community-orf. After several revisions, these drafts got expired due to lack of requirements at that time. If people found some new use cases of these kinds of mechanisms, the authors would be happy to bring them back to discussion.

The motivation for this work were scenarios where a single-shot refresh is needed, actually concurrent bunch of those based on configuration changes, peer having dropped received routes based on specs (A-D), in policy changes, joining VPNs, EVIs and so on. Putting ORF on a peer, refresh and remove ORFs is significantly heavier process that may interfere on top with normal update process going on and needs to be done one-by-one (since you have to wait for single BoRR/EoRR pair) unless one is very smart about combining ORF possibly & playing with the DEFER/IMMEDIATEs. As we indicated, if the AFI/SAFI is covered by RTC and RTC is supported & one is willing to configure RTs for each subset of routes that may need refreshing, RT will be doing the same job just fine.

[Jie] The motivations look similar to what we described for the one-time ORF drafts.

Yes, Refresh-ID# is strictly monotonic so there is never a misunderstanding WHAT the BoRR belongs to. Observe that the draft does NOT mandate that a request MUST be followed by according BoRR, only that BoRRs must follow same sequence as requests (i.e. are also strictly monotonic). However, we should probably specify that options _and_ ORF can NOT be mixed in the same type #3 message but it's either one or the other (and anything else is error). This will allow ORF operations like today + benefit of the Refresh ID#  on the BoRR so the IMMEDIATE can go on @ the same time as another request with higher Refresh ID# (de facto we allow multiple parallel refreshes as you see).  In case of DEFER there will be simply no BoRR for it.

If one requests full Adj_RIB_Out in the new model and sends refresh message with new refresh_id and no options however there are ORF entries already installed in the past would he get just the subset of routes against all ORF entries ? In other words I think the draft should state that Refresh_IDs have no impact to ORF ADDs or REMOVE actions - don't you think ?

I agree. Yes, ORF is kind of  "permanent filter" on the peer while the intent of this draft is to have bunch of "small refreshes" going on @ same time possibly (if you request the refreshes from a good implementation while low-end implementations may serialize the requests to simplify internal logic ;-).

Discussion came up. Feeling was it's an immediate encroach on RT territory. I argued for it ;-)  Ultimately, taking a more relaxed view, we chose to wait and see what the response is and most pressing use cases people bring to it and then we start to define bits and bytes of the options supported, possibly borrowing to an extent from the ORF specs ;-)  As in "most sincere form of flattery" and such ... ;-)

[Jie] Actually before the one-time ORF drafts were submitted, we initially considered to make it a “selective route refresh” mechanism. Then we realized that the filters will be quite similar to the ones already defined for ORF. In order to reuse the ORF filters, we then decided to define this mechanism as new “one-time” ORF types.  Just to provide some background information since you also plan to reuse the format of the existing ORF types.

Best regards,
Jie

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 19 Jul 2016 23:52:16 +0200

Hi Jie,

To me what is perhaps missing is just a new draft to define *Route Type*
ORF to address some of those EVPN new NLRI encodings.

I am not that much convinced if one time ORF is needed as you are free to
INSTALL and REMOVE ORF effectively producing one time behavior. Also
existing Enhanced Route Refresh should work with ORF too.

Many thx,
R.

On Tue, Jul 19, 2016 at 11:47 PM, Dongjie (Jimmy) <[email-masked]>
wrote:

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Tony Przygienda
> *Sent:* Tuesday, July 19, 2016 6:04 PM
> *To:* Robert Raszuk; idr wg
> *Subject:* [Idr] Fwd: Slot request in IDR to present
> From: *Tony Przygienda* <[email-masked]>
> [Jie] I think the attempts you mentioned here are the one-time ORF drafts:
> draft-zeng-idr-one-time-prefix-orf  and
> draft-dong-idr-one-time-ext-community-orf. After several revisions, these
> drafts got expired due to lack of requirements at that time. If people
> found some new use cases of these kinds of mechanisms, the authors would be
> happy to bring them back to discussion.
>
>
>
> [Jie] Actually before the one-time ORF drafts were submitted, we initially
> considered to make it a “selective route refresh” mechanism. Then we
> realized that the filters will be quite similar to the ones already defined
> for ORF. In order to reuse the ORF filters, we then decided to define this
> mechanism as new “one-time” ORF types.  Just to provide some background
> information since you also plan to reuse the format of the existing ORF
> types.
>
>
>
> Best regards,
>
> Jie
>
>
>
> -- tony
>
>
>
>
>
>
>
> --
>

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Tue, 19 Jul 2016 22:18:24 +0000

Robert, Dongjie,

Comments inlined #Keyur

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 19, 2016 at 2:52 PM
To: "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Hi Jie,

To me what is perhaps missing is just a new draft to define *Route Type* ORF to address some of those EVPN new NLRI encodings.

#Keyur: ORFs are permanent filters. We wanted to decouple the transaction based filters (one time per refresh) from the permanent filters and hence chose to modify refresh message as opposed to an ORF.

I am not that much convinced if one time ORF is needed as you are free to INSTALL and REMOVE ORF effectively producing one time behavior.

#Keyur: Ack.

Also existing Enhanced Route Refresh should work with ORF too.

#Keyur: There are modifications needed if the refresh is going to be for selective prefixes only. Furthermore, if we want to support multiple concurrent selective refreshes then the changes needed are very much along the lines of the solution suggested in the draft.

Regards,
Keyur

Many thx,
R.

On Tue, Jul 19, 2016 at 11:47 PM, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tony,

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tony Przygienda
Sent: Tuesday, July 19, 2016 6:04 PM
To: Robert Raszuk; idr wg
Subject: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Resending ...

---------- Forwarded message ----------
From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 11, 2016 at 3:04 PM
Subject: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>

[Jie] Actually before the one-time ORF drafts were submitted, we initially considered to make it a "selective route refresh" mechanism. Then we realized that the filters will be quite similar to the ones already defined for ORF. In order to reuse the ORF filters, we then decided to define this mechanism as new "one-time" ORF types.  Just to provide some background information since you also plan to reuse the format of the existing ORF types.

Best regards,
Jie

-- tony

--
We've heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
-Robert Wilensky

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Jul 2016 00:29:45 +0200

Hi Keyur,

The missing part seems to be justification if we really need "transaction
based filters" as opposed to simply having permanent ones.

What real problem "transaction based filters" solve ? IMO the draft needs
to state it clearly.

The other point is that "permanent" are not really permanent anyway .. they
are installed from update to withdraw of a given filter - regardless what
filtering mechanism you choose (ORF, RTC, XYZ ...). And if you go with the
notion that permanent are sufficient the entire aparatus allowing you to
have concurrent route refresh requests in flight goes away :)

Thx,
r.

On Wed, Jul 20, 2016 at 12:18 AM, Keyur Patel (keyupate) <[email-masked]

> Robert, Dongjie,
>
> Comments inlined #Keyur
>
> From: Robert Raszuk <[email-masked]>
> To: "Dongjie (Jimmy)" <[email-masked]>
> Subject: Re: [Idr] Fwd: Slot request in IDR to present
> #Keyur: ORFs are permanent filters. We wanted to decouple the transaction
> based filters (one time per refresh) from the permanent filters and hence
> chose to modify refresh message as opposed to an ORF.
>
> INSTALL and REMOVE ORF effectively producing one time behavior.
>
> #Keyur: Ack.
>
> #Keyur: There are modifications needed if the refresh is going to be for
> selective prefixes only. Furthermore, if we want to support multiple
> concurrent selective refreshes then the changes needed are very much along
> the lines of the solution suggested in the draft.
>
> Regards,
> Keyur
>
>
>
> Many thx,
> R.
>
>
>
>
>> [Jie] I think the attempts you mentioned here are the one-time ORF
>> drafts: draft-zeng-idr-one-time-prefix-orf  and
>> The motivation for this work were scenarios where a single-shot refresh
>> is needed, actually concurrent bunch of those based on configuration
>> changes, peer having dropped received routes based on specs (A-D), in
>> policy changes, joining VPNs, EVIs and so on. Putting ORF on a peer,
>> refresh and remove ORFs is significantly heavier process that may interfere
>> on top with normal update process going on and needs to be done one-by-one
>> (since you have to wait for single BoRR/EoRR pair) unless one is very smart
>> about combining ORF possibly & playing with the DEFER/IMMEDIATEs. As we
>> [Jie] Actually before the one-time ORF drafts were submitted, we
>> initially considered to make it a “selective route refresh” mechanism. Then
>> we realized that the filters will be quite similar to the ones already
>> defined for ORF. In order to reuse the ORF filters, we then decided to
>> define this mechanism as new “one-time” ORF types.  Just to provide some
>> background information since you also plan to reuse the format of the
>> existing ORF types.
>>
>>
>>
>> Best regards,
>>
>> Jie
>>
>>
>>
>> -- tony
>>
>>
>>
>>
>>
>>
>>
>> --
>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 20 Jul 2016 07:27:36 +0000

Hi Robert,

I agree that “Route Type” based filtering may be needed in some cases. Do you think it should behave as one-time filter or a permanent filter, or maybe both are needed?

As for the one-time behavior, IMO it deserves a dedicated ORF type (or refresh option), as using consecutive messages to install and remove the ORF filter could introduce unnecessary cost in both message exchange and the processing on the device.

Best regards,
Jie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, July 20, 2016 5:52 AM
To: Dongjie (Jimmy)
Cc: Tony Przygienda; idr wg
Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Hi Jie,

I am not that much convinced if one time ORF is needed as you are free to INSTALL and REMOVE ORF effectively producing one time behavior. Also existing Enhanced Route Refresh should work with ORF too.

Many thx,
R.

Resending ...

---------- Forwarded message ----------
From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 11, 2016 at 3:04 PM
Subject: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>

Best regards,
Jie

-- tony

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 20 Jul 2016 07:45:57 +0000

Hi Keyur,

Please see my comments inline with [Jie2]:

From: Keyur Patel (keyupate) [mailto:[email-masked]]
Sent: Wednesday, July 20, 2016 6:18 AM
To: Robert Raszuk; Dongjie (Jimmy)
Cc: idr wg
Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Robert, Dongjie,

Comments inlined #Keyur

Hi Jie,

[Jie2]: This was also my understanding in the beginning of writing the one-time orf drafts. However since you need traffic filters for this "selective refresh", you will find out it is already there with ORF, then you will want to reuse the filters. Actually it is something between the traditional refresh and the traditional ORF,  IMO the name does not really matter, the important thing is we can reuse what already exists.

#Keyur: Ack.

[Jie2] For the concurrent refresh part, could you elaborate in which case it will be needed? The draft says "The BGP speaker responding to  the route refresh requests MAY perform the refreshes in parallel", do you mean the route updates for different selective refresh requests may be interleaved?

Best regards
Jie

Regards,
Keyur

Many thx,
R.

Resending ...

---------- Forwarded message ----------
From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 11, 2016 at 3:04 PM
Subject: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>

Best regards,
Jie

-- tony

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 20 Jul 2016 21:05:37 +0000

Hi Robert,

One interesting use case is with EVPN address family where a new route-type is introduced without a capability.  A PE may have had safi enabled but not have accepted its route-type (or set of route-types) all mapping to a same RT. A transactional filter attempts to solve it.

We can clarify in the next revision of the draft.

One more comment inlined #Keyur

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 19, 2016 at 3:29 PM
To: Keyur Patel <[email-masked]<mailto:[email-masked]>>
Cc: "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>, idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Hi Keyur,

The missing part seems to be justification if we really need "transaction based filters" as opposed to simply having permanent ones.

What real problem "transaction based filters" solve ? IMO the draft needs to state it clearly.

The other point is that "permanent" are not really permanent anyway .. they are installed from update to withdraw of a given filter - regardless what filtering mechanism you choose (ORF, RTC, XYZ ...). And if you go with the notion that permanent are sufficient the entire aparatus allowing you to have concurrent route refresh requests in flight goes away :)

#Keyur: Ack your right. My reference to a permanent filter was in context of a session life time and I agree with you that it could be modified or withdrawn at any given time. I was trying to differentiate it from transactional filters.

Regards,
Keyur

Thx,
r.

On Wed, Jul 20, 2016 at 12:18 AM, Keyur Patel (keyupate) <[email-masked]<mailto:[email-masked]>> wrote:
Robert, Dongjie,

Comments inlined #Keyur

Hi Jie,

#Keyur: Ack.

Regards,
Keyur

Many thx,
R.

Resending ...

---------- Forwarded message ----------
From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 11, 2016 at 3:04 PM
Subject: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>

Best regards,
Jie

-- tony

---

From: "Keyur Patel (keyupate)" <[email-masked]>
Date: Wed, 20 Jul 2016 21:11:44 +0000

Hi Jie,

Comments inlined #Keyur1

From: "Dongjie (Jimmy)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 20, 2016 at 12:45 AM
To: Keyur Patel <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Fwd: Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt

Hi Keyur,

Robert, Dongjie,

Comments inlined #Keyur

Hi Jie,

[Jie2]: This was also my understanding in the beginning of writing the one-time orf drafts. However since you need traffic filters for this “selective refresh”, you will find out it is already there with ORF, then you will want to reuse the filters. Actually it is something between the traditional refresh and the traditional ORF,  IMO the name does not really matter, the important thing is we can reuse what already exists.

#Keyur1: We could definitely work towards reusing what is there or merging some of the work. :)

#Keyur: Ack.

[Jie2] For the concurrent refresh part, could you elaborate in which case it will be needed? The draft says “The BGP speaker responding to  the route refresh requests MAY perform the refreshes in parallel”, do you mean the route updates for different selective refresh requests may be interleaved?

#Keyur1: Exactly! More specifically a bgp speaker may be re-announcing route updates as part of multiple different refresh requests (same or with overlapping filters)).

Best Regards,
Keyur

Best regards
Jie

Regards,
Keyur

Many thx,
R.

Resending ...

---------- Forwarded message ----------
From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jul 11, 2016 at 3:04 PM
Subject: Re: [Idr] Slot request in IDR to present https://www.ietf.org/internet-drafts/draft-idr-bgp-route-refresh-options-00.txt
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>

Best regards,
Jie

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Jul 2016 00:14:40 +0200

Hi Keyur,

On the EVPN topic which defines BGP protocol extensions without any IDR WG
review the more I hear about cases like you bring below (and this is not
the first one btw) the more I think it is really quite badly designed.

And such bad protocol extensions should not be a justification to introduce
even more questionable knobs in BGP.

In this specific case just get all SAFI refreshed modulo to RTC or ORF
filters and you are done. Case solved :).

Best,
R.

On Wed, Jul 20, 2016 at 11:05 PM, Keyur Patel (keyupate) <[email-masked]

> Hi Robert,
>
> One interesting use case is with EVPN address family where a new
> route-type is introduced without a capability.  A PE may have had safi
> enabled but not have accepted its route-type (or set of route-types) all
> mapping to a same RT. A transactional filter attempts to solve it.
>
> To: Keyur Patel <[email-masked]>
> Cc: "Dongjie (Jimmy)" <[email-masked]>, idr wg <[email-masked]>
> The other point is that "permanent" are not really permanent anyway ..
> they are installed from update to withdraw of a given filter - regardless
> what filtering mechanism you choose (ORF, RTC, XYZ ...). And if you go with
> the notion that permanent are sufficient the entire aparatus allowing you
> to have concurrent route refresh requests in flight goes away :)
>
> #Keyur: Ack your right. My reference to a permanent filter was in context
> of a session life time and I agree with you that it could be modified or
> withdrawn at any given time. I was trying to differentiate it from
> transactional filters.
>
> Regards,
> Keyur
>
> Thx,
> r.
>
>
> On Wed, Jul 20, 2016 at 12:18 AM, Keyur Patel (keyupate) <
> [email-masked]> wrote:
>
>> Robert, Dongjie,
>>
>> Comments inlined #Keyur
>>
>>> We didn't discuss that one through but the only logical conclusion for
>>> me is that the ORF/CP-ORF installed are respected (i.e. it's an implicit
>>> AND). I see ORF as statefull, remote-pushed policy on the peer that is not
>>> being flipped around all the time (albeit AFAIR there were some attempts @

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 21 Jul 2016 08:41:34 -0700

Read the "longish" thread by now and between all this "let's do
filter/let's do pull (refresh)" I try to take a step back to see the forest:

a) To validate Niloo's point: 'f an implementation chooses to drop things
based on configuration/policy (multicast EVPN routes) extending ORF will
cause a complete refresh of EVPN (including type-2 MACs) unless you go and
"install filter type-2, then refresh, then remove-filter-2" and after
requesting type-6  (you can't defer remove-filter-2 step, otherwise you
won't receive type-2 updates anymore!) floods you with all MACs. Pub-sub
with a single "filter-list" is simply NOT a good model to request arbitrary
pieces of routes missing (which is where the world is going, BGP database
is sharding to the point specs are recommending to "drop when you don't
need it" and we have the need to ask for very specific sets @ given points
in time [as the use cases describe]).

b) A much _bigger_ problem IMO is the fact that ORF language does not seem
to be an algebra, it's a program and you can only build a closure of
procedural programs by running them normally (not good to restrict sets you
process). In less abstract terms a refresh with filters that are OR'ed and
AND'ed (first order logic transitive closure) determines the cone you need
to walk on the RIB very easily (people implementing heavy-duty BGP will
know precisely what that means) whereas any change to the filter will cause
a full walk on the RIB possibly (in case of arbitrary mix of accepts and
rejects) without a lot of possibly hard logic to write (I didn't think
fully through it but I think it may be actually possible to write something
delivering closure from a generic ORF filter so it's an interesting
discussion). Even if you can build the closure, you can only run one at a
time (one ORF filter) unless the peer does some crazy state-ful query
optimization language to do wonders to squeeze multiple queries it needs
into a single ORFs it's doing (SQL query optimizers are _really_ complex
beasts) while the "you can put a filter on something to suppress it on
refresh but you can hammered with it anyway the moment you remove it"
persists.

For that 2 cases my take  is that it's better to move towards the model
proposed by a "filtered refresh" (independently of being co-author) rather
than a 'pub-sub'.

As ultimate, wider angle view of the world.

BGP will be offered more cycles to run (it already is ) but not in the form
of a single faster and faster CPU anymore but in form of multiple
cores/machines. A set of filtered refreshes can be parallelized fairly
easily when requested. A single ORF filter being manipulated on/off will as
described in a) possibly cause huge spurious refreshes and in b) a single
threat of execution serializing the synchronization between peers.

I hope that all can be parsed ...

Very good discussion overall no matter which way it goes ...

--- tony

On Wed, Jul 20, 2016 at 3:14 PM, Robert Raszuk <[email-masked]> wrote:

> And such bad protocol extensions should not be a justification to
> introduce even more questionable knobs in BGP.
>
> On Wed, Jul 20, 2016 at 11:05 PM, Keyur Patel (keyupate) <
>>> #Keyur: ORFs are permanent filters. We wanted to decouple the
>>> transaction based filters (one time per refresh) from the permanent filters
>>> and hence chose to modify refresh message as opposed to an ORF.
>>>
>>> I am not that much convinced if one time ORF is needed as you are free
>>> to INSTALL and REMOVE ORF effectively producing one time behavior.
>>>
>>> #Keyur: Ack.
>>>
>>>> *We’ve heard that a million monkeys at a million keyboards could
>>>> produce the complete works of Shakespeare; now, thanks to the Internet, we
>>>> know that is not true.*
>>>>
>>>> —Robert Wilensky
>>>>
>>>
>>>
>>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Jul 2016 17:50:03 +0200

Tony,

You have nicely summarized various discussed this week sub threads
happening bith on and off the list.

Except .. you did not list the most important .. to enumerate real protocol
level use cases which would justify this addition.

If we start with the problem (rather then just starting with "when we need
subset of routes") then perhaps it will be easy to adopt this work or we go
back and fix protocol encoding which are root cause of the problem you are
trying to patch with solutions like selective overlapping route refresh
messages.

Best,
R.

On Jul 21, 2016 5:42 PM, "Tony Przygienda" <[email-masked]> wrote:

--- tony

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 21 Jul 2016 09:05:49 -0700

Robert, in the draft there are enough of first examples, I repeated several
times other ones we were seeing outside the idr room and later and each
time it seems it is being dismissed and discussion goes into abstract
"let's do publish-subscribe because it's better". So I won't repeat all
that again. I suggest we will update the draft with more and more of stuff
we saw and justified talking about it.

You didn't respond to any of the "what to do with type-6 refresh" or "how
will I make one ORF filter update multiple subsets [possibly disjoint] I
need to refresh without getting flooded to death with the AFI/SAFI stuff"
and "how will I implement ORF except a full walk on any change" which
happen to be pretty massive issues if you want decent BGP convergence on
more and more AFI/SAFIs, routes, types & other zoo sneaking upon BGP ...

sorry if I'm a tad acerbic ...

--- tony

On Thu, Jul 21, 2016 at 8:50 AM, Robert Raszuk <[email-masked]> wrote:

> Except .. you did not list the most important .. to enumerate real
> protocol level use cases which would justify this addition.
>
> BGP will be offered more cycles to run (it already is ) but not in the
> form of a single faster and faster CPU anymore but in form of multiple
>> On the EVPN topic which defines BGP protocol extensions without any IDR
>> WG review the more I hear about cases like you bring below (and this is not
>>> The missing part seems to be justification if we really need
>>> "transaction based filters" as opposed to simply having permanent ones.
>>>
>>> #Keyur: Ack your right. My reference to a permanent filter was in
>>> context of a session life time and I agree with you that it could be
>>> modified or withdrawn at any given time. I was trying to differentiate it
>>> from transactional filters.
>>>
>>> Regards,
>>> Keyur
>>>
>>> Thx,
>>> r.
>>>
>>>
>>>> To me what is perhaps missing is just a new draft to define *Route
>>>> Type* ORF to address some of those EVPN new NLRI encodings.
>>>>
>>>> #Keyur: There are modifications needed if the refresh is going to be
>>>> for selective prefixes only. Furthermore, if we want to support multiple
>>>>> The motivation for this work were scenarios where a single-shot
>>>>> refresh is needed, actually concurrent bunch of those based on
>>>>> configuration changes, peer having dropped received routes based on specs
>>>>> (A-D), in policy changes, joining VPNs, EVIs and so on. Putting ORF on a
>>>>> peer, refresh and remove ORFs is significantly heavier process that may
>>>>> interfere on top with normal update process going on and needs to be done
>>>>> one-by-one (since you have to wait for single BoRR/EoRR pair) unless one is
>>>>> very smart about combining ORF possibly & playing with the
>>>>> DEFER/IMMEDIATEs. As we indicated, if the AFI/SAFI is covered by RTC and
>>>>> RTC is supported & one is willing to configure RTs for each subset of
>>>>> routes that may need refreshing, RT will be doing the same job just fine.
>>>>>
>>>>>
>>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Jul 2016 18:22:45 +0200

Tony,

Sorry to be a bit stubborn here but I have not seen any valid reason for
this work.

Yes you have listed bunch if reasons in the original reply but non of those
apply.

Quoted below from your mail all below reasons require permanent filter not
one time as you must not only get the NLRI once .. you MUST also get all
updates to it when something changes supposedly also in subset way -
otherwise you get all SAFI (all MACs which is what you are trying to avoid
in the first place).

That is critical which you seems to be missing.

The debug thing is not sufficient justification.

Moreover as you confirm this work is not compatible with RTC and as you
confirmed you will not get anything over RTC filter in place. So to use one
time refresh RTC needs to be effectively disabled.

Your reasons:

"The motivation for this work were scenarios where a single-shot refresh is
needed, actually concurrent bunch of those based on configuration changes,
peer having dropped received routes based on specs (A-D), in policy
changes, joining VPNs, EVIs and so on. "

Thx,
R.

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 22 Jul 2016 01:52:21 -0700

Robert, fine, agreed to disagree. We see over next rev of the draft ...

We will extend section 1.1. further and frankly, I think it's sufficient
today (otherwise we wouldn't bother wasting our time writing/figuring that
out).

RD we need wildcard semantics, beside that I agree that there isn't
necessary enough justification for RD otherwise without assuming further
semantics overload of RDs (bad thing). So maybe not allowing and RD
options/filter and saying "RD is implied wildcard" is good enough. My
feeling tells me it's not but it can be added later.

I cannot parse the RTC comment you're making really. I suggest to
distinguish very tightly between "querying", "registering" and "filtering".

RTC is a intermixed "registration/filtering" mechanism, refresh is a
"querying" mechanism. I think we'll add RTs to the filters for the option
refresh and with that you can either "register via/filter RTCs" _or_
specifically request refresh for an RTC (which will be filtered by existing
RTCs since RTC is the "overall filtering").

registering is good if you want full refresh of something beside initial
open but the filters must be very orthogonal to do it efficiently and
decoupled from each other (transactional) while RTC is simply a accept/deny
language which is hard to closure compute (sorry, can't save the linear
programing vs. transitive closure algebra distinction here and if it's not
clear it will become painfully clear in implementation only).

filtering is the NOT of registering really and RTC is a ball-of-hair where
the deny are really "NOTs" and possibly filters rather then registers.
While empty RTC is a "register all" implicitly.

Refresh is querying. Something pretty different from "register". Semantics
is "I may have registered (implicitly) but I may have filtered on my side
for some reason and now I need the information again". Yes, one can play
great games with filtering/registering to emulate querying as one can
surely use screwdrivers to open tin cans. A very orthogonal algebra of
independent RTC filters would have been possibly equivalent to the route
refresh options but alas between the accept/reject/defer/immediate I would
always chose to have a clean "orthogonal filter transactional query"
architecture here ... (sorry, I speak databas'ish here since this is all
really a big partitioned/distributed/loosely synchronized database problem
and has nothing to do really with BGP carrying the bits).

Your answers to "on RTC change you'll get flooded with all the stuff again"
and "how do I get type-6 only without causing subsequent flooding when I
unwind the RTC filter" are still surepitiously missing.

If your  point "you never _query_ in BGP, we SHALL only register" then
route-refresh was the battle to be fought, this particular Rubicon has been
crossed long time ago as you know (and it took good many years until a
similar discussion I had a _looong_ time ago about "you need Begin
Transaction/End Transaction" and was ignored caused enough real pain to
lead to Extended Route Refresh).

no, to nastepnej wersi ;-) ;-)

--- tony

On Thu, Jul 21, 2016 at 9:22 AM, Robert Raszuk <[email-masked]> wrote:

> Yes you have listed bunch if reasons in the original reply but non of
> those apply.
>
> "The motivation for this work were scenarios where a single-shot refresh
> policy changes, joining VPNs, EVIs and so on. "
>
> Thx,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 24 Jul 2016 16:22:08 +0200

Dear Antoni,

The point here is not about the question if query in BGP is good or bad or
how easy or difficult it is to implement.

The points to discuss are following:

#1 What parameters are used to "query" ?

#2 How does defined "query" work with existing BGP protocol and extensions ?

#3 What protocol state machine change triggers "query" action ?

- - -

Ad 1 -

Cool that we have already accomplished consensus to get rid of RD query. If
you do not specify anything the automatic assumptions would be *ANY* RD
anyway if you query by anything other then NLRI prefix. Query by NLRI is
questionable too (see below Ad 3).

Now let's talk about (in)famous EVPN route types you keep bringing as query
parameter. Please observe that RFC7432 does not define BGP capability per
route type and only negotiates 25/70 implicitly indicating support of all
route types. Moreover RFC7432 is very clear that to accomplish filtering of
routes on the sender side use of RTC is recommended.

Ad 2 -

Assume operator is using RTC so list of RT filters is populated by the peer
outbound towards querying bgp speaker. Now issuing query for anything needs
to be evaluated against already supported Enhanced Route Refresh (RFC7313)
which btw you are also obsoleting here where you get full filtered by RTC
list of interesting NLRIs for specific AFI/SAFI.

On the topic of obsoleting RFC2918 I must say that I hope this is just a
huge oversight ... Your current draft says:

"When the Route Refresh Options Capability has been negotiated by both
sides of a BGP session, both peers MUST use message types 3, 4 and 5."

And message type 3 clearly states that I must have at least one refresh
option ... quote from the field of the msg: "One or more Route Refresh
Options"

That means that I no longer can ask for refresh of the entire AFI/SAFI -
this is pretty bad.

Ad 3 -

Now the crux of all of this ...

Please enumerate on the list or in the draft what exact protocol state
machine transitions will result in automated query for subset of given
AFI/SAFI with and without prior use of RTC and ORF filters.

In other words I do not buy general justifications explained before, quote:

* "now I need the information again"

* " The motivation for this work were scenarios where a single-shot refresh
is needed, actually concurrent bunch of those based on configuration
changes,

--> You need per AFI/SAFI or per RT refresh

" in policy changes, joining VPNs, EVIs and so on."

--> You need per AFI/SAFI or per RT refresh

- - - - - -

Conclusion:

Asking for subset of AFI/SAFI routes based on specific query does not in
any way allows to assure that you will get full set of routes which are
actually needed for correct operation.

BGP standardized use of Route Target Ext Community to filter routes both on
inbound as well as optimize it also outbound. If you modify RT import
policy say you add one RT I agree that asking for just that one RT may be
much better - but here RTC is exactly what comes as solution as generating
one update in SAFI 132 will result in getting such delta of routes.

It also needs to be stated that there is no overhead to add few RTs (one
per NLRI type) for those new address families which bring the concept of
NLRI types (EVPN, BGP-LS etc ...) hence the objectives of this work can be
easily achieved today with existing specifications.

Best regards,
Robert.

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 24 Jul 2016 23:18:59 +0200

inline

On Sun, Jul 24, 2016 at 4:22 PM, Robert Raszuk <[email-masked]> wrote:

> Cool that we have already accomplished consensus to get rid of RD query.
> If you do not specify anything the automatic assumptions would be *ANY* RD
> Now let's talk about (in)famous EVPN route types you keep bringing as
> query parameter. Please observe that RFC7432 does not define BGP capability
> per route type and only negotiates 25/70 implicitly indicating support of
> all route types. Moreover RFC7432 is very clear that to accomplish
> filtering of routes on the sender side use of RTC is recommended.
>
>
I think I admitted that getting rid of RD query is reasonable (as long we
understand that any other query means "any RD")

If you think asking for a new route-type in EVPN via AFI/SAFI refresh and
being swamped with all MAC updates is a reasonable deployment option then
we simply disagree and the operational world will tell us what is
reasonable.

>
> Ad 2 -
>
> Assume operator is using RTC so list of RT filters is populated by the
> peer outbound towards querying bgp speaker. Now issuing query for anything
> needs to be evaluated against already supported Enhanced Route Refresh
> (RFC7313) which btw you are also obsoleting here where you get full
> filtered by RTC list of interesting NLRIs for specific AFI/SAFI.
>

Absolutely valid, albeit subtle point. "zero or more route refresh options"
should be specified.

Obsoleting 70 when 74 is present is simplifying things. We can keep mixture
of 70 and 74 but implementation will get pretty hairy when you talk
details. We talked that through with Cisco co-authors @ length and actually
changed from "you can do both in parallel" to "nah, 74 obsoleting 70 is
much better/cleaner/easier".

> AFI/SAFI with and without prior use of RTC and ORF filters.

section 1.1. in the draft and to be extended

> * " The motivation for this work were scenarios where a single-shot
> configuration changes,

ok, then as I said, we agree to disagree and then we don't have currently a
really practical solution to the cases mentioned in 1.1 and yes, RTC can be
used for that if you're willing to maintain RTs for all possible sets you
may need to refresh and the draft very explicitly acknowledges that
already. Given you know those sets upfront. If you deploy EVPN today and
new route type gets introduced (type-6) you better go and reconfigure all
your routers in the networks with this type-6-per-EVI=a new RT knowledge to
satisfy the "I need now type-6 routes for the EVIs I configured for
multicast" use case. Quite a lot of configuration there since it's
combinatorial with every parameter.

Extending ORF with new filters will lead due to the accept/reject
non-computable language to full walks of which you can have one in parallel
in ORF and you chose to not answer any of the "and then you'll get flooded
on change of ORF filter anyway" observations which leads overall to an
interesting, partial treatment of the subject.

Frankly, the arguments we are engaged in are becoming repetitive by now, we
should close this discussion and see whether implementation/acceptance by
major vendors given the pressure of deployment cases we listed will lead to
acceptance or the draft will linger ...

--- tony

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 24 Jul 2016 23:31:49 +0200

​Hey Tony,​

> understand that any other query means "any RD")

​Done.

> should be specified.

​Great.​

> much better/cleaner/easier".

​Yes one
​SAFI ​
is much cleaner, but you can't break per AFI/SAFI refresh. ​
​So now I consider this fixed. ​

> ok, then as I said, we agree to disagree and then we don't have currently
> a really practical solution to the cases mentioned in 1.1 and yes, RTC can
> be used for that if you're willing to maintain RTs for all possible sets
> you may need to refresh and the draft very explicitly acknowledges that
> already.
>

​Possible sets .. hmmm how about this to address route types:

1 RT per route type of a given AFI/SAFI ... not much burden at all - for
EVPN you burn 5-6 RTs for entire network. ​

> Given you know those sets upfront. If you deploy EVPN today and new route
> type gets introduced (type-6) you better go and reconfigure all your
> routers in the networks with this type-6-per-EVI=a new RT knowledge to

​Not at all .. forgot that RTs can be applied on RR per route type of NLRI
on inbound. Your colleagues already defined that in the other work :) ​

Minimal configuration, existing protocols and all benefits.

Cheers,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 29 Jul 2016 02:18:17 +0000

Just reading some of this.
A limited refresh is NOT the same thing as "Apply the ORF then remove it".
Suppose you want to refresh a subset of the routes.
You send an ORF to permit only the subset.
You receive the subset.
Now you remove the ORF.
You receive the whole table.
NOT what you wanted.

Also, the use case is good.
The receiver dropped some routes due to policy.
The receiver changed the policy.
Now it wants a repeat of the previously dropped routes.
This is not a use case for ORF or RTC.
The thing is that ORF or RTC were already passing those routes, so changing them is nonsense.

Thanks,
Jakob.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 Jul 2016 09:45:39 +0200

Hi Jakob,

See inline ...

> You receive the whole table.

​If this is what your implementation does then I recommend you fix it
first.

For Match = DENY ​REMOVE action should result in *only* advertisement of
previously filtered entries.

For Match = PERMIT REMOVE action should result in *only* the delta between
whole table and remaining ORF entries.

​In no case you get the whole table (other then removal of last ORF PERMIT
entry). ​

> changing them is nonsense.

​For this case you use Enhanced Route Refresh. As result you get those
NLRIs which pass ORF or RTC the filters on a per AFI/SAFI basis.

You have to be able to handle it anyway as when you boot you will get.

If you pushed your prefix list with ORF then removing it will get you the
delta.

If you filtered based on import RT then advertising RT in ORF or RTC will
get you the delta.

So in what exact protocol cases you envision use case for this scoped one
time refresh ? And what exactly in your opinion should be the list of
parameters used to perform a query ?

Best,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 29 Jul 2016 10:12:59 +0000

Wrong. RFC 5291 says:

The speaker MUST re-advertise all the routes that have been
   affected by the ORF entries carried in the message, but MAY also re-
   advertise the routes that have not been affected by the ORF entries
   carried in the message.

Thanks,
Jakob.

On Jul 29, 2016, at 12:45 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jakob,

See inline ...

On Fri, Jul 29, 2016 at 4:18 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

?If this is what your implementation does then I recommend you fix it first.

For Match = DENY ?REMOVE action should result in *only* advertisement of previously filtered entries.

For Match = PERMIT REMOVE action should result in *only* the delta between whole table and remaining ORF entries.

?In no case you get the whole table (other then removal of last ORF PERMIT entry). ?

?For this case you use Enhanced Route Refresh. As result you get those NLRIs which pass ORF or RTC the filters on a per AFI/SAFI basis.

If you pushed your prefix list with ORF then removing it will get you the delta.

If you filtered based on import RT then advertising RT in ORF or RTC will get you the delta.

So in what exact protocol cases you envision use case for this scoped one time refresh ? And what exactly in your opinion should be the list of parameters used to perform a query ?

Best,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 29 Jul 2016 10:37:25 +0000

And to clarify, that means all routes permitted after the ORF message is processed MUST be re-advertised. It doesn't matter whether the action was add or remove.

Also, when you remove the last permit, you get nothing. It's like after session establishment: if the ORF capability was negotiated, nothing is sent until the first permit is received.

Thanks,
Jakob.

On Jul 29, 2016, at 3:12 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

Wrong. RFC 5291 says:

Thanks,
Jakob.

Hi Jakob,

See inline ...

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 29 Jul 2016 13:30:42 +0200

Jakob,

I did not make any judgement who is right and who is wrong. You did so let
me explain where you are missing it.

#1 - As someone wisely said at the last IETF MAY = MAY NOT hence if spec
contains MAY it equally well could be interpreted in the opposite way.
Enough to say this is not a base to make any right or wrong judgement.

#2 - This entire thread as well as this draft in question is all about
optimization. I must repeat that there is no problem in the first place so
receiving all routes in a given SAFI modulo ORF or RTC filter is just fine.
During policy change you issue Enhanced Route Refresh.

However If this is not fine then I recommend to fix those inefficient
implementations which are generating excess of messages in the BGP UPDATE
rather then putting another layer of questionable band-aid on top of it.

Thx,
R.

On Fri, Jul 29, 2016 at 12:12 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> On Jul 29, 2016, at 12:45 AM, Robert Raszuk <[email-masked]> wrote:
>
> Hi Jakob,
>
> See inline ...
>

---

From: Niloofar Fazlollahi <[email-masked]>
Date: Mon, 1 Aug 2016 06:19:56 +0000 (UTC)

Hi Robert,In response to your comment:"If you pushed your prefix list with ORF then removing it will get you the delta. 
If you filtered based on import RT then advertising RT in ORF or RTC will get you the delta. 
So in what exact protocol cases you envision use case for this scoped one time refresh ? And what exactly in your opinion should be the list of parameters used to perform a query ? "
There is also the case that policy is enforced locally, nor ORF and neither RTC, e.g., route-map in with deny prefix-list.
Once the policy is removed, with cap 74, speaker can request refresh of only the previously denied prefixes.How to implement this optimization with ORF? 
Based on your previous email:"For Match = PERMIT REMOVE action should result in *only* the delta between whole table and remaining ORF entries. "

If we send a PERMIT ADD for those prefixes and then PERMIT REMOVE, we will be refreshed with the whole AFI/SAFI assuming no other ORF is added previously.

Regards,Niloofar

    On Friday, July 29, 2016 4:30 AM, Robert Raszuk <[email-masked]> wrote:

 Jakob,
I did not make any judgement who is right and who is wrong. You did so let me explain where you are missing it. 
#1 - As someone wisely said at the last IETF MAY = MAY NOT hence if spec contains MAY it equally well could be interpreted in the opposite way. Enough to say this is not a base to make any right or wrong judgement. 
#2 - This entire thread as well as this draft in question is all about optimization. I must repeat that there is no problem in the first place so receiving all routes in a given SAFI modulo ORF or RTC filter is just fine. During policy change you issue Enhanced Route Refresh.
However If this is not fine then I recommend to fix those inefficient implementations which are generating excess of messages in the BGP UPDATE rather then putting another layer of questionable band-aid on top of it. 
Thx,R.
On Fri, Jul 29, 2016 at 12:12 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:

Wrong. RFC 5291 says:The speaker MUST re-advertise all the routes that have been
   affected by the ORF entries carried in the message, but MAY also re-
   advertise the routes that have not been affected by the ORF entries
   carried in the message.
Thanks,
Jakob.

Hi Jakob,
See inline ... 
On Fri, Jul 29, 2016 at 4:18 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:

Just reading some of this.A limited refresh is NOT the same thing as "Apply the ORF then remove it".Suppose you want to refresh a subset of the routes.You send an ORF to permit only the subset.You receive the subset.Now you remove the ORF.You receive the whole table.NOT what you wanted.

​If this is what your implementation does then I recommend you fix it first. 
For Match = DENY ​REMOVE action should result in *only* advertisement of previously filtered entries. 
For Match = PERMIT REMOVE action should result in *only* the delta between whole table and remaining ORF entries. 
​In no case you get the whole table (other then removal of last ORF PERMIT entry). ​

Also, the use case is good.
The receiver dropped some routes due to policy.The receiver changed the policy.Now it wants a repeat of the previously dropped routes.This is not a use case for ORF or RTC.The thing is that ORF or RTC were already passing those routes, so changing them is nonsense.

​For this case you use Enhanced Route Refresh. As result you get those NLRIs which pass ORF or RTC the filters on a per AFI/SAFI basis. 

Best,R.