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

[[e-mail]]

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
> www.ietf.org%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.