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

[Aijun Wang <[e-mail]>]

Hi, Med:

Thanks for your comments. We are preparing the update to address your concerns, let's try to make consensus via the mail.
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.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-vpn-prefix-orf/



----------------------------------------------------------------------
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 ..”

# 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

## 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)

## 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"


# 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://datatracker.ietf.org/doc/html/rfc5291#section-5, 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.

# 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"
…

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

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.

# 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.

# 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.


# 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.

# 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.


----------------------------------------------------------------------
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.

# 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.

# 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. 


## 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 "?
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.

# 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.

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.

# 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.

# 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.  


# 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... ..."?

# 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.

Cheers,
Med



_______________________________________________
Idr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]