Early Review of draft-ietf-idr-vpn-prefix-orf-22
review-ietf-idr-vpn-prefix-orf-22-opsdir-early-guo-2025-10-03-00
| Request | Review of | draft-ietf-idr-vpn-prefix-orf-20 |
|---|---|---|
| Requested revision | 20 (document currently at 31) | |
| Type | Early Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2025-10-07 | |
| Requested | 2025-08-14 | |
| Requested by | Keyur Patel | |
| Authors | Wei Wang , Aijun Wang , Haibo Wang , Gyan Mishra , Jie Dong | |
| I-D last updated | 2026-03-02 (Latest revision 2026-03-02) | |
| Completed reviews |
Opsdir Early review of -22
by Aihua Guo
(diff)
Secdir Early review of -20 by Scott G. Kelly (diff) Rtgdir Early review of -21 by Sasha Vainshtein (diff) |
|
| Comments |
Please provide your review comments. |
|
| Assignment | Reviewer | Aihua Guo |
| State | Completed | |
| Request | Early review on draft-ietf-idr-vpn-prefix-orf by Ops Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/ppLG_SQTzScgvIiZVFOo3Mu7cfI | |
| Reviewed revision | 22 (document currently at 31) | |
| Result | Has issues | |
| Completed | 2025-10-03 |
review-ietf-idr-vpn-prefix-orf-22-opsdir-early-guo-2025-10-03-00
Summary: Document is technically sound, with minor editorial issues and Nits
that need to be addressed
Comments:
Overview:
I was selected by the OPSAWG Directorate to review version -20 of the
draft. However, by the time of my review the draft had been updated.
Therefore, my comments are based on the current version -22.
Overall, I find the concept and technical solution proposed in the draft to
be sound and well-structured. The content is easy to comprehend. That said,
there are grammatical issues throughout the text that could certainly be
improved.
Major Issues: Not found
Minor issues:
1. There are several places where the use of key words does not appear to
conform to RFC 2119. I suggest reviewing and/or fixing the text accordingly.
E.g.
- Section 4: "Before originating a VPN Prefix ORF message, the device
*should* compare the list of RTs carried by VPN routes..." - Section 4: The
"default" entry *should* be installed in advance in the VPN Prefixes ORF
table - Section 5: "For the RR/ASBR, it *should* perform following" -
Section 5: "Once set and attached to the BGP UPDATE message, its value
*should not* be altered along the advertisement path" - Section 6: When the
BGP ROUTE-REFRESH message carries VPN Prefix ORF entries, it *must* be set
as follows..." - Section 6.1: "Otherwise, the value of Source PE TLV
*should* be set to next hop address" - Section 6.3: "the VPN routes with
different RTs *may* be assigned to different VRFs on the receiver" -
Section 8: "The commands *must* include the unique identification
information of the target ORF entry"
2. The title of section 4 says "The general procedures of VPN Prefix ORF
mechanism on sender", whereas the content describes the procedures for both
the sender and receiver of the ORF. Consider either removing sender from the
title, or splitting the section into two, one for the sender and the other
for the receiver.
Nits:
Here is a list of occurrences I found grammatically troublesome and suggest
fixing. Due to time constraints, this list may be incomplete. Section 1.
Introduction
OLD
there is lack of appropriate methods to control the flooding of VPN
routes within one VRF to avoid overwhelming the process of VPN routes
in other VRFs
NEW
there is a lack of appropriate methods to control the flooding of VPN
routes within one VRF to avoid overwhelming the processing of VPN
routes in other VRFs
END
OLD
There are several solutions can be used to alleviate this problem:
NEW
There are several solutions that can be used to alleviate this problem:
END
OLD
Configure the Maximum Prefix for each VRF on edge nodes
NEW
Configuring the Maximum Prefix for each VRF on edge nodes
END
OLD
RTC can only filter the VPN routes from any uninterested VRFs, if the
"offending routes (prefixes)" come from an interested VRF, RTC
mechanism can't filter them.
NEW
RTC can only filter VPN routes from uninterested VRFs, if the
"offending routes (prefixes)" come from an interested VRF, the RTC
mechanism cannot filter them.
END
OLD
CP-ORF is applicable in Virtual Hub-and-Spoke[RFC7024] VPN and also
the BGP/MPLS Ethernet VPN (EVPN)[RFC7432] networks, but its main aim
is get any interested VPN prefixes and can't be used to filter the
overwhelmed VPN prefixes dynamically.
NEW
CP-ORF is applicable in Virtual Hub-and-Spoke[RFC7024] VPNs and also
BGP/MPLS Ethernet VPN (EVPN)[RFC7432] networks, but its primary function
is to retrieve interested VPN prefixes and it cannot be used to filter
overwhelmed VPN prefixes dynamically.
END
OLD
the BGP session will be shut down, which will effect the operation...
NEW
the BGP session will be shut down, which will affect the operation...
END
s/effect/affect
OLD
Configure the Maximum Prefix for each VRF on edge nodes
NEW
Configuring the Maximum Prefix for each VRF on edge nodes
END
OLD
However, PEs still need to parse the incoming BGP.
NEW
However, PEs still need to parse the incoming BGP messages.
END
OLD
The BGP speaker
upon receiving a VPN Prefix ORF entry from its BGP peer will filter
and withdraw any offending VPN routes that was announced to its peer.
NEW
Upon receiving a VPN Prefix ORF entry from its BGP peer, the BGP
speaker will filter
and withdraw any offending VPN routes that were announced to its peer.
END
Section 4
s/Pefixes/Prefixes
OLD
The VPN information includes the updated VPN routes and their
NEW
The VPN information includes updated VPN routes and their
END
OLD
It then checks whether the number of the
newly added VPN routes has caused the number of total VPN routes to
exceed the maximum route limit for the associated VPN instance.
NEW
It then checks whether the number of
newly added VPN routes has caused the total number of VPN routes to
exceed the maximum route limit for the associated VPN instance.
END
OLD
If the route limit of the VPN instance, which is identified by the
VPN instance identification information, is reached or is exceeded,
it will send a VPN Prefix ORF message to the sending BGP peer,
indicating that the sending BGP peer stop sending the corresponding
VPN routes which are identified by the VPN instance identification
information.
NEW
If the route limit of the VPN instance, which is identified by the
VPN instance identification information, is reached or exceeded,
the receiving BGP peer will send a VPN Prefix ORF message to the sending BGP
peer, indicating that it should stop sending the corresponding VPN routes
which are identified by the VPN instance identification information.
END
OLD
Before originating a VPN Prefix ORF message, the device should
compare the list of RTs carried by VPN routes to those are imported
by other VRFs on the device. If the route's RT are included in the
import rules of other VRFs, the VPN Prefix ORF message MUST NOT be
originated.
NEW
Before originating a VPN Prefix ORF message, the device SHOULD
compare the list of RTs carried by VPN routes with those imported
by other VRFs on the device. If the route's RT is included in the
import rules of other VRFs, the VPN Prefix ORF message MUST NOT be
originated.
END
OLD
Before sending a VPN Prefix ORF entry, a sender SHOULD send a
"default" entry to the VPN Prefix ORF receiver, to allow other
allowed VPN prefixes pass the filter. The "default" entry should be
installed in advance in the VPN Pefixes ORF table, with the offending
VPN routes process method equal to 0, sequence equal to 0xFFFFFFFF,
length is equal to 8, and Route Distinguisher is equal to 0.
NEW
Before sending a VPN Prefix ORF entry, a sender SHOULD send a
"default" entry to the VPN Prefix ORF receiver, to allow other
allowed VPN prefixes to pass the filter. The "default" entry should be
installed in advance in the VPN Prefixes ORF table, with the offending
VPN routes process method set to 0, sequence set to 0xFFFFFFFF,
length set to 8, and Route Distinguisher set to 0.
END
OLD
The instruction information that sends from the receiving BGP peer
includes the followings information:
NEW
The instruction information sent from the receiving BGP peer
includes the following information:
END
OLD
The ORF entries that are included in the route-refresh message.
NEW
The ORF entries that are included in the ROUTE-REFRESH message.
END
OLD
Set the Action field in the ORF entries to the value that
instructs adding the corresponding filter condition to the
outbound route filter of the sending BGP peer.
NEW
The Action field in the ORF entries is set to a value that
instructs the sending BGP peer to add the corresponding filter condition
to its outbound route filter. END
OLD
Set the Match field in the ORF entries to the value that instructs
denying the VPN routes updates that match the corresponding ORF
entries.
NEW
The Match field in the ORF entries is set to a value that instructs
the sending BGP peer to deny VPN routes updates that match the
corresponding ORF entries. END
OLD
When multiple VRFs on a PE is receiving VPN routes with a specific
RD
NEW
When multiple VRFs on a PE are receiving VPN routes with a specific
RD
END
OLD
The detail procedures for different scenarios are described below
NEW
The detailed procedures for different scenarios are described below
END
Section 5:
OLD
For the RR/ASBR, it should perform as following:
NEW
For the RR/ASBR, it SHOULD perform the following:
END
OLD
This section updates route reflection procedures, which means
[RFC4456] need to be updated.
NEW
This section updates route reflection procedures, which means
[RFC4456] needs to be updated.
END
Section 6:
"A BGP speaker that is willing to receive ORF entries from its peer,
or a BGP speaker that would like to send ORF entries to its peer,
advertises this to the peer by using the Outbound Route Filtering
Capability defined in [RFC5291]"
What does "this" refer to, the ORF message?
Section 6.2:
OLD
The encoding of Source AS TLV is as follow
NEW
The encoding of Source AS TLV is as follows
END
Section 7:
s/orignator/originator
s/The receiver check/The receiver checks
s/The receiver withdraw/The receiver withdraws
s/the entries that are needed to /the entries that need to