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

[Keyur Patel <[e-mail]>]

Thanks Med. We will do the needful.

Best Regards,
Keyur

> On May 20, 2026, at 3:50 AM, [e-mail] wrote:
> 
> Hi Aijun, all,
> 
> Thank you for the changes. I cleared my DISCUSS right now.
> 
> Please note that there are some points that were agreed in the thread but for which I don't see the changes were implemented. I listed those in my new ballot. I trust you will take care of those.
> 
> Thank you for your patience.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Aijun Wang <[e-mail]>
>> Envoyé : mercredi 20 mai 2026 04:06
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>;
>> [e-mail]; '【外部账号】 Ketan Talaulikar'
>> <[e-mail]>
>> Cc : 'The IESG' <[e-mail]>; draft-ietf-idr-vpn-prefix-
>> [e-mail]; [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Objet : RE: [Idr] Re: [iesg] Re: Mohamed Boucadair's Discuss on
>> draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)
>> 
>> 
>> Hi, Med:
>> 
>> We have posted the new version and changed the related text to
>> less affirmative tense.
>> Wish it can address your concern.
>> 
>> Thanks for your review and the discussions！
>> 
>> To Ketan: can we end the IESG Last call and forward it then?
>> 
>> Aijun
>> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of
>> [e-mail]
>> Sent: Monday, May 18, 2026 9:39 PM
>> To: [e-mail]; '【外部账号】 Ketan Talaulikar'
>> <[e-mail]>
>> Cc: 'The IESG' <[e-mail]>; draft-ietf-idr-vpn-prefix-
>> [e-mail]; [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: [Idr] Re: [iesg] Re: Mohamed Boucadair's Discuss on
>> draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)
>> 
>> Hi Aijun,
>> 
>> Thank you for the follow-up. Focusing on this part:
>> 
>>> [WAJ] ...
>>> We can consider to change some rephrases in the document if you
>> think
>>> they are too affirmative.
>> 
>> Yes, please. Thanks.
>> 
>> Cheers,
>> Med
>> 
>>> -----Message d'origine-----
>>> De : [e-mail] <[e-mail]> Envoyé :
>> jeudi
>>> 14 mai 2026 04:55 À : '【外部账号】 Ketan Talaulikar'
>>> <[e-mail]>; BOUCADAIR Mohamed INNOV/NET
>>> <[e-mail]> Cc : 'The IESG' <[e-mail]>;
>>> draft-ietf-idr-vpn-prefix- [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail] Objet : [iesg]
>> Re:
>>> Mohamed Boucadair's Discuss on draft-ietf-idr-
>>> vpn-prefix-orf-40: (with DISCUSS and COMMENT)
>>> 
>>> 
>>> Hi, Med:
>>> 
>>> It seems that you are concerning the efficiency of this
>> approach,
>>> especially comparing with other existing mechanisms.
>>> Let's review the proposal from another point of view:
>>> 
>>> As indicated in
>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-vpn-prefix-
>> orf-
>>> 40%23name-existing-
>>> 
>> solutions&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a74
>>> 
>> 63d34068362508deb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
>>> 
>> 0%7C639143241083331048%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
>>> 
>> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
>>> 
>> Q%3D%3D%7C0%7C%7C%7C&sdata=sYUKKjHil6Kuf27s2FkgPhjgtRqsX7HZKp0kcAW
>>> hFxc%3D&reserved=0, the most relevant solution to such scenario,
>> is to
>>> configure the PE-CE maximum prefix at each remote side PE, the
>>> receiving PE can only act passively for the potential overload
>> VPN
>>> routes risks.
>>> Any misconfiguration on any remote PE can lead to such outrage.
>>> 
>>> Then we think it is necessary to enhance the BGP protocol to let
>> it
>>> can control or mitigate such outrage actively, especially in the
>>> shared BGP sessions scenarios(various VPN circumstances).
>>> Some detail responses are inline below.
>>> 
>>> Aijun
>>> 
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of 【外部账号】
>>> Ketan Talaulikar
>>> Sent: Wednesday, May 13, 2026 4:01 PM
>>> To: [e-mail]
>>> Cc: The IESG <[e-mail]>; draft-ietf-idr-vpn-prefix-
>> [e-mail];
>>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>>> Subject: Re: [iesg] Mohamed Boucadair's Discuss on draft-ietf-
>> idr-
>>> vpn-prefix-orf-40: (with DISCUSS and COMMENT)
>>> 
>>> Hi Med,
>>> 
>>> To be clear, can you confirm that your comment is specific to
>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
>> ww.ietf.org%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C38b
>> f3581c4784707e64308deb6144f21%7C90c7a20af34b40bfbc48b9253b6f5d20%7
>> C0%7C0%7C639148395523819563%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
>> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
>> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=E3yr3JVOPNTtwgEFmyrWtLracIs2mFJSx5
>> V3jG1L18g%3D&reserved=0%2Farchive%2Fid%2Fdraft-ietf-idr-vpn-
>> prefix-orf-
>>> 40.html%23name-vpn-prefix-orf-tlv-
>>> 
>> types&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a7463d3
>>> 
>> 4068362508deb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
>>> 
>> 639143241083349712%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
>>> 
>> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
>>> 
>> %3D%7C0%7C%7C%7C&sdata=wEp%2FkDvBtYFeuhBADPGHR7Bl3giS6HEBlGNHhOF78
>>> h4%3D&reserved=0
>>> ?
>>> 
>>> Assuming yes, I can't say whether or not the WG will endorse
>> further
>>> extensions or proposals. That would be something for the WG to
>> decide
>>> when something comes up. Is it required to preclude this or
>> constrain
>>> the WG?
>>> [WAJ] These TLVs are necessary even for the one-hop VPN Prefix
>> ORF
>>> message.
>>> 
>>> Is your concern with the FCFS allocation under this registry?
>> And if
>>> so, perhaps the authors and WG can consider changing the entire
>>> codepoint space to IETF Review.
>>> [WAJ] This is newly created code point, and has no conflict with
>> any
>>> other existing code points.
>>> 
>>> Thanks,
>>> Ketan
>>> 
>>> 
>>> On Wed, May 13, 2026 at 8:24 AM <[e-mail]>
>>> wrote:
>>> 
>>>> Re-,
>>>> 
>>>> 
>>>> 
>>>> Thanks Ketan.
>>>> 
>>>> 
>>>> 
>>>> I’m not sure to get the point about the BGP hygiene here.
>>> Creating new
>>>> registries (read, allow for future extensions that may or may
>>> not
>>>> come) for a feature to be yet assessed is a bit weird. Does
>> the
>>> WG
>>>> envisage to endorse extensions based on this feature without
>>> waiting
>>>> for stable/sufficient experience with the base spec?
>>> 
>>> [WAJ] Such new registries are necessary even for the one-hop VPN
>>> prefix ORF mechanism.
>>> 
>>>> 
>>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> Med
>>>> 
>>>> 
>>>> 
>>>> *De :* Ketan Talaulikar <[e-mail]> *Envoyé :*
>>> mercredi 13
>>>> mai 2026 09:11 *À :* BOUCADAIR Mohamed INNOV/NET
>>>> <[e-mail]> *Cc :* The IESG
>> <[e-mail]>;
>>>> [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail];
>>> [e-mail]
>>>> *Objet :* Re: [iesg] Mohamed Boucadair's Discuss on
>>>> draft-ietf-idr-vpn-prefix-orf-40: (with DISCUSS and COMMENT)
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Hi Med,
>>>> 
>>>> 
>>>> 
>>>> Thanks for sharing your updated ballot. Please see the inline
>>>> responses below.
>>>> 
>>>> 
>>>> 
>>>> I request the authors to consider this for the upcoming
>> document
>>> update.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Wed, May 13, 2026 at 7:47 AM Mohamed Boucadair via
>>> Datatracker <
>>>> [e-mail]> wrote:
>>>> 
>>>> Mohamed Boucadair has entered the following ballot position
>> for
>>>> draft-ietf-idr-vpn-prefix-orf-40: 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.)
>>>> 
>>>> 
>>>> Please refer to
>>>> 
>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> www.
>>>> ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-
>> ballot-
>>> posi&d
>>>> 
>>> 
>> ata=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a7463d34068362
>>> 508d
>>>> 
>>> 
>> eb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63914324108
>>> 3370
>>>> 
>>> 
>> 337%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
>>> AwMC
>>>> 
>>> 
>> IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
>>> ata=
>>>> sypyvGyAVsS%2BXWj8u1dffotyh17NY6U1wjpNXSWIa6w%3D&reserved=0
>>>> tions/ for more information about how to handle DISCUSS and
>>> COMMENT
>>>> positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found
>>> here:
>>>> 
>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> data
>>>> tracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-vpn-prefix-
>>> orf%2F&data=05%7C02
>>>> 
>>> 
>> %7Cmohamed.boucadair%40orange.com%7C48659a7463d34068362508deb16433
>>> 00%7
>>>> 
>>> 
>> C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639143241083404175%7CU
>>> nkno
>>>> 
>>> 
>> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiO
>>> iJXa
>>>> 
>>> 
>> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MBzQ4oQ
>>> A8Wc
>>>> 4ZlpfZGEuxQvSnMitWhUsUdS8LbjC%2BaA%3D&reserved=0
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------
>> --
>>> ------
>>>> DISCUSS:
>>>> --------------------------------------------------------------
>> --
>>> ------
>>>> 
>>>> Hi Wei, Aijun, Haibo, Gyan, and Jie,
>>>> 
>>>> Thank you for the discussion and changes made so far. I
>> updated
>>> my
>>>> ballot [1] to reflect the changes made 37/40 [2].
>>>> 
>>>> # 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 ..”
>>>> 
>>>> UPDATE: I still see this statement in the document. I don't
>>> think we
>>>> can claim this compared to controlling the load at the source
>>>> (attachment circuit
>>>> level)
>>>> or by policy. Whether this is an improvement or the mechanism
>>> has
>>>> positive impact in general is to be assessement. That's the
>>> whole
>>>> poingt of having this mechanums as Experimental. Please review
>>> such
>>>> claims in the document and expresss them as "intended" rather
>>> than
>>>> affirmative.
>>> 
>>> [WAJ] Depending on the policy, or at the attachment circuit
>> level
>>> can't eliminate the risks of overload VPN routes.
>>> The PE itself should have also some risk mitigation mechanism.
>>> This is similar as for maximum prefix mechanism, in which, the
>>> receiver of overload prefixes can break down the BGP session
>> directly.
>>> We can consider to change some rephrases in the document if you
>> think
>>> they are too affirmative.
>>> 
>>>> 
>>>> 
>>>> 
>>>> KT> I see your point. Authors, please consider rephrasing
>> those
>>>> KT> statements
>>>> as intents or goals rather than affirmations.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> # 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.
>>>> 
>>>> 
>>>> 
>>>> KT> Yes, we do need those registries. This ensures an up-to-
>> date
>>> and
>>>> accurate reflection of code points for BGP features. Because
>> BGP
>>> has a
>>>> continuous flow of features, I consider this as necessary
>>> hygiene
>>>> regardless of the document's intended status.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------
>> --
>>> ------
>>>> COMMENT:
>>>> --------------------------------------------------------------
>> --
>>> ------
>>>> 
>>>> # 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] Actually,
>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-idr-vpn-prefix-
>> orf-
>>> 40%23name-general-considerations-for-
>>> 
>> &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C48659a7463d340683
>>> 
>> 62508deb1643300%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63914
>>> 
>> 3241083453858%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
>>> 
>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
>>> 
>> C0%7C%7C%7C&sdata=vIW1HUhSuMuRrG7gMjRNfF8uMIS1tQ0JmzWiRhchtqE%3D&r
>>> eserved=0 has already added some descriptions.
>>> If you expect some quantitative results, it should be provided
>> fairly
>>> via some open test and comparison? But I doubt it can compare
>> with the
>>> complex policy, error-prone approach.
>>> Anyway, we think controlling, or depending only on the remote
>> peers'
>>> behavior is not enough.
>>> 
>>>> 
>>>> 
>>>> 
>>>> KT> I will leave this to the authors' discretion. I am not
>> sure
>>> how
>>>> KT> much
>>>> such discussions (which are essentially individual opinions)
>>> help when
>>>> captured in a protocol specification (even an experimental
>> one).
>>> If
>>>> you have suggestions for potential issues that can be added
>>> (beyond
>>>> what came out of the WG and got captured in the document),
>> those
>>> would
>>>> be very welcome.
>>> 
>>> [WAJ] I agree with Ketan.
>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> # 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
>>>> 
>>>> 
>>>> 
>>>> KT> I will leave this to the authors, the WG and seek the WG
>>> chairs'
>>>> KT> help=
>> 
>> __________________________________________________________________
>> __________________________________________
>> 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.
>> _______________________________________________
>> 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.
> [EXTERNAL]