[Idr] Re: Jeff's review on draft-ietf-idr-vpn-prefix-orf-12

[Wei Wang <[e-mail]>]

Hi Jeffrey,


Thanks for your comments.
We updated -v14 of draft-ietf-idr-vpn-prefix-orf:https://datatracker.ietf.org/doc/html/draft-ietf-idr-vpn-prefix-orf-14
And please see my in-line replies with [WW]


Best Regards,
Wei Wang
China Telecom


        



         原始邮件
         
       
发件人：Jeffrey Haas <[e-mail]&gt;
发件时间：2025年5月22日 21:54
收件人：Wei Wang <[e-mail]&gt;
抄送：draft-ietf-idr-vpn-prefix-orf <[e-mail]&gt;, idr <[e-mail]&gt;
主题：Re: Jeff's review on draft-ietf-idr-vpn-prefix-orf-12



       Wei&nbsp;Wang,

Thanks&nbsp;for&nbsp;addressing&nbsp;my&nbsp;comments&nbsp;to&nbsp;date.&nbsp;&nbsp;A&nbsp;few&nbsp;more&nbsp;comments&nbsp;in&nbsp;this&nbsp;reply;


&gt;&nbsp;On&nbsp;May&nbsp;22,&nbsp;2025,&nbsp;at&nbsp;2:37&nbsp;AM,&nbsp;Wei&nbsp;Wang&nbsp;<[e-mail]&gt;&nbsp;wrote:
&gt;&nbsp;Note&nbsp;that&nbsp;this&nbsp;section&nbsp;also&nbsp;updates&nbsp;route&nbsp;reflection&nbsp;procedures.&nbsp;&nbsp;This&nbsp;potentially&nbsp;means&nbsp;needing&nbsp;to&nbsp;flag&nbsp;"updates&nbsp;RFC&nbsp;4456".&nbsp;&nbsp;
&gt;&nbsp;[WW]:&nbsp;In&nbsp;the&nbsp;end&nbsp;of&nbsp;this&nbsp;Section,&nbsp;we&nbsp;added&nbsp;the&nbsp;sentence&nbsp;“This&nbsp;section&nbsp;updates&nbsp;route&nbsp;reflection&nbsp;procedures,&nbsp;which&nbsp;means&nbsp;RFC4456&nbsp;need&nbsp;to&nbsp;be&nbsp;updated.”

Normally&nbsp;this&nbsp;would&nbsp;mean&nbsp;the&nbsp;document's&nbsp;status&nbsp;would&nbsp;be&nbsp;"update&nbsp;rfc&nbsp;4456"&nbsp;as&nbsp;part&nbsp;of&nbsp;the&nbsp;RFC&nbsp;header.&nbsp;&nbsp;However,&nbsp;this&nbsp;is&nbsp;a&nbsp;good&nbsp;start&nbsp;to&nbsp;note&nbsp;the&nbsp;consideration&nbsp;while&nbsp;we&nbsp;discuss&nbsp;how&nbsp;it&nbsp;is&nbsp;finally&nbsp;resolved.
[WW]: Thank you. We have added this information in -v14.
&gt;&nbsp;VPN&nbsp;Prefix&nbsp;Limit&nbsp;is&nbsp;defined&nbsp;here.&nbsp;&nbsp;Later&nbsp;on&nbsp;in&nbsp;section&nbsp;7&nbsp;it's&nbsp;discussed&nbsp;that&nbsp;this&nbsp;value&nbsp;is&nbsp;checked.&nbsp;&nbsp;However,&nbsp;there's&nbsp;no&nbsp;normative&nbsp;procedure&nbsp;that&nbsp;defines&nbsp;how&nbsp;the&nbsp;receiver&nbsp;of&nbsp;the&nbsp;ORF&nbsp;is&nbsp;to&nbsp;calculate&nbsp;whether&nbsp;a&nbsp;route&nbsp;counts&nbsp;versus&nbsp;a&nbsp;given&nbsp;prefix&nbsp;limit.&nbsp;
&gt;&nbsp;
&gt;&nbsp;Prior&nbsp;IDR&nbsp;list&nbsp;discussion&nbsp;had&nbsp;gone&nbsp;back&nbsp;and&nbsp;forth&nbsp;on&nbsp;whether&nbsp;this&nbsp;is&nbsp;tracked&nbsp;per&nbsp;RD,&nbsp;or&nbsp;per&nbsp;route-target.&nbsp;&nbsp;Even&nbsp;knowing&nbsp;that,&nbsp;it's&nbsp;not&nbsp;clear&nbsp;to&nbsp;me&nbsp;in&nbsp;the&nbsp;draft&nbsp;how&nbsp;it&nbsp;works.
&gt;&nbsp;[WW]:&nbsp;The&nbsp;description&nbsp;of&nbsp;VRF&nbsp;Prefix&nbsp;Limit&nbsp;has&nbsp;been&nbsp;changed&nbsp;to&nbsp;“VRF&nbsp;Prefix&nbsp;Limit:&nbsp;carrying&nbsp;the&nbsp;prefix&nbsp;limit&nbsp;of&nbsp;the&nbsp;overflowed&nbsp;VRF.&nbsp;This&nbsp;value&nbsp;is&nbsp;calculated&nbsp;based&nbsp;on&nbsp;RT(s)&nbsp;of&nbsp;the&nbsp;VRF.&nbsp;The&nbsp;VPN&nbsp;Prefix&nbsp;ORF&nbsp;receiver&nbsp;SHOULD&nbsp;stop&nbsp;sending&nbsp;VPN&nbsp;routes&nbsp;with&nbsp;RT(s)&nbsp;that&nbsp;contains&nbsp;in&nbsp;the&nbsp;VPN&nbsp;Prefix&nbsp;ORF&nbsp;entry.&nbsp;For&nbsp;the&nbsp;Source&nbsp;PE&nbsp;of&nbsp;a&nbsp;VPN&nbsp;Prefix&nbsp;ORF&nbsp;entry,&nbsp;once&nbsp;the&nbsp;number&nbsp;of&nbsp;qualifying&nbsp;VPN&nbsp;routes&nbsp;sent&nbsp;by&nbsp;the&nbsp;receiver&nbsp;of&nbsp;the&nbsp;VPN&nbsp;Prefix&nbsp;ORF&nbsp;entry&nbsp;to&nbsp;the&nbsp;Source&nbsp;PE&nbsp;has&nbsp;reached&nbsp;the&nbsp;VPN&nbsp;Prefix&nbsp;Limit,&nbsp;the&nbsp;receiver&nbsp;shall&nbsp;stop&nbsp;sending&nbsp;additional&nbsp;qualifying&nbsp;VPN&nbsp;routes&nbsp;to&nbsp;that&nbsp;Source&nbsp;PE.”

If&nbsp;I&nbsp;were&nbsp;to&nbsp;restate&nbsp;this,&nbsp;the&nbsp;desire&nbsp;here&nbsp;is&nbsp;that&nbsp;the&nbsp;prefix-limit&nbsp;is&nbsp;the&nbsp;counter&nbsp;of&nbsp;BGP&nbsp;Routes&nbsp;that&nbsp;match&nbsp;the&nbsp;ORF.&nbsp;&nbsp;Is&nbsp;this&nbsp;correct?&nbsp;&nbsp;If&nbsp;so,&nbsp;that&nbsp;is&nbsp;clear.
[WW]: Yes.
What&nbsp;remains&nbsp;a&nbsp;challenge&nbsp;is&nbsp;when&nbsp;those&nbsp;filters&nbsp;are&nbsp;matched.&nbsp;&nbsp;This&nbsp;again&nbsp;becomes&nbsp;a&nbsp;question&nbsp;as&nbsp;to&nbsp;whether&nbsp;the&nbsp;sequence&nbsp;number&nbsp;is&nbsp;used&nbsp;to&nbsp;sort&nbsp;the&nbsp;ORFs.

If&nbsp;the&nbsp;ORFs&nbsp;are&nbsp;sorted&nbsp;by&nbsp;sequence&nbsp;number&nbsp;rather&nbsp;than&nbsp;order&nbsp;that&nbsp;they&nbsp;are&nbsp;received,&nbsp;things&nbsp;are&nbsp;clear.&nbsp;&nbsp;However,&nbsp;it&nbsp;also&nbsp;means&nbsp;that&nbsp;if&nbsp;ORFs&nbsp;are&nbsp;added&nbsp;or&nbsp;removed,&nbsp;it&nbsp;becomes&nbsp;necessary&nbsp;to&nbsp;re-calculate&nbsp;the&nbsp;prefix-limits&nbsp;matched&nbsp;for&nbsp;that&nbsp;RIB-OUT&nbsp;for&nbsp;that&nbsp;set&nbsp;of&nbsp;ORFs.

Is&nbsp;this&nbsp;the&nbsp;desired&nbsp;procedure?
[WW]: Actually, the VPN Prefix Limit is calculated by the sender of the VPN Prefix ORF entry. Then, it is carried in the ORF entry and sent to the receiver. So the receiver does not need to re-calculate its value.
&gt;&nbsp;For&nbsp;your&nbsp;type&nbsp;3&nbsp;Source&nbsp;PE&nbsp;Identifier&nbsp;TLV,&nbsp;what&nbsp;is&nbsp;your&nbsp;procedure&nbsp;if&nbsp;the&nbsp;reflector&nbsp;that&nbsp;attached&nbsp;the&nbsp;ORIGINATOR&nbsp;attribute&nbsp;did&nbsp;not&nbsp;also&nbsp;attach&nbsp;the&nbsp;extended&nbsp;community?&nbsp;&nbsp;
&gt;&nbsp;[WW]:&nbsp;In&nbsp;Section&nbsp;5,&nbsp;we&nbsp;defined&nbsp;the&nbsp;following&nbsp;procedures:
&gt;&nbsp;“For&nbsp;the&nbsp;RR/ASBR,&nbsp;it&nbsp;should&nbsp;perform&nbsp;as&nbsp;following:
&gt;&nbsp;	•&nbsp;Check&nbsp;the&nbsp;existence&nbsp;of&nbsp;the&nbsp;SPE&nbsp;EC.&nbsp;If&nbsp;it&nbsp;exists,&nbsp;does&nbsp;not&nbsp;change&nbsp;it.
&gt;&nbsp;	•&nbsp;If&nbsp;SPE&nbsp;EC&nbsp;does&nbsp;not&nbsp;exist,&nbsp;check&nbsp;the&nbsp;existence&nbsp;of&nbsp;ORIGINATOR_ID.&nbsp;If&nbsp;it&nbsp;exists,&nbsp;put&nbsp;it&nbsp;into&nbsp;SPE&nbsp;EC.
&gt;&nbsp;	•&nbsp;If&nbsp;ORIGINATOR_ID&nbsp;does&nbsp;not&nbsp;exist,&nbsp;put&nbsp;the&nbsp;router-id&nbsp;of&nbsp;source&nbsp;PE&nbsp;into&nbsp;SPE&nbsp;EC.”
&gt;&nbsp;Based&nbsp;on&nbsp;the&nbsp;above&nbsp;contents,&nbsp;if&nbsp;the&nbsp;RR&nbsp;did&nbsp;not&nbsp;attach&nbsp;the&nbsp;extended&nbsp;community,&nbsp;the&nbsp;ASBR&nbsp;will&nbsp;attach&nbsp;it.

Thanks&nbsp;for&nbsp;pointing&nbsp;out&nbsp;that&nbsp;section.

For&nbsp;this&nbsp;ORF&nbsp;feature,&nbsp;a&nbsp;BGP&nbsp;speaker&nbsp;receiving&nbsp;an&nbsp;VPN&nbsp;ORF&nbsp;with&nbsp;the&nbsp;Source&nbsp;PE&nbsp;TLV,&nbsp;it&nbsp;is&nbsp;necessary&nbsp;for&nbsp;that&nbsp;router&nbsp;to&nbsp;have&nbsp;the&nbsp;impacted&nbsp;routes&nbsp;in&nbsp;its&nbsp;RIB-OUT&nbsp;toward&nbsp;the&nbsp;originator&nbsp;of&nbsp;the&nbsp;ORF.

If&nbsp;the&nbsp;Source&nbsp;PE&nbsp;community&nbsp;was&nbsp;not&nbsp;already&nbsp;attached&nbsp;to&nbsp;the&nbsp;routes,&nbsp;this&nbsp;is&nbsp;also&nbsp;the&nbsp;device&nbsp;that&nbsp;SHOULD&nbsp;attach&nbsp;them.&nbsp;&nbsp;Documenting&nbsp;this&nbsp;process&nbsp;as&nbsp;part&nbsp;of&nbsp;the&nbsp;route&nbsp;receive&nbsp;process&nbsp;when&nbsp;the&nbsp;device&nbsp;supports&nbsp;this&nbsp;ORF&nbsp;may&nbsp;be&nbsp;the&nbsp;best&nbsp;way&nbsp;to&nbsp;document&nbsp;this&nbsp;procedure.
[WW]: If the SPE EC is not attached to the BGP Update message of the VPN prefixes, the receiver should use NEXT_HOP or ORIGINATOR_ID as the originator of VPN Prefix to match against the VPN Prefix ORF entry. This information is claimed in the section 7 of -v14 as follows:“If the SPE EC is not attached to the BGP Update message of the VPN prefixes, the receiver should use NEXT_HOP or ORIGINATOR_ID as the originator of VPN Prefix to match against the VPN Prefix ORF entry.”

&gt;&nbsp;I&nbsp;suspect&nbsp;the&nbsp;intent&nbsp;here&nbsp;is&nbsp;that&nbsp;it's&nbsp;also&nbsp;an&nbsp;order&nbsp;in&nbsp;which&nbsp;this&nbsp;ORF&nbsp;type&nbsp;is&nbsp;evaluated.&nbsp;&nbsp;Is&nbsp;that&nbsp;the&nbsp;case?&nbsp;&nbsp;If&nbsp;so,&nbsp;text&nbsp;needs&nbsp;to&nbsp;be&nbsp;added&nbsp;covering&nbsp;that&nbsp;detail.
&gt;&nbsp;[WW]:&nbsp;We&nbsp;added&nbsp;the&nbsp;following&nbsp;sentence&nbsp;to&nbsp;the&nbsp;description&nbsp;of&nbsp;Sequence&nbsp;in&nbsp;Section&nbsp;6:
&gt;&nbsp;“Sequence:&nbsp;identifying&nbsp;the&nbsp;order&nbsp;in&nbsp;which&nbsp;VPN&nbsp;Prefix&nbsp;ORF&nbsp;is&nbsp;generated.&nbsp;&nbsp;It&nbsp;can&nbsp;uniquely&nbsp;identify&nbsp;a&nbsp;VPN&nbsp;Prefix&nbsp;ORF&nbsp;entry&nbsp;together&nbsp;with&nbsp;AFI/SAFI,&nbsp;ORF-Type,&nbsp;and&nbsp;Route&nbsp;Distinguisher.”

This&nbsp;text&nbsp;still&nbsp;does&nbsp;not&nbsp;address&nbsp;evaluation&nbsp;issues.&nbsp;&nbsp;It&nbsp;does&nbsp;discuss&nbsp;how&nbsp;the&nbsp;ORF&nbsp;entry&nbsp;is&nbsp;"keyed"&nbsp;for&nbsp;purposes&nbsp;of&nbsp;add/delete.

To&nbsp;give&nbsp;an&nbsp;example,&nbsp;consider&nbsp;this&nbsp;order&nbsp;of&nbsp;events.


I&nbsp;understand&nbsp;this&nbsp;example&nbsp;does&nbsp;not&nbsp;have&nbsp;the&nbsp;sequence&nbsp;numbers&nbsp;monotonically&nbsp;increasing&nbsp;as&nbsp;the&nbsp;"order&nbsp;it&nbsp;is&nbsp;generated".&nbsp;&nbsp;So,&nbsp;this&nbsp;could&nbsp;be&nbsp;a&nbsp;bug&nbsp;for&nbsp;the&nbsp;ORF&nbsp;sender&nbsp;to&nbsp;do&nbsp;this,&nbsp;but&nbsp;the&nbsp;receiver&nbsp;will&nbsp;still&nbsp;need&nbsp;to&nbsp;deal&nbsp;with&nbsp;it.&nbsp;&nbsp;Further,&nbsp;the&nbsp;above&nbsp;example&nbsp;explains&nbsp;the&nbsp;motivation&nbsp;for&nbsp;my&nbsp;questions:

If&nbsp;the&nbsp;ORFs&nbsp;are&nbsp;processed&nbsp;in&nbsp;the&nbsp;received&nbsp;order&nbsp;(perhaps&nbsp;the&nbsp;sequence&nbsp;numbers&nbsp;are&nbsp;in&nbsp;correct&nbsp;order&nbsp;as&nbsp;well),&nbsp;then&nbsp;routes&nbsp;containing&nbsp;both&nbsp;RT&nbsp;Y&nbsp;and&nbsp;PE&nbsp;a.b.c.d&nbsp;will&nbsp;be&nbsp;permitted&nbsp;because&nbsp;it&nbsp;matches&nbsp;first.

If&nbsp;the&nbsp;ORFs&nbsp;are&nbsp;processed&nbsp;in&nbsp;the&nbsp;sequential&nbsp;order,&nbsp;routes&nbsp;containing&nbsp;both&nbsp;RT&nbsp;Y&nbsp;and&nbsp;PE&nbsp;a.b.c.d&nbsp;will&nbsp;be&nbsp;denied.

This&nbsp;shows&nbsp;the&nbsp;consequence&nbsp;of&nbsp;ordering.

Now,&nbsp;consider&nbsp;that&nbsp;an&nbsp;implementation&nbsp;always&nbsp;generated&nbsp;monotonically&nbsp;increasing&nbsp;sequence&nbsp;numbers:

Add&nbsp;seq=1,&nbsp;RD1,&nbsp;RT=Y&nbsp;permit
Add&nbsp;seq=2,&nbsp;RD1,&nbsp;RT=Y,&nbsp;Source&nbsp;PE=a.b.c.d&nbsp;deny

In&nbsp;this&nbsp;circumstance,&nbsp;the&nbsp;intent&nbsp;to&nbsp;match&nbsp;both&nbsp;RT&nbsp;Y&nbsp;and&nbsp;Source&nbsp;PE=a.b.c.d&nbsp;cannot&nbsp;be&nbsp;hit&nbsp;because&nbsp;the&nbsp;first&nbsp;rule&nbsp;takes&nbsp;effect.

Further,&nbsp;the&nbsp;only&nbsp;way&nbsp;to&nbsp;get&nbsp;the&nbsp;second&nbsp;rule&nbsp;to&nbsp;take&nbsp;effect&nbsp;would&nbsp;be&nbsp;to&nbsp;delete&nbsp;the&nbsp;rules&nbsp;and&nbsp;resend&nbsp;with&nbsp;next&nbsp;sequence&nbsp;numbers&nbsp;like:
Delete&nbsp;seq=1,&nbsp;RD1,&nbsp;RT=Y&nbsp;permit
Delete&nbsp;seq=2,&nbsp;RD1,&nbsp;RT=Y,&nbsp;Source&nbsp;PE=a.b.c.d&nbsp;deny

Add&nbsp;seq=N,&nbsp;RD1,&nbsp;RT=Y,&nbsp;Source&nbsp;PE=a.b.c.d&nbsp;deny
Add&nbsp;seq=N+1,&nbsp;RD1,&nbsp;RT=Y&nbsp;permit

But&nbsp;this&nbsp;would&nbsp;also&nbsp;require&nbsp;that&nbsp;the&nbsp;prior&nbsp;rules&nbsp;<&nbsp;N&nbsp;did&nbsp;not&nbsp;interfere&nbsp;with&nbsp;this&nbsp;intent.
[WW]: As our reply for the last comment, the permit action only used by the last entry to allow other allowed VPN prefixes pass the filter. So the situation in the examples will not occur.

The&nbsp;issue&nbsp;above&nbsp;is&nbsp;common&nbsp;with&nbsp;firewall&nbsp;configurations.&nbsp;&nbsp;When&nbsp;firewalls&nbsp;use&nbsp;sequence&nbsp;numbers&nbsp;for&nbsp;such&nbsp;programming,&nbsp;it's&nbsp;common&nbsp;practice&nbsp;to&nbsp;leave&nbsp;gaps&nbsp;in&nbsp;the&nbsp;numbering&nbsp;to&nbsp;permit&nbsp;reordering.&nbsp;&nbsp;Alternatively,&nbsp;management&nbsp;mechanisms&nbsp;that&nbsp;allow&nbsp;for&nbsp;insert&nbsp;operations&nbsp;are&nbsp;used.&nbsp;&nbsp;However,&nbsp;this&nbsp;is&nbsp;signaled&nbsp;in&nbsp;BGP&nbsp;and&nbsp;the&nbsp;only&nbsp;way&nbsp;to&nbsp;manage&nbsp;such&nbsp;ordering&nbsp;is&nbsp;to&nbsp;be&nbsp;explicit&nbsp;about&nbsp;it&nbsp;in&nbsp;the&nbsp;protocol.
[WW]: Thank you for your comments. The sequence numbers can be discontinuous to facilitate the insertion of new rules at a later stage. We also added these contents to the Section 6.

---

One&nbsp;final&nbsp;point,&nbsp;ORFs&nbsp;are&nbsp;expected&nbsp;to&nbsp;allow&nbsp;or&nbsp;deny&nbsp;all&nbsp;routes&nbsp;that&nbsp;pass&nbsp;through&nbsp;them.&nbsp;&nbsp;How&nbsp;is&nbsp;the&nbsp;default&nbsp;"allow"&nbsp;for&nbsp;routes&nbsp;not&nbsp;covered&nbsp;by&nbsp;the&nbsp;ORF&nbsp;encoded?&nbsp;&nbsp;Or,&nbsp;was&nbsp;the&nbsp;intent&nbsp;for&nbsp;it&nbsp;to&nbsp;be&nbsp;a&nbsp;default&nbsp;part&nbsp;of&nbsp;the&nbsp;procedure?
[WW]: The purpose of VPN Prefix ORF is to block unwanted VPN prefixes, then the "action" of one valid entry should be set to "DENY". In order to allow other allowed VPN prefixes pass the filter, one default, last resort entry should be installed in advance in the VPN Prefixes ORF table, with the RD is set to 0 and the corresponding Sequence are set to 0xFFFFFFFF. We also give some clarifications in Section 6.

--&nbsp;Jeff