Subject: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

From: Robert Raszuk <[email-masked]>
Date: Wed, 15 Jul 2020 20:26:01 +0200

Dear Aijun & Wei,

I have read your draft as per subject.

I think there is a serious misunderstanding on what RD's role is
in RFC4364.

RDs MUST never be used to signal anything which would in any way influence
what routes are distributed where. Their sole role is to make the VPN
prefix unique across given VPN's domain.

It is RTs which are used to import routes to VRFs on PEs. What you are
trying to do is exactly why we have defined some time back RTC (RFC4684).
Applications from section 5.1 and 5.2 can be happily addressed with use of
RTC.

Informationally let me also point out that RFC7543 has defined extensions
to ORF to signal RTs for reducing size VPN RIBs in specific Hub & Spoke
topologies.

Last your proposal calls for treating ORF as a transitive message without
any loop protection. That is not a good idea.

I recommend to protect your PEs from being overwhelmed by VPN routes by
prefix limit instead.

Kind regards,
R.

PS. Did we have any discussion in IDR or BESS on this proposal ?

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 16 Jul 2020 10:40:28 +0800

Hi, Robert:

Thanks for your reviews and comments.

As you said, RD is to make the VPN prefix unique within the VPN’s domain. It can also be used to identify the VPN customer.

The usage of RT, just as you said, is to control what routes are distributed where, that is to say, to control the customer’s VPN topology. RT can’t be used to identify one VPN customer.

The scenarios/problems described in this draft(https://tools.ietf.org/html/draft-wang-idr-rd-orf-00) are not for the VPN topology control, but for the VPN prefix limit management, which is signed along with the agreement with the VPN customer.

This is the reason that we select the RD-based ORF control mechanism.

More detail reply are inline below. Wish to get more your comments/suggestions on them.

Thanks in advance.

Best Regards

Aijun Wang

China Telecom 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 2:26 AM
To: [email-masked]; Aijun Wang <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Dear Aijun & Wei,

I think there is a serious misunderstanding on what RD's role is in RFC4364. 

RDs MUST never be used to signal anything which would in any way influence what routes are distributed where. Their sole role is to make the VPN prefix unique across given VPN's domain. 

【WAJ】RD can be used to identify one VPN customer

It is RTs which are used to import routes to VRFs on PEs. What you are trying to do is exactly why we have defined some time back RTC (RFC4684). Applications from section 5.1 and 5.2 can be happily addressed with use of RTC. 

【WAJ】RT is used to control VPN topology, same as the mechanism of RTC(4684). But the application described in section 5.1 and 5.2 of this draft is not for VPN topology control, but for VPN route-limit management, which is based on customer/RD.

Informationally let me also point out that RFC7543 has defined extensions to ORF to signal RTs for reducing size VPN RIBs in specific Hub & Spoke topologies. 

【WAJ】RFC7543 is to pull the prefix that cover one specific host address, to get the more optimal route information from the Hub, not the same scenarios as described in the current draft.

Last your proposal calls for treating ORF as a transitive message without any loop protection. That is not a good idea. 

【WAJ】ORF messages are exchanged within only the directed BGP sessions. Such Messages will be regenerated when it is needed to send to another BGP peer.  Would you like to describe more for the loop scenarios? 

I recommend to protect your PEs from being overwhelmed by VPN routes by prefix limit instead. 

【WAJ】Prefix Limit mechanism can be used for Option –A, but not for Option B/C, as that described in the draft.

Kind regards,

R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Jul 2020 09:06:27 +0200

> It can also be used to identify the VPN customer.

Sorry but no.

Best practice for number of reasons is to make RD unique per VRF and not
per VPN. We should not standardize something which is a pretty bad idea to
start with.

Kind regards,
Robert

On Thu, Jul 16, 2020 at 4:40 AM Aijun Wang <[email-masked]>
wrote:

> As you said, RD is to make the VPN prefix unique within the VPN’s domain.
> It can also be used to identify the VPN customer.
>
> The usage of RT, just as you said, is to control what routes are
> distributed where, that is to say, to control the customer’s VPN topology.
> RT can’t be used to identify one VPN customer.
>
>
>
> The scenarios/problems described in this draft(
> https://tools.ietf.org/html/draft-wang-idr-rd-orf-00) are not for the VPN
> topology control, but for the VPN prefix limit management, which is signed
> along with the agreement with the VPN customer.
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Thursday, July 16, 2020 2:26 AM
> *To:* [email-masked]; Aijun Wang <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>
> *Subject:* [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> Dear Aijun & Wei,
>
>
>
> 【WAJ】RT is used to control VPN topology, same as the mechanism of
> RTC(4684). But the application described in section 5.1 and 5.2 of this
> draft is not for VPN topology control, but for VPN route-limit management,
> which is based on customer/RD.
>
>
>
> 【WAJ】RFC7543 is to pull the prefix that cover one specific host address,
> to get the more optimal route information from the Hub, not the same
> scenarios as described in the current draft.
>
>
>
> 【WAJ】ORF messages are exchanged within only the directed BGP sessions.
> Such Messages will be regenerated when it is needed to send to another BGP
> peer.  Would you like to describe more for the loop scenarios?
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 16 Jul 2020 16:58:32 +0800

Hi, Robert:

When the RD is designed as per VRF per PE, the mechanism of RD based ORF can also apply-------The received router needs only extract and reflect the most influenced RDs back to upstream router(ASBR/RR),  and then to notify the source of these VPN routes to control the prefixes advertisement.

Actually, the above design will make the RD-ORF more accurate than the RT based control.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 16, 2020 3:06 PM
To: Aijun Wang <[email-masked]>
Cc: [email-masked]; Aijun Wang <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Sorry but no. 

Best practice for number of reasons is to make RD unique per VRF and not per VPN. We should not standardize something which is a pretty bad idea to start with. 

Kind regards,

Robert

 

On Thu, Jul 16, 2020 at 4:40 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

Thanks in advance.

Best Regards

Aijun Wang

China Telecom 

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 2:26 AM
To: [email-masked] <mailto:[email-masked]> ; Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: idr@ietf. org <[email-masked] <mailto:[email-masked]> >
Subject: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Dear Aijun & Wei,

Kind regards,

R.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 16 Jul 2020 14:26:38 +0000

A combination of RTs can identify a VPN customer regardless of topologies being deployed. Our systems are able to figure out which paths belong to which customers. RD is used to make a prefix unique.  Using RT Constrain reduces the scope of an advertisement to interested topologies or subsets of topologies based upon the distribution of a set of VRFs.  Not sure what you want to do here.

Thanks,
              Jim Uttaro

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 3:06 AM
To: Aijun Wang <[email-masked]>
Cc: Aijun Wang <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Sorry but no.

Kind regards,
Robert

On Thu, Jul 16, 2020 at 4:40 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert:

Thanks for your reviews and comments.
As you said, RD is to make the VPN prefix unique within the VPN’s domain.. It can also be used to identify the VPN customer.
The usage of RT, just as you said, is to control what routes are distributed where, that is to say, to control the customer’s VPN topology. RT can’t be used to identify one VPN customer.

The scenarios/problems described in this draft(https://tools.ietf.org/html/draft-wang-idr-rd-orf-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=6Jx4PFr3kh7DSy7LLkZ1DmONh26T4r4vIvfywUjoADQ&s=wpUrfSxySaPTcmxZL0kjc02l9rFO1pwxpb7mCfphW60&e=>) are not for the VPN topology control, but for the VPN prefix limit management, which is signed along with the agreement with the VPN customer.
This is the reason that we select the RD-based ORF control mechanism.

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 2:26 AM
To: [email-masked]<mailto:[email-masked]>; Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=6Jx4PFr3kh7DSy7LLkZ1DmONh26T4r4vIvfywUjoADQ&s=wpUrfSxySaPTcmxZL0kjc02l9rFO1pwxpb7mCfphW60&e=>

Dear Aijun & Wei,

Informationally let me also point out that RFC7543 has defined extensions to ORF to signal RTs for reducing size VPN RIBs in specific Hub & Spoke topologies..
【WAJ】RFC7543 is to pull the prefix that cover one specific host address, to get the more optimal route information from the Hub, not the same scenarios as described in the current draft.

Kind regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Jul 2020 21:20:34 +0200

Aijun,

I do understand that you want to push in RD-ORD pre import RDs. Perhaps
selecting first those which advertise the most VPN routes.

But this is so severely broken idea that I am not sure how to even
describe it. Just imagine the mess of now partially broken VPN users which
asked for full mesh and got now partially working and partially broken
mesh.

This would be also terrible to troubleshoot (even assuming that you would
refrain from RD-ORF propagation).

Bottom line - to control number of VPN routes - for years operators have
deployed prefix limit on ingress to the SP network (PE-CE edge). Once
prefix is accepted into a network it better be installed when VPN topology
requires it.

Filtering per RD is a really BAD IDEA.

Thx,
R.

On Thu, Jul 16, 2020 at 10:58 AM Aijun Wang <[email-masked]> wrote:

> Hi, Robert:
>
>
>
> When the RD is designed as per VRF per PE, the mechanism of RD based ORF
> can also apply-------The received router needs only extract and reflect the
> most influenced RDs back to upstream router(ASBR/RR),  and then to notify
> the source of these VPN routes to control the prefixes advertisement.
>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* Thursday, July 16, 2020 3:06 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* [email-masked]; Aijun Wang <[email-masked]>;
> idr@ietf. org <[email-masked]>
> *Subject:* Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> distributed where, that is to say, to control the customer’s VPN
> topology. RT can’t be used to identify one VPN customer.
>
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 16 Jul 2020 21:22:08 +0000

I can see how you might want to do max-prefix filtering by RD.
Suppose there are many PEs in an AS that all have VRFs for the same VPN,
but only one of them is sending too many routes.
In that case, you can't filter just that one VRF by RT.
You need RD.
Sure, you will end up with partial routes and a bit of a mess, as Robert points out, but that's the nature of max-prefix anyway. It is a safety valve that prevents a big disaster by causing a smaller disaster.

One thing I do see a problem with is that the RR or ASBR propagates
a received ORF back to the source of the routes.
That RR or ASBR may have other clients that still want the routes.
ORFs are not designed to be propagated.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 12:21 PM
To: Aijun Wang <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

I do understand that you want to push in RD-ORD pre import RDs. Perhaps selecting first those which advertise the most VPN routes.

But this is so severely broken idea that I am not sure how to even describe it. Just imagine the mess of now partially broken VPN users which asked for full mesh and got now partially working and partially broken mesh.

This would be also terrible to troubleshoot (even assuming that you would refrain from RD-ORF propagation).

Bottom line - to control number of VPN routes - for years operators have deployed prefix limit on ingress to the SP network (PE-CE edge). Once prefix is accepted into a network it better be installed when VPN topology requires it.

Thx,
R.

On Thu, Jul 16, 2020 at 10:58 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert:

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> [mailto:robert@raszuk..net<mailto:[email-masked]>]
Sent: Thursday, July 16, 2020 3:06 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Sorry but no.

Kind regards,
Robert

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

Dear Aijun & Wei,

Kind regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Jul 2020 23:57:30 +0200

> but only one of them is sending too many routes.

Well PEs do not produce routes all by themselves :)

They receive it from CEs. /* Likewise ASBRs option B receive it from
other ASBRs. */

So one's network should be able to handle an agreed number of routes as
defined in VPN service. For anything above that in order to protect PE
control and data planes prefix limit is the tool to apply towards your
local peers which could result with src session down till NOC diagnoses the
issue.

Thx,
R.

On Thu, Jul 16, 2020 at 11:22 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> Sure, you will end up with partial routes and a bit of a mess, as Robert
> points out, but that's the nature of max-prefix anyway. It is a safety
> valve that prevents a big disaster by causing a smaller disaster.
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Thursday, July 16, 2020 12:21 PM
> *To:* Aijun Wang <[email-masked]>
> *From:* [email-masked] [mailto:robert@raszuk..net <[email-masked]>]

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 16 Jul 2020 22:58:18 +0000

Can't we already do an RD ORF anyway?
Using an address-prefix ORF in the VPN address family with prefix length 64.

Regards,
Jakob.

From: Robert Raszuk <[email-masked]>
Sent: Thursday, July 16, 2020 2:58 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Aijun Wang <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

They receive it from CEs. /* Likewise ASBRs option B receive it from other ASBRs. */

So one's network should be able to handle an agreed number of routes as defined in VPN service. For anything above that in order to protect PE control and data planes prefix limit is the tool to apply towards your local peers which could result with src session down till NOC diagnoses the issue.

Thx,
R.

On Thu, Jul 16, 2020 at 11:22 PM Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Jakob.

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 12:21 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

Thx,
R.

Best Regards

Aijun Wang
China Telecom

Sorry but no.

Kind regards,
Robert

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

Dear Aijun & Wei,

Kind regards,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Jul 2020 01:06:43 +0200

That is true indeed.

Good point !

R.

On Fri, Jul 17, 2020 at 12:58 AM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Thursday, July 16, 2020 2:58 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* Aijun Wang <[email-masked]>; idr@ietf. org <[email-masked]>
> *From:* Idr <[email-masked]> *On Behalf Of *Robert Raszuk

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Jul 2020 17:20:29 -0700

+1

Regards,
Jeff

> On Jul 16, 2020, at 15:58, Jakob Heitz (jheitz) <jheitz=[email-masked]> wrote:
> 
> 
> On Thu, Jul 16, 2020 at 11:22 PM Jakob Heitz (jheitz) <[email-masked]> wrote:
> From: [email-masked] [mailto:robert@raszuk..net] 
> On Thu, Jul 16, 2020 at 4:40 AM Aijun Wang <[email-masked]> wrote:
> Hi, Robert:
>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 17 Jul 2020 12:47:48 +0800

Hi, Jakob:

It’s possible to reuse the address-prefix ORF to achieve the aim, but I am afraid that it will lead some confusion for the application of the current ORF types.

>From our POV, the user of the address-prefix ORF will pay more attention to the prefix itself(the actual part that used to route traffic), not care about the associated RD.

But for VRF prefixes limit control, the user pay more attention to the associated RD, not the prefix(the actual part that used to route traffic).

For example, we can refer to https://tools.ietf.org/html/rfc7543 (Covering Prefixes Outbound Route Filter for BGP-4), the minLen, maxLen and host address encoding do not include the RD(when comparing the received route, the receiver needs to add 64 to minLen/maxLen)

Defining one new ORF type will certainly to mitigate the ambiguous when apply these ORF-types within the network,  

I thinks this is same as that using RTC(RFC4684) to achieve the aim.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, July 17, 2020 6:58 AM
To: Robert Raszuk <[email-masked]>
Cc: Aijun Wang <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Regards,

Jakob.

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, July 16, 2020 2:58 PM
To: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >; idr@ietf. org <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Thx,

R.

 

On Thu, Jul 16, 2020 at 11:22 PM Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> > wrote:

You need RD.

Regards,

Jakob.

From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 12:21 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: idr@ietf. org <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

Thx,
R.

On Thu, Jul 16, 2020 at 10:58 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  [mailto:robert@raszuk..net <mailto:[email-masked]> ] 
Sent: Thursday, July 16, 2020 3:06 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Aijun Wang <[email-masked] <mailto:[email-masked]> >; idr@ietf. org <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Sorry but no. 

Kind regards,

Robert

 

Hi, Robert:

Thanks in advance.

Best Regards

Aijun Wang

China Telecom 

Dear Aijun & Wei,

Kind regards,

R.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 17 Jul 2020 14:53:28 +0800

Hi, Jakob:

Some clarification should be made later within the draft. 

Actually, the RD-ORF message will be regenerated between every BGP session, not propagate directly back to the upstream, as that done in BGP Update messages.

Then, every regeneration point(RR/ASBR) can control whether or not send the newly generated RD-ORF to the upstream.  In scenarios that when not all of PEs are overwhelmed by routes from this specified VPN, the RR/ASBR can constraint the sending of the RD-ORF policy to the source.

Best Regards

Aijun Wang

China Telecom    

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
Sent: Friday, July 17, 2020 5:22 AM
To: Robert Raszuk <[email-masked]>; Aijun Wang <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

You need RD.

Regards,

Jakob.

Aijun,

Thx,
R.

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Sorry but no. 

Kind regards,

Robert

 

Hi, Robert:

Thanks in advance.

Best Regards

Aijun Wang

China Telecom 

Dear Aijun & Wei,

Kind regards,

R.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 17 Jul 2020 15:07:15 +0800

Hi, Robert:

The edge between CE and PE is one control point to restrict the prefixes number, but we can’t rely solely on it, especially in the Option-B/Option-C interconnection scenario.

Using RD-ORF mechanism, we can prevent the overwhelmed VPN prefixes in one AS to influence PEs in another AS, and also the PEs within same AS(when they exchange routes via RR)

The reason for the occurrences of overwhelmed VPN prefixes may be misconfiguration on one PE, or being attacked from the outside of network, or other unforeseeable events.

Best Regards

Aijun Wang

China Telecom 

Sent: Friday, July 17, 2020 5:58 AM

Thx,

R.

 

You need RD.

Regards,

Jakob.

Aijun,

Thx,
R.

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Sorry but no. 

Kind regards,

Robert

 

Hi, Robert:

Thanks in advance.

Best Regards

Aijun Wang

China Telecom 

Dear Aijun & Wei,

Kind regards,

R.

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 17 Jul 2020 15:39:04 +0800

Hi, Jim:

RT is not as precise as RD to reflect the specific VRF.  RD is to make the prefix unique, it is certainly unique for one VRF.

Then using RTC is not as simple and reliable as using RD-ORF to control the overwhelmed VPN prefixes routes.

Best Regards

Aijun Wang

China Telecom

From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Thursday, July 16, 2020 10:27 PM
To: Robert Raszuk <[email-masked]>; Aijun Wang <[email-masked]>
Cc: Aijun Wang <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Thanks,

              Jim Uttaro

Sorry but no. 

Kind regards,

Robert

 

Hi, Robert:

The scenarios/problems described in this draft(https://tools.ietf.org/html/draft-wang-idr-rd-orf-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=6Jx4PFr3kh7DSy7LLkZ1DmONh26T4r4vIvfywUjoADQ&s=wpUrfSxySaPTcmxZL0kjc02l9rFO1pwxpb7mCfphW60&e=> ) are not for the VPN topology control, but for the VPN prefix limit management, which is signed along with the agreement with the VPN customer.

Thanks in advance.

Best Regards

Aijun Wang

China Telecom 

Subject: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=6Jx4PFr3kh7DSy7LLkZ1DmONh26T4r4vIvfywUjoADQ&s=wpUrfSxySaPTcmxZL0kjc02l9rFO1pwxpb7mCfphW60&e=> 

Dear Aijun & Wei,

Kind regards,

R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Jul 2020 11:43:12 +0200

Hi Aijun,

>From our POV, the user of the address-prefix ORF will pay more attention to
> the prefix itself
>

First the "user" is the implementation ... hope you are not expecting real
operator to inject such ORF entries when "overflow" happens.

Let's also observe that In L3VPNs_PREFIX = RD + IPv4_PREFIX

For example, we can refer to https://tools.ietf.org/html/rfc7543 (Covering
> Prefixes Outbound Route Filter for BGP-4), the minLen, maxLen and host
> address encoding do not include the RD(when comparing the received route,
> the receiver needs to add 64 to minLen/maxLen)
>

Incorrect.

The RFC says:

   o  the route prefix length is greater than or equal to the CP-ORF
      Minlen plus 64 (i.e., the length of a VPN Route Distinguisher);

  Note: ==equal== So that means that at least RD must be compared.

Actually, the RD-ORF message will be regenerated between every BGP session,
not propagate directly back to the upstream, as that done in BGP Update
messages.

Then, every regeneration point(RR/ASBR) can control whether or not send the
newly generated RD-ORF to the upstream.  In scenarios that when not all of
PEs are overwhelmed by routes from this specified VPN, the RR/ASBR can
constraint the sending of the RD-ORF policy to the source.

"Regeneration" follows propagation. This is exactly why we defined RTC so
all loop free properties are still met. ORF is point to point.

Or do you mean that when RR receives the RD-ORF from sending PE it will not
propagate till an operator pushes a new configuration to propagate this
further. If so have you even considered timing of those events ?

The edge between CE and PE is one control point to restrict the prefixes
number, but we can’t rely solely on it, especially in the Option-B/Option-C
interconnection scenario.

Using RD-ORF mechanism, we can prevent the overwhelmed VPN prefixes in one
AS to influence PEs in another AS, and also the PEs within same AS(when
they exchange routes via RR)

The reason for the occurrences of overwhelmed VPN prefixes may be
misconfiguration on one PE, or being attacked from the outside of network,
or other unforeseeable events.

ORF means installing additional route filter outbound from a BGP speaker as
instructed by the peer.

I do not see how any Option-B or worse Option-C peer will allow different
AS to push some VPN prefix filter on his infrastructure. Unless both are
under the same administration - but then you can use prefix limit.

Again I do not support your assertion that RD is more granular then RT for
this purpose. It all depends how given operator designed the RT and/or RD
allocations.

As mentioned for a given VPN importing VRF copies prefixes and *ovverrides*
incoming RD with local one. So just think what happens if that specific VRF
"overflows" but there is many sources of original pre-import routes all
with different RDs.

If anything in this space I would rather see us perhaps trying to automate
prefix limit per RT (in this case it would be export RTs carried with the
routes not import RTs).

Thx,
R.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 17 Jul 2020 14:16:54 +0000

Aijun,

              What do you mean “to control the overwhelmed VPN prefix routes” ? What is being overwhelmed PE? RR Control Plane?

Thanks,
              Jim Uttaro

From: Aijun Wang <[email-masked]>
Sent: Friday, July 17, 2020 3:39 AM
To: UTTARO, JAMES <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'Aijun Wang' <[email-masked]>; 'idr@ietf. org' <[email-masked]>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi, Jim:

Best Regards

Aijun Wang
China Telecom

From: UTTARO, JAMES [mailto:[email-masked]]
Sent: Thursday, July 16, 2020 10:27 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=kfXggcBd5hKNwNCgtVv-oU6n22cE7AqIrBisiYWQiHk&s=eTnCrbTFiCXqYPVquOYkzKilDYoJAyuT_7penXMYWt4&e=>

Thanks,
              Jim Uttaro

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 3:06 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Aijun Wang <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=kfXggcBd5hKNwNCgtVv-oU6n22cE7AqIrBisiYWQiHk&s=eTnCrbTFiCXqYPVquOYkzKilDYoJAyuT_7penXMYWt4&e=>

Sorry but no.

Kind regards,
Robert

Thanks in advance.

Best Regards

Aijun Wang
China Telecom

Dear Aijun & Wei,

Kind regards,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 20 Jul 2020 14:25:49 +0800

Hi, Robert:

The semantic encoding of “Address Prefix ORF(RFC5292)” can cover the proposed “RD-ORF”, but their usages is different.

For the usage of “Address Prefix ORF”, please refer to https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-oubound-route-filtering.pdf, the device needs to configure the prefix list that used to notify the ORF peer. The prefix list itself does not include RD.

For RD-ORF, the sender needs not do such configuration, and it can’t decide the RD info in advance that leads to the overwhelmed VPN table. 

Defining the new RD-ORF type can make the route filter policy more distinctly.

Other detail reply are inline below.【WAJ】

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, July 17, 2020 5:43 PM
To: Aijun Wang <[email-masked]>
Cc: Jakob Heitz (jheitz) <jheitz=[email-masked]>; Jeff Tantsura <[email-masked]>; Aijun Wang <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi Aijun,

>From our POV, the user of the address-prefix ORF will pay more attention to the prefix itself

First the "user" is the implementation ... hope you are not expecting real operator to inject such ORF entries when "overflow" happens. 

[WAJ]  In semantic encoding, it seems true.  But in actual usage of the “Address Prefix ORF”, the RD is often be ignored.  In RFC7543, we can also see the context as “ignoring the Route Distinguisher……” in  section 3 “Processing Rules”  <https://tools.ietf.org/html/rfc7543#section-3> https://tools.ietf.org/html/rfc7543#section-3  

Incorrect. 

The RFC says: 

[WAJ]   NO, The above procedures actually speak out that the RD is passed/ignored when compared.

"Regeneration" follows propagation. This is exactly why we defined RTC so all loop free properties are still met. ORF is point to point. 

Or do you mean that when RR receives the RD-ORF from sending PE it will not propagate till an operator pushes a new configuration to propagate this further. If so have you even considered timing of those events ? 

[WAJ]   No, the operator needs not intervene this process, but the RR can have its policy to send out or not the received RD-ORF messages.

 

ORF means installing additional route filter outbound from a BGP speaker as instructed by the peer. 

I do not see how any Option-B or worse Option-C peer will allow different AS to push some VPN prefix filter on his infrastructure. Unless both are under the same administration - but then you can use prefix limit. 

[WAJ]  Even under the same administration, we can’t depend on the prefix limit, because the ASBR/RR has no specific VRF route table.

Again I do not support your assertion that RD is more granular then RT for this purpose. It all depends how given operator designed the RT and/or RD allocations. 

[WAJ] Whatever the design of RD/RT, the RD is unique to one VRF, but RT is not.

As mentioned for a given VPN importing VRF copies prefixes and *ovverrides* incoming RD with local one. So just think what happens if that specific VRF "overflows" but there is many sources of original pre-import routes all with different RDs. 

[WAJ]  The overwhelmed PE should determines which RD or RDs leads to its overflow and send the specific RD-ORF message accordingly

If anything in this space I would rather see us perhaps trying to automate prefix limit per RT (in this case it would be export RTs carried with the routes not import RTs). 

[WAJ]  Prefix Limit mechanism can’t be used in Option B/C inter-AS scenarios

Thx,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 20 Jul 2020 14:37:52 +0800

Hi, Jim:

We consider the situation that the prefix limit within one VRF on PE being reached as “overwhelmed”. Not RR control Plane.

The RD-ORF mechanism just want to feedback such info back to the upstream BGP peer, limit the influence in controlled manner to one restricted scope.

Best Regards

Aijun Wang

China Telecom

From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Friday, July 17, 2020 10:17 PM
To: Aijun Wang <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'Aijun Wang' <[email-masked]>; 'idr@ietf. org' <[email-masked]>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

Thanks,

              Jim Uttaro

From: Aijun Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, July 17, 2020 3:39 AM
To: UTTARO, JAMES <[email-masked] <mailto:[email-masked]> >; 'Robert Raszuk' <[email-masked] <mailto:[email-masked]> >
Cc: 'Aijun Wang' <[email-masked] <mailto:[email-masked]> >; 'idr@ietf. org' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi, Jim:

 

Best Regards

Aijun Wang

China Telecom

From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Thursday, July 16, 2020 10:27 PM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Aijun Wang <[email-masked] <mailto:[email-masked]> >; idr@ietf. org <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=kfXggcBd5hKNwNCgtVv-oU6n22cE7AqIrBisiYWQiHk&s=eTnCrbTFiCXqYPVquOYkzKilDYoJAyuT_7penXMYWt4&e=> 

Thanks,

              Jim Uttaro

Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=3qhKphE8RnwJQ6u8MrAGeA&m=kfXggcBd5hKNwNCgtVv-oU6n22cE7AqIrBisiYWQiHk&s=eTnCrbTFiCXqYPVquOYkzKilDYoJAyuT_7penXMYWt4&e=> 

Sorry but no. 

Kind regards,

Robert

 

Hi, Robert:

Thanks in advance.

Best Regards

Aijun Wang

China Telecom 

Dear Aijun & Wei,

Kind regards,

R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Jul 2020 11:26:09 +0200

Aijun,

Cisco implemented Prefix ORF for SAFI1. We are talking about using it for
SAFI 128. So whatever any vendor is shipping today just does not matter.

> But in actual usage of the “Address Prefix ORF”, the RD is often be
ignored.

Not correct.

> *[WAJ]   *NO, The above procedures actually speak out that the RD is
passed/ignored when compared.

That is not the way I read this text.

*> [WAJ]   *No, the operator needs not intervene this process,

Then I think we are done with this proposal right here. No one will agree
to make ORF to become a transitive message. With or without policies. Note
appling any policies on IBGP is a different problem on its own.

Thank you,
R.

On Mon, Jul 20, 2020 at 8:25 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Robert:
>
>
>
> The semantic encoding of “Address Prefix ORF(RFC5292)” can cover the
> proposed “RD-ORF”, but their usages is different.
>
> For the usage of “Address Prefix ORF”, please refer to
> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-oubound-route-filtering.pdf
> , the device needs to configure the prefix list that used to notify the
> ORF peer. The prefix list itself does not include RD.
>
>
>
> For RD-ORF, the sender needs not do such configuration, and it can’t
> decide the RD info in advance that leads to the overwhelmed VPN table.
>
> *From:* Robert Raszuk [mailto:[email-masked]]
> *Sent:* Friday, July 17, 2020 5:43 PM
> *Cc:* Jakob Heitz (jheitz) <jheitz=[email-masked]>; Jeff
> Tantsura <[email-masked]>; Aijun Wang <[email-masked]>;
> *[WAJ]  *In semantic encoding, it seems true.  But in actual usage of the
> “Address Prefix ORF”, the RD is often be ignored.  In RFC7543, we can
> also see the context as “ignoring the Route Distinguisher……” in  section
> 3 “Processing Rules” https://tools.ietf.org/html/rfc7543#section-3
>
>
>
> For example, we can refer to https://tools.ietf.org/html/rfc7543
> (Covering Prefixes Outbound Route Filter for BGP-4), the minLen, maxLen
> and host address encoding do not include the RD(when comparing the received
> route, the receiver needs to add 64 to minLen/maxLen)
>
>
>
> Incorrect.
>
>
>
> The RFC says:
>
>
>
> *[WAJ]   *NO, The above procedures actually speak out that the RD is
> passed/ignored when compared.
>
>
>
> Actually, the RD-ORF message will be regenerated between every BGP
> session, not propagate directly back to the upstream, as that done in BGP
> Update messages.
>
> Then, every regeneration point(RR/ASBR) can control whether or not send
> the newly generated RD-ORF to the upstream.  In scenarios that when not all
> of PEs are overwhelmed by routes from this specified VPN, the RR/ASBR can
> Or do you mean that when RR receives the RD-ORF from sending PE it will
> not propagate till an operator pushes a new configuration to propagate this
> *[WAJ]   *No, the operator needs not intervene this process, but the RR
> can have its policy to send out or not the received RD-ORF messages.
>
>
>
>
>
> number, but we can’t rely solely on it, especially in the
> Option-B/Option-C interconnection scenario.
>
> *[WAJ]  *Even under the same administration, we can’t depend on the
> prefix limit, because the ASBR/RR has no specific VRF route table.
>
> *[WAJ] *Whatever the design of RD/RT, the RD is unique to one VRF, but RT
> is not.
>
>
>
> As mentioned for a given VPN importing VRF copies prefixes and
> *ovverrides* incoming RD with local one. So just think what happens if that
> specific VRF "overflows" but there is many sources of original pre-import
> routes all with different RDs.
>
> *[WAJ] * The overwhelmed PE should determines which RD or RDs leads to
> its overflow and send the specific RD-ORF message accordingly
>
>
>
> *[WAJ]  *Prefix Limit mechanism can’t be used in Option B/C inter-AS
> scenarios
>
>
>
> Thx,
> R.
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 21 Jul 2020 10:13:33 +0800

Hi, Robert:

I think the address prefix ORF procedures described in the specified document applied to any address family.  You can conclude this from its command description.

And, the most distinct difference between “Address Prefix ORF” and “RD-ORF”, is that the “Address Prefix ORF” is used in the pre-defined manner (the operator should define in advance the prefix list itself), but the “RD-ORF” is triggered only under the VRF table is overwhelmed, the corresponding RD info can’t be decided in advance.

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Monday, July 20, 2020 5:26 PM
To: Aijun Wang <[email-masked]>
Cc: Jakob Heitz (jheitz) <jheitz=[email-masked]>; Jeff Tantsura <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

Cisco implemented Prefix ORF for SAFI1. We are talking about using it for SAFI 128. So whatever any vendor is shipping today just does not matter. 

> But in actual usage of the “Address Prefix ORF”, the RD is often be ignored.

Not correct. 

> [WAJ]   No, the operator needs not intervene this process,   

Then I think we are done with this proposal right here. No one will agree to make ORF to become a transitive message. With or without policies. Note appling any policies on IBGP is a different problem on its own. 

Thank you,

R.

On Mon, Jul 20, 2020 at 8:25 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, July 17, 2020 5:43 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Jakob Heitz (jheitz) <jheitz=[email-masked] <mailto:[email-masked]> >; Jeff Tantsura <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; idr@ietf. org <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi Aijun,

Incorrect. 

The RFC says: 

 

 

Thx,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 21 Jul 2020 05:31:14 +0000

Aijun,

The Cisco configuration guide you cited shows the configuration of ORF for the
ipv4 address family only. https://tools.ietf.org/html/rfc5292 may be applied to
other address families, including VPN-IPv4 in particular.

https://tools.ietf.org/html/rfc4364#section-4.3.4 states:
   The labeled VPN-IPv4 NLRI itself is encoded as specified in
   [MPLS-BGP<https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP>], where the prefix consists of an 8-byte RD followed by an
   IPv4 prefix.

Per RFC5292, Section 4, an address prefix ORF in the VPN-IPv4 address family
encoded as:
MinLen = 0
MaxLen = 0
Length = 64
specifies an RD without any IP address bits.

The covering prefixes ORF specified in RFC7543 is different.
It specifically excludes the RD, so, as you rightly say, this ORF
cannot be used to specify an RD.

Regards,
Jakob.

From: Aijun Wang <[email-masked]>
Sent: Monday, July 20, 2020 7:14 PM
To: 'Robert Raszuk' <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; 'Jeff Tantsura' <[email-masked]>; 'idr@ietf. org' <[email-masked]>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi, Robert:

Best Regards

Aijun Wang
China Telecom

Cc: Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:jheitz=[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>

Aijun,

Not correct.

Thank you,
R.

On Mon, Jul 20, 2020 at 8:25 AM Aijun Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Robert:

Best Regards

Aijun Wang
China Telecom

From: Robert Raszuk [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 17, 2020 5:43 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Jakob Heitz (jheitz) <jheitz=[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi Aijun,

[WAJ]  In semantic encoding, it seems true.  But in actual usage of the “Address Prefix ORF”, the RD is often be ignored.  In RFC7543, we can also see the context as “ignoring the Route Distinguisher……” in  section 3 “Processing Rules” https://tools.ietf.org/html/rfc7543#section-3

Incorrect.

The RFC says:

Thx,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 21 Jul 2020 14:12:30 +0800

Hi, Jakob:

Yes, it is possible to reuse the encoding of Address Prefix ORF to transfer the information that related to RD, RD is actually part of the VPN Prefix.

But, considering the primary intention and application of these ORF policies, separate them in different ORF types will be benefit to their implementation and deployment.

One important difference between the “Address Prefix ORF” and “RD-ORF”, as stated in previous mail, is the former is predetermined but the latter is event driven.

Best Regards

Aijun Wang

China Telecom

From: Jakob Heitz (jheitz) [mailto:[email-masked]] 
Sent: Tuesday, July 21, 2020 1:31 PM
To: Aijun Wang <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'Jeff Tantsura' <[email-masked]>; 'idr@ietf. org' <[email-masked]>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

   [MPLS-BGP <https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP> ], where the prefix consists of an 8-byte RD followed by an

   IPv4 prefix.

encoded as:

MinLen = 0

MaxLen = 0

Length = 64

 

Regards,

Jakob.

From: Aijun Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, July 20, 2020 7:14 PM
To: 'Robert Raszuk' <[email-masked] <mailto:[email-masked]> >
Cc: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >; 'Jeff Tantsura' <[email-masked] <mailto:[email-masked]> >; 'idr@ietf. org' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Cc: Jakob Heitz (jheitz) <jheitz=[email-masked] <mailto:jheitz=[email-masked]> >; Jeff Tantsura <[email-masked] <mailto:[email-masked]> >; idr@ietf. org <[email-masked] <mailto:[email-masked]> >

Aijun,

Not correct. 

Thank you,

R.

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Incorrect. 

The RFC says: 

 

 

Thx,
R.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 21 Jul 2020 07:29:46 +0000

I made a mistake. MinLen must be 64, because you want to match all routes with a specified RD.

I did not see this:
former is predetermined but the latter is event driven
Can you explain this in more detail please.

Regards,
Jakob.

From: Aijun Wang <[email-masked]>
Sent: Monday, July 20, 2020 11:13 PM
To: Jakob Heitz (jheitz) <[email-masked]>; 'Robert Raszuk' <[email-masked]>
Cc: 'Jeff Tantsura' <[email-masked]>; 'idr@ietf. org' <[email-masked]>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi, Jakob:

Best Regards

Aijun Wang
China Telecom

From: Jakob Heitz (jheitz) [mailto:[email-masked]]
Sent: Tuesday, July 21, 2020 1:31 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>
Cc: 'Jeff Tantsura' <[email-masked]<mailto:[email-masked]>>; 'idr@ietf. org' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

Regards,
Jakob.

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 20, 2020 7:14 PM
To: 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>
Cc: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; 'Jeff Tantsura' <[email-masked]<mailto:[email-masked]>>; 'idr@ietf. org' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi, Robert:

Best Regards

Aijun Wang
China Telecom

Aijun,

Not correct.

Thank you,
R.

Best Regards

Aijun Wang
China Telecom

Hi Aijun,

Incorrect.

The RFC says:

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Jul 2020 10:29:57 +0200

Aijun,

> the former is predetermined but the latter is event driven.

There is *NOTHING* in the ORF spec that requires prefix ORF to be
"predetermined". It can be happily generated dynamically on demand.

You can not use one example of one implementation to justify a new protocol
extension :)

- - -

Btw ... Imagine this scenario:

PE1 ---- RR ---- PE2
                |____ PE3

Let's observe that for a given VPN PE is overwhelmed but PE3 is ok. If PE2
will send RD-ORF towards PE1 (via RR) it will impact VPN routes received
also to PE3. Not good. If PE can not handle load of a given VPN it can drop
the routes for that very VPN and generate alarm.

In general the issue you are struggling with has been solved around 2001 in
many L3VPNs deployments by proper selection of RTs structure in a given
network. Yes it is not trivial to construct your import and export policies
such that it can accommodate and handle various real time scenarios. But
clearly possible.

Thx,
R.

On Tue, Jul 21, 2020 at 8:12 AM Aijun Wang <[email-masked]>
wrote:

> Hi, Jakob:
>
>
>
> Yes, it is possible to reuse the encoding of Address Prefix ORF to
> transfer the information that related to RD, RD is actually part of the VPN
> Prefix.
>
> But, considering the primary intention and application of these ORF
> policies, separate them in different ORF types will be benefit to their
> implementation and deployment.
>
> One important difference between the “Address Prefix ORF” and “RD-ORF”, as
> stated in previous mail, is the former is predetermined but the latter is
> event driven.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Jakob Heitz (jheitz) [mailto:[email-masked]]
> *Sent:* Tuesday, July 21, 2020 1:31 PM
> *To:* Aijun Wang <[email-masked]>; 'Robert Raszuk' <
> [email-masked]>
> *Cc:* 'Jeff Tantsura' <[email-masked]>; 'idr@ietf. org' <
> [email-masked]>
> *Subject:* RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> Aijun,
>
>
>
>    [MPLS-BGP <https://tools.ietf.org/html/rfc4364#ref-MPLS-BGP>], where
> the prefix consists of an 8-byte RD followed by an
>
>    IPv4 prefix.
>
>
>
> *From:* Aijun Wang <[email-masked]>
> *Sent:* Monday, July 20, 2020 7:14 PM
> *To:* 'Robert Raszuk' <[email-masked]>
> *Cc:* Jakob Heitz (jheitz) <[email-masked]>; 'Jeff Tantsura' <
> [email-masked]>; 'idr@ietf. org' <[email-masked]>
> *Subject:* RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>
>
>
> Hi, Robert:
>
>
>
> I think the address prefix ORF procedures described in the specified
> document applied to any address family.  You can conclude this from its
> command description.
>
> And, the most distinct difference between “Address Prefix ORF” and “RD-ORF
> ”, is that the “Address Prefix ORF” is used in the pre-defined manner
> (the operator should define in advance the prefix list itself), but the “
> RD-ORF” is triggered only under the VRF table is overwhelmed, the
> corresponding RD info can’t be decided in advance.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Robert Raszuk [mailto:[email-masked] <[email-masked]>]
> *Sent:* Monday, July 20, 2020 5:26 PM
> Tantsura <[email-masked]>; idr@ietf. org <[email-masked]>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 21 Jul 2020 17:03:25 +0800

Hi, Robert:

In this scenario, the RR can constrain the BGP UPDATEs (which matches the RD within its received RD-ORF) to PE2 only, not send/regenerate the RD-ORF message to PE1.

Then, PE1 can still send the VPN routes to RR, RR can send them to PE3, but not to PE2.

RR can have its own policy to propagate such messages to upstream peer, depends on its capabilities.

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk [mailto:[email-masked]] 
Sent: Tuesday, July 21, 2020 4:30 PM
To: Aijun Wang <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; Jeff Tantsura <[email-masked]>; idr@ietf. org <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

> the former is predetermined but the latter is event driven.  

There is *NOTHING* in the ORF spec that requires prefix ORF to be "predetermined". It can be happily generated dynamically on demand. 

You can not use one example of one implementation to justify a new protocol extension :) 

- - - 

PE1 ---- RR ---- PE2

                |____ PE3

Let's observe that for a given VPN PE is overwhelmed but PE3 is ok. If PE2 will send RD-ORF towards PE1 (via RR) it will impact VPN routes received also to PE3. Not good. If PE can not handle load of a given VPN it can drop the routes for that very VPN and generate alarm. 

In general the issue you are struggling with has been solved around 2001 in many L3VPNs deployments by proper selection of RTs structure in a given network. Yes it is not trivial to construct your import and export policies such that it can accommodate and handle various real time scenarios. But clearly possible. 

Thx,

R.

On Tue, Jul 21, 2020 at 8:12 AM Aijun Wang <[email-masked] <mailto:[email-masked]> > wrote:

Hi, Jakob:

 

Best Regards

Aijun Wang

China Telecom

From: Jakob Heitz (jheitz) [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, July 21, 2020 1:31 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >; 'Robert Raszuk' <[email-masked] <mailto:[email-masked]> >
Cc: 'Jeff Tantsura' <[email-masked] <mailto:[email-masked]> >; 'idr@ietf. org' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun,

   IPv4 prefix.

encoded as:

MinLen = 0

MaxLen = 0

Length = 64

 

Regards,

Jakob.

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Aijun,

Not correct. 

Thank you,

R.

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Incorrect. 

The RFC says: 

 

 

Thx,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 21 Jul 2020 17:13:35 +0800

Hi, Jakob:

Current implementation for “Address Prefix ORF” is based on prefix list, please refer to https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html#wp1883421149 (neighbor prefix-list), which can be configured under any address family, include VPN IPv4 address.

Such filter policy needs to be configured in advance, to tell BGP peer do not send the specified prefix. Then they are “predetermined”.

But for the scenario of RD-ORF, the sender of RD-ORF can’t decide the RDs which leads to its VPN table overflow until such events happen. The RD-ORF messages can only be determined upon such event, then they are “event driven.”

Should we consider such differences and separate them into two ORF types then?

Best Regards

Aijun Wang

China Telecom

Sent: Tuesday, July 21, 2020 3:30 PM

I did not see this:

Regards,

Jakob.

To: Jakob Heitz (jheitz) <[email-masked] <mailto:[email-masked]> >; 'Robert Raszuk' <[email-masked] <mailto:[email-masked]> >

Hi, Jakob:

 

Best Regards

Aijun Wang

China Telecom

Aijun,

   IPv4 prefix.

encoded as:

MinLen = 0

MaxLen = 0

Length = 64

 

Regards,

Jakob.

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Aijun,

Not correct. 

Thank you,

R.

Hi, Robert:

 

Best Regards

Aijun Wang

China Telecom

Hi Aijun,

Incorrect. 

The RFC says: 

 

 

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Jul 2020 11:16:34 +0200

> depends on its capabilities.

That now sounds like a very SDN like controller - not a BGP RR.

I have one final question:

Do you agree that you can accomplish exactly what you need by proper RT
assignment and use of RTC ?

Thx,
R.

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 21 Jul 2020 17:28:13 +0800

Hi, Robert:

It’s possible, but is not easy management as using RD-ORF.  

We should also consider that RTs for one VPN can be changed due to inter-VRF communication.

Best Regards

Aijun Wang

China Telecom

Sent: Tuesday, July 21, 2020 5:17 PM

Do you agree that you can accomplish exactly what you need by proper RT assignment and use of RTC ? 

Thx,
R.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 21 Jul 2020 14:04:20 +0000

We have been managing it for 20+ yrs. It is fairly straightforward..

From: Idr <[email-masked]> On Behalf Of Aijun Wang
Sent: Tuesday, July 21, 2020 5:28 AM
To: 'Robert Raszuk' <[email-masked]>
Cc: 'idr@ietf. org' <[email-masked]>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Hi, Robert:

Best Regards

Aijun Wang
China Telecom

From: Robert Raszuk [mailto:[email-masked]]
Sent: Tuesday, July 21, 2020 5:17 PM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>; idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwang-2Didr-2Drd-2Dorf-2D00&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=roxkpiFp9g7IaLpCxHcd33cXy3ihzxCIh6B5COpYAMA&s=Prl9RuYC9oJEOil_ZeG_fnHExKsXI7vMTAvg_ewsvlE&e=>

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Tue, 21 Jul 2020 22:31:52 +0800

Managing the VPN route table overflow or managing RTs for VPN? We are discussing the former.

Aijun Wang
China Telecom

> On Jul 21, 2020, at 22:04, UTTARO, JAMES <[email-masked]> wrote:
> 
>