[OPS-DIR]Re: draft-ietf-idr-vpn-prefix-orf-22 early Opsdir review

[Aihua Guo <[e-mail]>]

Hi Med,

Thanks for checking in - it looks like I missed the earlier reply. I’ve
reviewed the changes the authors included in rev -23, and all of my
comments have been addressed.

Best,
Aihua

On Sat, Apr 25, 2026 at 2:03 PM <[e-mail]> wrote:

> Hi Aihua,
>
> Thank you for the review. I understood that the authors addressed your
> review in -23 ?
>
> FYI, I balloted DISCUSS:
> https://mailarchive.ietf.org/arch/msg/idr/7D3PK6tKs4_LCwHQ8604JqTKW4Y/
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Aihua Guo via Datatracker <[e-mail]>
> > Envoyé : samedi 4 octobre 2025 00:20
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail]
> > Objet : [OPS-DIR]draft-ietf-idr-vpn-prefix-orf-22 early Opsdir
> > review
> >
> > Document: draft-ietf-idr-vpn-prefix-orf
> > Title: VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
> > Reviewer: Aihua Guo
> > Review result: Has Issues
> >
> > 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
> >
> >
> > _______________________________________________
> > OPS-DIR mailing list -- [e-mail] To unsubscribe send an
> > email to [e-mail]
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>