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

[Aijun Wang <[e-mail]>]

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

 

 

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

 

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 <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, July 20, 2020 11:13 PM
To: Jakob Heitz (jheitz) <[e-mail] <mailto:[e-mail]> >; 'Robert Raszuk' <[e-mail] <mailto:[e-mail]> >
Cc: 'Jeff Tantsura' <[e-mail] <mailto:[e-mail]> >; 'idr@ietf. org' <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

 

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:[e-mail]] 
Sent: Tuesday, July 21, 2020 1:31 PM
To: Aijun Wang <[e-mail] <mailto:[e-mail]> >; 'Robert Raszuk' <[e-mail] <mailto:[e-mail]> >
Cc: 'Jeff Tantsura' <[e-mail] <mailto:[e-mail]> >; 'idr@ietf. org' <[e-mail] <mailto:[e-mail]> >
Subject: RE: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

 

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 <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, July 20, 2020 7:14 PM
To: 'Robert Raszuk' <[e-mail] <mailto:[e-mail]> >
Cc: Jakob Heitz (jheitz) <[e-mail] <mailto:[e-mail]> >; 'Jeff Tantsura' <[e-mail] <mailto:[e-mail]> >; 'idr@ietf. org' <[e-mail] <mailto:[e-mail]> >
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:[e-mail]] 
Sent: Monday, July 20, 2020 5:26 PM
To: Aijun Wang <[e-mail] <mailto:[e-mail]> >
Cc: Jakob Heitz (jheitz) <jheitz=[e-mail] <mailto:jheitz=[e-mail]> >; Jeff Tantsura <[e-mail] <mailto:[e-mail]> >; idr@ietf. org <[e-mail] <mailto:[e-mail]> >
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 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 <[e-mail] <mailto:[e-mail]> > 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. 

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:[e-mail] <mailto:[e-mail]> ] 
Sent: Friday, July 17, 2020 5:43 PM
To: Aijun Wang <[e-mail] <mailto:[e-mail]> >
Cc: Jakob Heitz (jheitz) <jheitz=[e-mail] <mailto:[e-mail]> >; Jeff Tantsura <[e-mail] <mailto:[e-mail]> >; Aijun Wang <[e-mail] <mailto:[e-mail]> >; idr@ietf. org <[e-mail] <mailto:[e-mail]> >
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. 

 

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

 

[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  

 

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.   

[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 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 ? 

[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.

 

 

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. 

[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.