Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

From: "Wei Wang" <[email-masked]>
Date: Wed, 23 Feb 2022 20:41:31 +0800

Hi Nick,
&nbsp; &nbsp;&nbsp;
&nbsp; &nbsp; The trigger of VPN Prefix ORF and how sender determins which prefix should be put into ORF list is described in:&nbsp;https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01#section-4.1.1

&nbsp; &nbsp; In brief, each VRF has a set threshold,&nbsp;when the number of VPN routes exceeds the threshold but has not reached the prefix limit, the device will monitoring the RD carried by the received VPN routing entries. Once the number of VPN routes exceeds prefix limit, the device will calculate the RD, RT and its source PE received the most times during this period. If there is no other VRFs import the VPN routes with RT that it has calculated, the device will put the RD, RT and source PE into ORF list.
&nbsp; &nbsp; This mechanism has been fully discussed, if you are interested in, follow &amp; review the discussion on mail list may be an efficient way. :)

Best Regards,
Wei
------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Nick Hilliard"                                                                                    <[email-masked]&gt;;
Date:&nbsp;Wed, Feb 23, 2022 05:25 PM
To:&nbsp;"Aijun Wang"<[email-masked]&gt;;
Cc:&nbsp;"idr"<[email-masked]&gt;;
Subject:&nbsp;Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

 
 can you describe how devices on the network select which prefixes go  into the ORF list?
 
 Nick
 
 Aijun Wang wrote on 23/02/2022 01:11:
             
Hi,  Nick:

This  draft described the behavior of the PE and RR, have you reviewed the  draft in detail?

The  ORF filter is applied independently to each PE that originated such  message. &nbsp;It does not prevent other PEs in the same VPN acts also in  same manner.

Would  you like to give the example that you worried about “result in unexpected blackholing of traffic due to breakage  in forward or return paths.” ?

&nbsp;

And  one thing you should know that if we don’t have such mechanism, what we  can do is to drop the excessive routes locally.

The  VPN Prefix ORF mechanism just optimize such actions.

&nbsp;

&nbsp;

Best  Regards

&nbsp;

Aijun  Wang

China  Telecom

&nbsp;

From: Nick Hilliard <[email-masked]&gt; 
Sent:  Wednesday, February 23, 2022 8:21 AM
To: Aijun Wang  <[email-masked]&gt;
Cc: [email-masked]
Subject:  Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022  to 2/18/2022)

&nbsp;

The outcome of this draft will result in non-deterministic  sets of prefixes ending up on PEs, e.g.

&nbsp;&nbsp; PEs and RR should have some mechanisms to identify and control the&nbsp;&nbsp; advertisement of excessive VPN routes.

&nbsp;&nbsp; The operation of VPN Prefix ORF mechanism on each device is&nbsp;&nbsp; independent, each of them makes a local judgement to determine&nbsp;&nbsp; whether it needs to send VPN Prefix ORF to its peers.

It seems likely that there are scenarios where this  would result in unexpected blackholing of traffic due to breakage in  forward or return paths.&nbsp; This is not desirable from an operational  point of view.&nbsp; It would be unwise for the WG to adopt this draft  without clarifying how this policy is created and can be applied  consistently across all devices in a vpn domain.

Nick

Aijun  Wang wrote on 21/02/2022 23:01:

Hi,Jeffrey: 

All your concerns are the detail implementation  considerations, I don’t think the protocols standards should focus  mainly how to implement.

And, can you give some examples that there is no cost or  influences to the devices but beneficial to the devices at the same  times within BGP protocol?

According to the rules of IDR WG, there should be two  independent implementations to forward the draft after its adoption. I  think your concerns will be addressed during the implementation process  and we can give you the final answer to your questions.

If you obstacles or raise the bar for the adoption call of  this draft in such way, I think every document in IDR WG should also  answer such kind questions and take the same procedures.

If you can’t give the example that there is such example  to free to answer your questions, I object your proposal/bar to this  document.

Aijun Wang

China Telecom

在 2022年2月21日，23:53，Jeffrey Haas <[email-masked]&gt; 写道：

[Speaking as an individual contributor.]

&nbsp;

Sue,

&nbsp;

I do not support adoption of this draft.

&nbsp;

After various discussions about the scope of the feature  the authors seem to intend that:

- It address exhaustion by a Provider Edge device of RIB  (and subsequently FIB) resources.

- Part of the concern is BGP messaging load on the  receiving PE.

- This can be mitigated by causing remote drop of some  portion of impactful routes.

&nbsp;

The proposal has the issues that it:

- Will require additional per-route per-VRF counter state  (potentially useful, somewhat expensive to implement)

- Does not provide an algorithm to determine drop, meaning  no consistent local implementation of the feature.

- Does not address edge conditions wherein multiple classes  of routes may be eligible for drop

- Will impose additional load on upstream BGP devices such  as route reflectors to implement the filters

- Cannot guarantee prompt mitigation of the issues of  concern. &nbsp;Local filtering will be required as a mitigation during ORF  installation at the upstream device.

- Installation of the ORF will generate additional  messages for the withdraw messaging.

&nbsp;

Much of the conversation about local PE behaviors amounts  to, "I'll know it when I see it". &nbsp;Implementation choice may be  reasonable, but is too vague for the local end of a standard.

&nbsp;

Discussion of this feature has resulted in the  specification improving its clarity, but I don't foresee the above  points converging across the disagreeing parties.

&nbsp;

My recommendation is that if the authors wish to progress  this proposal that they make it Experimental, request a First Come,  First Served ORF code point from IANA, and take the draft to the  Independent Submissions Editor track.

&nbsp;

-- Jeff

&nbsp;

On Feb 4, 2022, at 7:39 AM, Susan Hares <[email-masked]&gt;  wrote:

&nbsp;

Resending the adoption call – with the appropriate header&nbsp;

&nbsp;

From:&nbsp;Idr [mailto:[email-masked]]&nbsp;On Behalf Of&nbsp;Susan Hares
Sent:&nbsp;Friday, February 4, 2022 7:33 AM
To:&nbsp;[email-masked]
Subject:&nbsp;[Idr]  draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 2/18/2022)

&nbsp;

This begins a 2 week WG adoption call &nbsp;for&nbsp;

draft-wang-idr-vpn-prefix-orf-00.txt&nbsp;

https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf.&nbsp;

&nbsp;

In your discussion on adoption, please consider the  following questions:&nbsp;

&nbsp;

1) Does this draft describe problems existing in networks  today?&nbsp;

&nbsp;

2) Does the solution describe address these problems?&nbsp;

The solution has both a general solution and BGP encodings.&nbsp;

&nbsp;

3) Would the solution be useful in networks today?&nbsp;

&nbsp;

Thank you, Susan Hares&nbsp;

<Untitled attachment 00214.txt&gt;_______________________________________________
Idr  mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

&nbsp;

_______________________________________________
Idr  mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________Idr mailing [email-masked]://www.ietf.org/mailman/listinfo/idr
&nbsp;

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 23 Feb 2022 14:44:15 +0100

Wei,

This is IDR WG.

Can you imagine what would happen to Internet if ISPs start putting crappy
routers in their data path and randomly dropping routes as it seems fit (or
rather no fit) ?

And VPNs are supposed to be a premium service right ?

When you drop as described irrespective if you drop on local PE or on RR
per RD you do not even know which routes you dropped.

If yr NOC gets call from affected customer you have no way to tell him the
real cause of the issue.

This draft is bad ... really bad.

Thx
R.

On Wed, Feb 23, 2022, 13:41 Wei Wang <[email-masked]> wrote:

> Hi Nick,
>
>     The trigger of VPN Prefix ORF and how sender determins which prefix
> should be put into ORF list is described in:
> https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01#section-4.1.1
>
>     In brief, each VRF has a set threshold, when the number of VPN routes
> exceeds the threshold but has not reached the prefix limit, the device will
> monitoring the RD carried by the received VPN routing entries. Once the
> number of VPN routes exceeds prefix limit, the device will calculate the
> RD, RT and its source PE received the most times during this period. If
> there is no other VRFs import the VPN routes with RT that it has
> calculated, the device will put the RD, RT and source PE into ORF list.
>     This mechanism has been fully discussed, if you are interested in,
> follow & review the discussion on mail list may be an efficient way. :)
>
> Best Regards,
> Wei
> ------------------ Original ------------------
> *From:* "Nick Hilliard" <[email-masked]>;
> *Date:* Wed, Feb 23, 2022 05:25 PM
> *To:* "Aijun Wang"<[email-masked]>;
> *Cc:* "idr"<[email-masked]>;
> *Subject:* Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call
> (2/4/2022 to 2/18/2022)
>
> Aijun,
>
> The ORF filter is applied independently to each PE that originated such
> message.  It does not prevent other PEs in the same VPN acts also in same
> manner.
>
> Would you like to give the example that you worried about “result in
> unexpected blackholing of traffic due to breakage in forward or return
> paths.” ?
>
>
>
> And one thing you should know that if we don’t have such mechanism, what
> we can do is to drop the excessive routes locally.
>
> *From:* Nick Hilliard <[email-masked]> <[email-masked]>
> *Sent:* Wednesday, February 23, 2022 8:21 AM
> *To:* Aijun Wang <[email-masked]> <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call
> (2/4/2022 to 2/18/2022)
>
>
>
>    PEs and RR should have some mechanisms to identify and control the
>
>    advertisement of excessive VPN routes.
>
>
>
>    The operation of VPN Prefix ORF mechanism on each device is
>
>    independent, each of them makes a local judgement to determine
>
>    whether it needs to send VPN Prefix ORF to its peers.
>
>
> It seems likely that there are scenarios where this would result in
> unexpected blackholing of traffic due to breakage in forward or return
> paths.  This is not desirable from an operational point of view.  It would
> be unwise for the WG to adopt this draft without clarifying how this policy
> is created and can be applied consistently across all devices in a vpn
> domain.
>
> Nick
>
> All your concerns are the detail implementation considerations, I don’t
> think the protocols standards should focus mainly how to implement.
>
> And, can you give some examples that there is no cost or influences to the
> devices but beneficial to the devices at the same times within BGP protocol?
>
> According to the rules of IDR WG, there should be two independent
> implementations to forward the draft after its adoption. I think your
> concerns will be addressed during the implementation process and we can
> give you the final answer to your questions.
>
> If you obstacles or raise the bar for the adoption call of this draft in
> such way, I think every document in IDR WG should also answer such kind
> questions and take the same procedures.
>
> If you can’t give the example that there is such example to free to answer
> your questions, I object your proposal/bar to this document.
>
> Aijun Wang
>
> China Telecom
>
>
>
> 在 2022年2月21日，23:53，Jeffrey Haas <[email-masked]> <[email-masked]> 写道：
>
> - Cannot guarantee prompt mitigation of the issues of concern.  Local
> filtering will be required as a mitigation during ORF installation at the
> upstream device.
>
> Much of the conversation about local PE behaviors amounts to, "I'll know
> it when I see it".  Implementation choice may be reasonable, but is too
> vague for the local end of a standard.
>
>
>
> Discussion of this feature has resulted in the specification improving its
> clarity, but I don't foresee the above points converging across the
> disagreeing parties.
>
>
>
> My recommendation is that if the authors wish to progress this proposal
> that they make it Experimental, request a First Come, First Served ORF code
> point from IANA, and take the draft to the Independent Submissions Editor
> track.
>
>
>
> -- Jeff
>
>
>
>
>
> On Feb 4, 2022, at 7:39 AM, Susan Hares <[email-masked]> wrote:
>
>
>
> Resending the adoption call – with the appropriate header
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Susan Hares
> *Sent:* Friday, February 4, 2022 7:33 AM
> *To:* [email-masked]
> *Subject:* [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to
> 2/18/2022)
>
>
>
> This begins a 2 week WG adoption call  for
>
> draft-wang-idr-vpn-prefix-orf-00.txt
>
> https://datatracker.ietf.org/doc/draft-wang-idr-vpn-prefix-orf.
>
>
>
> In your discussion on adoption, please consider the following questions:
>
>
>
> 1) Does this draft describe problems existing in networks today?
>
>
>
> 2) Does the solution describe address these problems?
>
> The solution has both a general solution and BGP encodings.
>
>
>
> 3) Would the solution be useful in networks today?
>
>
>
> Thank you, Susan Hares
>
> <Untitled attachment 00214.txt>

---

From: Aijun Wang <[email-masked]>
Date: Wed, 23 Feb 2022 22:09:02 +0800

Hi, Robert:
I found you are not hearing what other persons have said. The questions you raised are answered several times, but you raised it again.
Let’s stop loop it again. OK?

Aijun Wang
China Telecom

> 在 2022年2月23日，21:44，Robert Raszuk <[email-masked]> 写道：
> 
> 
> Wei,
> 
> This is IDR WG.
> 
> Can you imagine what would happen to Internet if ISPs start putting crappy routers in their data path and randomly dropping routes as it seems fit (or rather no fit) ?
> 
> When you drop as described irrespective if you drop on local PE or on RR per RD you do not even know which routes you dropped.
> 
> If yr NOC gets call from affected customer you have no way to tell him the real cause of the issue.
> 
>>     The trigger of VPN Prefix ORF and how sender determins which prefix should be put into ORF list is described in: https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01#section-4.1.1
>> 
>>     In brief, each VRF has a set threshold, when the number of VPN routes exceeds the threshold but has not reached the prefix limit, the device will monitoring the RD carried by the received VPN routing entries. Once the number of VPN routes exceeds prefix limit, the device will calculate the RD, RT and its source PE received the most times during this period. If there is no other VRFs import the VPN routes with RT that it has calculated, the device will put the RD, RT and source PE into ORF list.
>>     This mechanism has been fully discussed, if you are interested in, follow & review the discussion on mail list may be an efficient way. :)
>> 
>> Best Regards,
>> Wei
>> From: "Nick Hilliard" <[email-masked]>;
>> Date: Wed, Feb 23, 2022 05:25 PM
>> To: "Aijun Wang"<[email-masked]>;
>> Cc: "idr"<[email-masked]>;
>>> The ORF filter is applied independently to each PE that originated such message.  It does not prevent other PEs in the same VPN acts also in same manner.
>>> 
>>> From: Nick Hilliard <[email-masked]> 
>>> To: Aijun Wang <[email-masked]>
>>> Cc: [email-masked]
>>> It seems likely that there are scenarios where this would result in unexpected blackholing of traffic due to breakage in forward or return paths.  This is not desirable from an operational point of view.  It would be unwise for the WG to adopt this draft without clarifying how this policy is created and can be applied consistently across all devices in a vpn domain.
>>> 
>>> Nick
>>> 
>>> 在 2022年2月21日，23:53，Jeffrey Haas <[email-masked]> 写道：
>>> 
>>> - Cannot guarantee prompt mitigation of the issues of concern.  Local filtering will be required as a mitigation during ORF installation at the upstream device.
>>> 
>>> Much of the conversation about local PE behaviors amounts to, "I'll know it when I see it".  Implementation choice may be reasonable, but is too vague for the local end of a standard.
>>> 
>>>  
>>> 
>>> From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
>>> Sent: Friday, February 4, 2022 7:33 AM
>>> To: [email-masked]
>>> Subject: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt : (2/4/2022 to 2/18/2022)
>>> 
>>>  
>>> 
>>> <Untitled attachment 00214.txt>_______________________________________________
>>> Idr mailing list
>>> [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 23 Feb 2022 18:27:49 +0000

> https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01#section-4.1.1

the suggestions made in sections 4.1.1 to 4.1.3 are imprecisely 
specified and non-deterministic.  This is inappropriate for a standards 
track document.  This should be addressed before the draft is adopted as 
a working group item.

 From an operational point of view, a non-deterministic protocol 
specification is usually worse than a protocol which fully stops working 
in a specific set of circumstances (e.g. injecting too many prefixes).

Nick

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 Feb 2022 19:43:04 +0100

Hi,

On Wed, Feb 23, 2022 at 10:09:02PM +0800, Aijun Wang wrote:
> Let???s stop loop it again. OK?

Seems you are not listening to what multiple persons here that have
done BGP implementations and run networks are telling you.

Instead, this is going in circles again.

I do oppose WG adoption, if only for "no, we can't take a draft because 
the authors send so many mails that everybody unsubscribes from idr" 
reasons.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 24 Feb 2022 09:54:30 -0500

Working Group,

This discussion thread has become a little heated.  While the Chairs are pleased to see additional participation in the thread, we'd like to remind all participants that civility is important to advance discussion in a beneficial manner.

It is okay if you do not like how something works.

You are encouraged to raise technical objections or request better clarity on functional behaviors. Good examples of such clarification are the mail from Wei Wang.  We are writing protocol documents, and protocol must be clear enough that independent implementations could write interoperable code.  If you can't write code from the document, the document isn't done.

Thanks.

-- Jeff

---

From: "Vladimir B." <[email-masked]>
Date: Thu, 24 Feb 2022 18:11:14 +0300

Golden words, Jeff ;)

With best regards,
Vladimir Blazhkun.

On Thu, Feb 24, 2022 at 5:55 PM Jeffrey Haas <[email-masked]> wrote:

> Working Group,
>
> This discussion thread has become a little heated.  While the Chairs are
> pleased to see additional participation in the thread, we'd like to remind
> all participants that civility is important to advance discussion in a
> beneficial manner.
>
> You are encouraged to raise technical objections or request better clarity
> on functional behaviors. Good examples of such clarification are the mail
> from Wei Wang.  We are writing protocol documents, and protocol must be
> clear enough that independent implementations could write interoperable
> code.  If you can't write code from the document, the document isn't done.
>
> Thanks.
>
> -- Jeff
>