[Idr] Re: Mohamed Boucadair's Discuss on draft-ietf-idr-vpn-prefix-orf-37: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Aijun, 

Thank you for the follow-up. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Aijun Wang <[e-mail]>
> Envoyé : lundi 27 avril 2026 05:14
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
> 'The IESG' <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : RE: [Idr] Mohamed Boucadair's Discuss on draft-ietf-idr-
> vpn-prefix-orf-37: (with DISCUSS and COMMENT)
> 
> Hi, Med:
> 
> Thanks for your comments. We are preparing the update to address
> your concerns, let's try to make consensus via the mail.

[Med] ACK

> Please see the replies inline[WAJ] below.
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Mohamed
> Boucadair via Datatracker
> Sent: Sunday, April 26, 2026 1:53 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: [Idr] Mohamed Boucadair's Discuss on draft-ietf-idr-vpn-
> prefix-orf-37: (with DISCUSS and COMMENT)
> 
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-idr-vpn-prefix-orf-37: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> 
> ------------------------------------------------------------------
> DISCUSS:
> ------------------------------------------------------------------
> 
> Hi Wei, Aijun, Haibo, Gyan, and Jie,
> 
> Thank you for the effort put into this document. Thanks also to
> Keyur of the great write-up.
> 
> Thanks Aihua Guo for the OPSDIR review and to the authors for the
> changes made in -23.
> 
> Given the intended status, my review focuses on the overall
> consistency and claimed goals not much about the low level details
> of the procedure. Please find below some points for DISCUSSion:
> 
> # Be less affirmative
> 
> I don't think it is adequate to be affirmative about the
> enhancements in the spec as that need to be further assessed. I
> suggest to consider the various affirmative statements in the doc
> and make those as to be further confirmed as part of the
> experiment.
> 
> Example of such statements are "The VPN Prefix ORF mechanism
> improves upon this by enabling the .."

[Med] I assume this will be checked and adjusted as appropriate.

> 
> # Better than existing techniques
> [WAJ]: In section 3, we analyze the drawback of existing
> solutions, and the proposed VPN prefixes ORF is expected to
> control the VPN routes advertisement in more finer manner than the
> existing solutions.
> All the current solutions can't meet the finer control
> requirements, especially in the shared BGP session scenario.
> 
> We say in the document:
> 
> CURRENT:
>    Upon receiving a VPN
>    Prefix ORF entry, the BGP speaker filters and withdraws any
> overload
>    VPN routes that were previously announced to its peer.
> 
> ## But, what if it doesn't?
> [WAJ] If the VPN prefix ORF receiver doesn't withdraw such
> overload VPN routes, then, the continuous advertisement/parsing of
> such overloaded routes will impact the performances of other VPN
> routes within the same and different VRFs

[Med] Yes, this is a direct implication (which actually need to be added to your OPS CONS section). More importantly, my point is that you will need some local action to soften that "performance degradation" and that the signaling alone may not be sufficient if the receiver doesn't act upon. 

One approach here is to argue that the feature is expected to be deployed in intra and that it should be enabled only when it is consistently configured in a domain.

> 
> ## Why we expect that it will react to this notification while the
> prefix max was already known to that peer?
> [WAJ] No. In the intra-domain scenario, PE is peering with the RR.
> RR have no knowledge the prefix max on each VRF of the peer PE.
>       RR can only control the max advertised prefixes on the BGP
> session with the PE(the maximum value is shared with all the VRFs
> in the PE)

[Med] Understood. My comment was on the control at the source (control on an attachment circuit). Both mechanisms rely on the sender to adhere to a max that is know them: either by config or dynamically in BGP itself. This is actually linked to my previous comment about being less affirmative: this is an aspect you can further investigate/explore as part the experiment: control at the source vs. dynamic signal within the shared session.

> 
> ## The statement is a bit not aligned with the informative nature
> of the signal in the main spec: withdraws != SHOULD withdraw:
> 
> CURRENT:
>    *  Overload VPN routes process method (1 bit): if the value is
> set to
>       0, it means the receiver of such message SHOULD withdraw all
>       previously advertised overload VPN routes that match the
> ORF's
>       type-specific part.  If the value is set to 1, it means the
> sender
>       of the VPN Prefix ORF message will refuse to accept new
> overload
>       VPN routes and that the receiver of the VPN Prefix ORF
> message
>       SHOULD NOT announce new overload VPN routes.  The default
> value is
>       0.
> [WAJ] Would it be better to change all the "SHOULD" to "MUST", and
> "SHOULD NOT" to "MUST NOT", to enhance the confirmative tone of
> this document?
>       Same as your following comments regarding to the
> "SHOULD/SHOULD NOT"
> 

[Med] I think that MUST is more aligned with the objective you set for the procedure. If the ORF carries only a hint and left it to the receiver to decide, then you won't get the expected benefits.

> 
> # Deployment dependency
> 
> CURRENT:
>    The VPN Prefix ORF mechanism improves upon this by enabling the
>    overloaded PE to signal the specific overload routes back to
> the
>    sender.
> 
> This assumes the peer has to support this.
> [WAJ] Yes, the support of the VPN Prefix ORF capabilities should
> be known between the peers before sending such signal.
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5291%23section-
> 5&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C05473dfef4a14f21
> 3b3d08dea40b21b0%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6391
> 28564895334035%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=k9K1VOxlpes3cCRGSe4R%2F2yvsVPhTP1LazyodM9pB5c%3
> D&reserved=0, we would like to add the following description at
> the beginning of section 5(before section 5.1):
> 
> " A BGP speaker that is willing to receive VPN Prefix ORF entries
> from its peer,
>    or would like to send VPN Prefix ORF ORF entries to its peer
> SHOULD advertise the
>    Outbound Route Filtering Capability to the peer using BGP
>    Capabilities advertisement RFC 3392"
> 
> 
> That needs to be agreed by some channel (e.g., L3SM). If such
> channel exists, why not the max indicated isn't honored at the
> first place?
> [WAJ] Please see the above explanations. It will depend on the BGP
> Capabilities advertisement. And the max prefix limit for each VRF
> can't be known in existing mechanism.

[Med] This is a SHOULD for the capability advertisement. Absent other mechanisms, the max control can't be used even if supported by a local peer. The point I'm trying to make here is that enabling the feature locally does not give you the immediate expected/claimed benefits. Please consider highlighting this better in the operational considerations section.

> 
> # Please check almost all the SHOULD uses in the document [WAJ]
> Yes, will try to replace "SHOULD" to "MUST" when appropriate.
> 
> For example, why the following is not a MUST?
> 
> CURRENT:
>       If the received ORF entry contains an
>       unrecognized value(0x11), such an ORF entry SHOULD be
> removed.
> [WAJ] Will update to "MUST"

[Med] ACK.

> .
> 
>       The sequence number SHOULD be monotonically increasing for
>       each ORF update.
> and many other similar constructs.
> [WAJ] Will revise the related descriptions.

[Med] Thanks.

> 
> The lack of clear language will make the comparison of
> experimental data difficult to compare.
> 
> Please double check your use through the document.
> [WAJ] Will check through the document.

[Med] ACK.

> 
> # I don't quite understand why we do have the following note:
> 
> CURRENT:
>       Note well, this bit is specific to the ORF Type introduced
> by
>       this document and MUST be ignored (i.e., considered to be 0)
> for
>       all other ORF Types.

[Med] Any comment on this one?

> 
> # Internal inconsistency
> 
>       If one or more TLV(s) are unrecognized, the
>       entire VPN Prefix ORF entry SHOULD be discarded.
> 
> Vs.
> 
>    If an ORF entry contains multiple Source PE TLVs, the entire
>    ORF entry MUST be ignored.
> 
> Vs.
> 
>    If an ORF entry contains multiple Source AS TLVs, the entire
>    entry SHOULD be ignored.
> 
> Why do we have different behaviors?
> [WAJ]: Will try to make them consistency.

[Med] ACK.

> 
> 
> # Scope Clarity: intra vs inter
> 
> Section 4.2
> 
>    The Source AS TLV is defined to identify the source AS number
> of the
>    source PE.  It is only required in inter-domain scenarios.
> 
> Section 7.1
> 
>    The VPN Prefix ORF mechanism is designed for intra-domain
> BGP/MPLS IP
>    VPN [RFC4364] and BGP/MPLS Ethernet VPN (EVPN) [RFC7432]
> deployments
> 
> The two excerpt are conflicting. Please double check.
> [WAJ] Will remove the source AS TLV at this stage, and leave it in
> future inter-as solution.

[Med] Great. Please consider adding a mention about the intra- intended scope early in the document (e.g., abstract and introduction). Thanks. 

> 
> # De we really need to create new registries at this stage?
> 
> Given the current state of the technology, I don't see appealing
> arguments to create new registries under the BGP registry group
> for a feature that need further assessment.
> [WAJ] We can consider remove the "Source AS TLV" registry at the
> current stage, because actually it belongs to the future inter-as
> scenario.
> 

[Med] ACK for the source AS. 

I still think that we can remove all the new sub-registries.

> 
> ------------------------------------------------------------------
> COMMENT:
> ------------------------------------------------------------------
> 
> # Clarity: Shared Session & Experimental
> 
> ## Given the intended scope, make it clear in the title this is
> about Shared BGP Sessions + Experimental
> 
> OLD:
>   VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
> 
> NEW:
>   An Experimental VPN Prefix Outbound Route Filter (VPN Prefix
> ORF) for Shared
>   BGP Sessions
> 
> ## Also, echo that in the abstract
> 
> OLD: This draft defines a new type
> 
> NEW: This document defines an experimental new type
> 
> [WAJ] We prefer to keeping the status of this document as
> "Experimental", don't expand it in every corner of document which
> will let the contents of the document redundancy.

[Med] Abstracts and Titles are circulated outside RFC metadata. Having an accurate description of the mechanism contributes to set the context right. I'd like us to lake that clear for readers.

> 
> # Keyur included the following in his write-up:
> 
> "The third version of the text was clear, but the operators were
> split in their opinion on whether the functions was valuable or
> dangerous."
> 
> I would expect the document to include a discussion of the
> potential issues that need assessment for confirmation/information
> as a part of the experimental work.
> 
> Can we please have such discussion in the document?
> [WAJ] We will try to add one additional section in section 7
> "Operational Considerations" to discuss the possible challenges
> that are arose from this mechanism.

[Med] Great. Thanks.

> 
> # Experiment Goals
> 
> I suggest to move at least appendix "Experimental topology" to be
> in the main body for better visibility of the intended scope. I
> also suggest that text to be expanded to cover some items that
> will be assessed and used as objective criteria to declare success
> or failure. For example, it would be helpful to have some data
> about:
> 
> * impact on the routing stability
> * impact on the CPU vs configuration
> * overall efficiency
> * tune the quota formula and its optimization
> * operational complications
> [WAJ] We will try to add one general intra-domain topology in the
> beginning of the section 7, and analyze the above concerns.

[Med] ACK.

> 
> 
> ## Also, the following should be part of the assessment in the
> exp, unless you already have data to back the claims:
> 
>    However, PEs still need to parse the incoming BGP messages,
>    which consumes CPU cycles and further burdens the overloaded
> PE.
> 
> This is still applicable even with the feature in the draft if the
> peer does not honor the signal.
> [WAJ] The above is just "qualitative analysis", not "quantitative
> analysis".  Is there any inaccurate for the " qualitative analysis
> "?

[Med] I'm afraid...espcially that you still need to do some local treatment to soften the impact of the load if the peer does not honor the signal.

> And, if the peer does not honor the signal, it fallbacks to the
> existing solution and then is not the fault of the proposed VPN
> prefix ORF mechanism?
> 
> ## The following may have implication on stability. Please
> consider adding assessing that impact as part of the aspects to be
> assessed during exp work:
> 
> CURRENT:
>    Each device makes a local judgment to determine whether
>    it needs to send a VPN Prefix ORF message to its upstream peer.
> [WAJ] Here, the local judgement is meant to the related
> algorithm("quantitative analysis") is done by the PE itself, and
> it can only be realized by the PE itself.

[Med] this needs to be translated into a logic/heuristic that will be followed by an implem. The impact will depend on the implementation of that logic.

> 
> # Missing citation
> 
> CURRENT:
> *  Provider Edge (PE) - Customer Edge (CE) edge peer Maximum
> Prefix
> 
> You may cite rfc9182#section-7.6.3.2 (bgp-max-prefix, warning-
> threshold, violate-action).
> [WAJ] Will add the reference.

[Med] ACK

> 
> This is also part of site-maximum-routes in the L3SM (RFC8299).
> [WAJ] The "site-maximum-routes" should be mainly used for the PE-
> CE connection, not for the PE-RR connection.

[Med] Yes, but the text I quoted is about CE-PE :-)

> 
> # Device?
> 
> CURRENT:
>   the device SHOULD check whether the RT included in
> 
> There are several similar uses in the document. It is not clear
> what are we referring to here. BGP peer, BGP speaker, ASBR, else?
> [WAJ] In section 4.3, "the device" will be updated to "the VPN
> Prefix ORF receiver".
>      In section 5.1,  "the device" will be updated to "the VPN
> Prefix ORF sender"
>      There is no other occurrence for such descriptions.

[Med] This is better. Please note that you have 14 occurrences of device in the doc; almost all need to be changed to BGP-specific term. Thanks. 

> 
> # Threshold vs Maximum
> 
> CURRENT:
>    S02.     If (the total number of received prefixes + the number
>             of prefixes already inVRF v exceeds its configured
>             prefix limit) {
> 
> ## Waiting for the max to be fired may be too late
> 
> ## Shouldn't be more optimal to have a threshold (lower than the
> max) to anticipate new ones ?
> 
> ## Should that be part of the aspects to explored in the
> experiments?
> [WAJ] Actually, in the standard document, we consider the max
> "prefix limit" has already some redundancy.
> Or else, if we introduce the concept of threshold, there will be
> another parameter needs to be standardized.
> And, actually, the implementers can determine themselves the
> criteria to trigger the VPN Prefix ORF mechanism.

[Med] This is fair. 

> 
> 
> # A PE may have multiple ASN!
> 
> CURRENT:
>   The AS number of the source PE can be conveyed by the Source AS
> 
> A PE can have multiple ASNs, including private one. Some clarity
> is needed here.
> [WAJ] Will it be more clear that we change the description from
> "The AS number of the source PE...."  to "The peering AS number of
> the source PE... ..."?
> 

[Med] This is better. 

> # The formula should be part of further investigation as part of
> the experimental work. You may add an item about this
> 
> CURRENT:
>    To avoid frequent changes to the quota value, the value SHOULD
> be set
>    based on the following formula:
> 
>    Quota=MIN[(Margins coefficient)*<PE,CE limit>*<Number of PEs
> within
>    the VPN, includes the possibility of expansion in futures>, VRF
>    Prefixes Limit]
> 
> # Inappropriate use of normative language
> 
> OLD:
>    It SHOULD be noted that the above formula is only an example;
>    operators can use different formulas based on actual needs in
> the
>    management plane.
> 
> NEW:
>    It should be noted that the above formula is only an example;
>    operators can use different formulas based on actual needs in
> the
>    management plane.
> [WAJ] OK, will update the above sentence.

[Med] ACK

> 
> Cheers,
> Med
> 
> 
> 
> _______________________________________________
> Idr 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.