Re: [Idr] rd-orf problem clarification at the local level

[Aijun Wang <[e-mail]>]

Hi, All:

 

We have upload one new draft to describe the problems that related to the VPN routes control in shared BGP session https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-routes-control-analysis

Wish to hear your considerations and comments on such analysis.

If we can consensus on the scenarios analysis and the solution requirements, we can focus on the potential solutions in next step.

 

Thanks in advance.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: [e-mail] <[e-mail]> On Behalf Of Aijun Wang
Sent: Tuesday, February 16, 2021 1:06 PM
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Idr] rd-orf problem clarification at the local level

 

 

Hi, Jeff:
This is the reply to your comments on the local peer that initiated the RD-ORF message.

Wish these explanations can help you know RD-ORF mechanism more throughly and can refine and forward it.


Aijun Wang
China Telecom




On Feb 16, 2021, at 01:10, Jeffrey Haas <[e-mail] <mailto:[e-mail]> > wrote:

 

Authors,

 

The IDR chairs were discussing how best to move forward the discussion about

Working Group adoption for rd-orf.  As part of that discussion, we thought

it would be helpful to have the discussion split to cover specific points.

The goal is primarily to clarify the functional requirements.  As part of

this discussion, there will be some technical observations on the proposal.

 

This e-mail is structured with the perceived issue, and a set of questions

to be commented on as Issues at the end.

 

This e-mail focuses on the rd-orf problem statement from the receiving PE's

perspective.  

 

---

 

Presume we have a PE router with some number of attached VRFs.

For this example, we have a VRF-A that uses a single route target.

In this VRF, routes from two remote PEs with distinct route distinguishers,

RD1 and RD2, contribute to that VRF.

 

---

 

Presumed problem statement:

It is possible for this VRF, and perhaps the PE itself, to be overwhelmed by

an excess number of VPN routes.

 

Common implementation mitigations available today:

1. A VRF may implement a prefix limit that prevents an excess number of

 routes from being redistributed from the VPN's address family into the VRF.

 

 However, this does not keep the PE from retaining an excess number of VPN

 routes in its global VPN table.

[WAJ]Yes



 

2. The PE may apply BGP policy to restrict the VPN routes that it will

 accept and store.  An example of this may be policy based on BGP route

 properties in Path Attributes such as Extended Communities.  Another

 example may be policy based on BGP NLRI properties, such as route

 distinguisher.  (The implementation may require configuration to cause

 VPN routes rejected by policy to be discarded rather than stored in the

 Adj-Ribs-In as ineligible routes.)

 

It is thus possible for an implementation to mitigate the impact storage

requirements for an excess number of VPN routes with no new features.

[WAJ] As stated in previous mail, if we can know the attributes of offending routes in advance, such solution is possible. But for the scenarios that described in the draft, the overwhelming VPN routes are interested and permitted, but accept all of them can influence the capabilities for the PE to service other VRFs on it.



 

---

 

Reducing the work for the receiving PE for unwanted routes:

 

It can be observed that a core benefit of RT-Constrain (RFC 4684) is that it

permits a receiving PE to avoid receiving routes it is not interested in.

This may also reduce the work of the sending BGP Speaker by avoiding the I/O

overhead of the unwanted routes.

 

However, RT-Constrain will not help you reduce the work if you want a subset

of the routes covered by a specific route target.


[WAJ]Yes





 

The desired property in rd-orf is that a BGP Speaker will exchange an

outbound route filter that provides a list of route distinguishers that will

be excluded from the routes sent on a session.  

 

Essentially, a "do not send these RD routes list".

 

Such an ORF can reduce the amount of work on a receiving PE, and reduce the

storage of unwanted routes.


[WAJ] Yes





 

---

 

Operational considerations for PE filtering using route distinguishers:

 

1. A VPN route may be targeted for more than one receiving VRF.  Excluding

 VPN routes by route distinguisher may only be done if it is operationally

 acceptable that no VRFs on the receiving router will receiving those

 routes, regardless of VPN membership.  

 

 (That is, collateral damage is a possibility that must be understood.)

 

[WAJ] Yes. Section https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1 in Figure 3 has described such situations, as also the example that Robert mentioned. More clear description should be clarified in the later version to achieve the determined behavior in such situations.





 

2. A PE may have downstream BGP peers.  It must be operationally acceptable

 that no downstream BGP peers receive VPN routes whose route distinguisher

 is being filtered.

[WAJ] Yes. This is more like the behavior of RR/ASBR. More descriptions and criteria will be added for the trigger of RD-ORF message on these intermediate/proxy/leader devices.



 

3. VRFs that have prefix limits may have its limit exceeded by routes from

 multiple remote PE resources.  What is the mechanism that will permit an

 implementation to choose what route distinguisher will be filtered,

 presuming the collateral damage in points 1 and 2 is acceptable?

[WAJ] Currently, we consider to select the RD whose associated VPN routes occupy most part of offending VPN routes.



 

---

 

rd-orf protocol issues:

 

1. The rd-orf type specific part includes a Sequence field.  Its use in the

 ORF filtering mechanism is unclear in the draft's text.

 

 It is my speculation that this comes from the Prefix ORF (RFC 5292)

 semantics.  However, it is improperly specified, if so.  A Prefix ORF

 requires ordering semantics in order to properly execute prefix-match

 behavior, especially given the need for more-specific/less-specific

 portions of the match.  In the case of an rd-orf, order is not relevant,

 only the route-distinguisher.

[WAJ] Yes, it refers the semantic of RFC5292. But I think this field can also be useful for the list/add/remove of the filter policy, not the compared order. 

And, one correction to the previous mail for the ORF mechanism: there are permit/deny actions for the filter policy. Is it possible we also utilize this field to achieve the following effects as that you mentioned in previous mail:

1: “Permit some, deny the rest”

2:”Deny some, permit the rest”

If so, the “sequence” field can be utilized.

Anyway, we can further refine the semantic of these fields later.





 

2. The Route Distinguisher field is a fixed length of 8 octets.  Using ORF

 procedures (RFC 5291), once an ORF has been received for a given

 AFI/SAFI, the entries of the ORF must be matched or the routes will not

 be advertised to the remote BGP speaker.  

 

 This means that once there is a desire to specify a "do not send" rd-orf,

 it becomes required that all desired RDs must be sent.  Knowing the full

 set of possible RDs a priori is likely impossible.

 

 The feature thus needs a "default" entry of some sort.


[WAJ] Yes. One possible way is that adding the following RD-ORF entry in last:

“Action/permit, RD/all-zero”

If acceptable, will add such description later.





 

---

 

Encoding rd-orf behaviors using Address-Prefix-Based ORF (RFC 5292):

 

Jakob Heitz, among others, has mentioned this solution.

 

A VPN route is made up of an RD + Prefix, with RD being a fixed 8 octet

value from known types.

 

A rd-only ORF may be represented as:

- The AFI/SAFI of the VPN address family to be filtered.

- An appropriate Sequence number

- A minlen of 64 bits

- A maxlen appropriate to the AFI/SAFI of the VPN route in question (as long

as its bit-length is <= 255).

- Length is 64 bits

- Prefix is the encoded route distinguisher

 

The default VPN Address Family ORF may be represented as:

- The AFI/SAFI of the VPN address family to be filtered.

- The last sequence number in the known series.

- A minlen of 0 bits

- A maxlen appropriate to the AFI/SAFI of the VPN route in question (as long

as its bit-length is <= 255).

 

[WAJ] We should state clearly the maxlen value in every AFI/SAFI, as that done in RFC7543 https://tools.ietf.org/html/rfc7543.

Is it more prune to error?




- Length is 0 bits

- Prefix will not be encoded due to the Length.

 

The Sequence number semantics for such Prefix ORFs containing only route

distinguishers is less important than those for Address prefixes.  The main

requirement is that the individual members are distinctly numbered, and that

the default entry, if present, is last.

 

In cases where Prefix filtering is desired for VPN routes in addition to

route distinguisher filtering, the implementation will need to make

appropriate adjustments to the Sequence number.

 

That said, aside from the popularity of ORFs in modern BGP implementations

being low, VPN route filtering for ORFs is likely uncommon due to the need

to known the route distinguisher a priori.  (See discussion above.)

 

[WAJ] Yes, it is not easy to know the RD of offending VPN routes, and it is different from the initial aim of Prefix-Based ORF, which is always planned in advance. This is the main reason that we prefer to using one distinct encoding.





---

 

Issues for discussion:

1. Is this analysis of the issue from the receiving PE's perspective

 correct?  If not, please comment in the appropriate text above.

[WAJ] Basically correct. Have commented in the related parts above.



 

2. What procedure would an implementation use to apply a prefix-limit to

 trigger this filtering mechanism given that a VRF may have routes

 contributed to by several route distinguishers?

[WAJ] Will select the RD whose associated VPN routes occupy the most part of the offending VPN routes. Will clarify this point later if necessary.



 

3. Can the procedure above for using RFC 5292 address the use case?  If not,

 please comment on the specific use case and encoding difficulty.

[WAJ] It is possible, but not very concise. We must define clearly most of used fields for every AFI/SAFI. And it is contrary in some extent the knowledge of prefix-list usage/implementation in several vendors including Cisco/Huawei and Juniper, as I have explained to Jakob in https://mailarchive.ietf.org/arch/msg/idr/sSrjOAoLZCEd2oYfJAYeryp9i4Y/



 

 

 

 

-- Jeff