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

From: "Susan Hares" <[email-masked]>
Date: Tue, 1 Mar 2022 07:59:05 -0500

Thank you to all who have contributed to this discussion. 

I will be sending out notes on this discussion later today. 

This message closes the WG adoption call. 

Sue 

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)

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 2 Mar 2022 11:37:23 -0500

Authors and WG:  

The adoption call on draft-wang-idr-vpn-prefix-orf-00.txt is closed.

There is no consensus to adoption this draft. 

Thank you for engaging in the 3 week discussion on the VPN ORF limits
(2/4/22 to 2/25/2022).   

I appreciate the active participation by Network operators, developers, and
BGP experts.  

 Since this discussion shared a great deal of BGP wisdom, my comments below
summarize: 

a) Is there a problem or problems?  

b) Is there a possible solution space? 

c) Does this draft describe a clear problem the solution addresses? 

d) Does this draft clearly describe the solution? 

e) Does it need implementations before adoption? 

Sue 

Shepherd for adoption 

RFC1925 ask these same questions a different format (it's a fun read). 

Summary of Adoption call for draft-wang-idr-vpn-prefix-00.txt 

=========================

a) Is there a problem or problems? 

Grow has talked about needing more prefix limits 

.         Recommending hard prefix limits for inbound routes and outbound
routes, 

.         Recommending soft-limits before the hard limits

These box limits are to protect any type of IP boxes. Grow did not further
specify how VPNs interact with these hard or soft limits.  Grow indicates
(just as many IDR folks did) these limits are for the failure case. 

Grow and IDR people recommend prefix limits in addition to strong filters on
inbound and outbound.  

Gyan Mishra noted China's networks (China Telcom, China Mobile) had early
SRv6 and EVPN deployments, and that the EVPN intra and inter-AS were one
concern.  

https://mailarchive.ietf.org/arch/msg/idr/4SCbqhuhLpoDazxcjLSW8CD9wZk/

https://mailarchive.ietf.org/arch/msg/idr/jR7DNFym2J_YK9RY24ggvdge0Mk/

Jim Uttaro indicated that his network limited clients to 50 MAC per customer
for RT-2 EVPNs. 

Historically hub-spoke IP-VPNS and EVPN used ORF filters (RFC7543, aka
CP-ORF). 

[VPN-RT, Import-RT, Route-type, Host (prefix)] 

Two new definitions:  Weak-PE and Rogue-PE

https://mailarchive.ietf.org/arch/msg/idr/QgtIssT7zSxGIDgw8129WxdeK9c/

https://mailarchive.ietf.org/arch/msg/idr/6gp7i-9dCxU_vXlAcmVGGqq8FIA/

Recommendations:  

1) Query Grow for details on prefix limits for VPNs 

2) Query Bess for expected limits on RT-2 and RT-5 EVPNS

3) Treat prefix limits as occurring after good edge filtering

=======

b) Possible solutions mentioned: 

a) ORF using Address filtering (RD-prefix = NLRI) 

b) better filtering before you get to IBGP  

c) Flow specification v2 based solution 

d) VPN ORF Prefix (RD, RT, source-Prefix]

Surprisingly:  Augmenting CP-ORF (7543) was not mentioned.  

=========

c) Does this draft describe the problem clearly?  No. 

Three Types of threads are useful for the authors to consider: 

1) Operator discussion redefining the needs 

Jim Uttaro, Zhenqiang Li, Wei Wang, Gyan Mishra, Aijun Wang, and others 

2) Jeff Haas's query to Wei Wang on exact desires 

https://mailarchive.ietf.org/arch/msg/idr/1wCVv36KNdb6DJIt_80aWwpf4U0/

3) Robert Raszuk's 10 questions to Aijun Wang 

https://mailarchive.ietf.org/arch/msg/idr/1Iv5EiA1_PM_kaH0Oc5vtp-Mn3k/

======

d) Does this draft describe the solution clearly.  No. 

Sections 2 needs corrections and sections 4-7 need more detail.  As your
draft's shepherd during the adoption process, I suggest reviewing other ORF
drafts (RFC7543, RFC5292) for how much description is needed for sections
4-7.   

====

e) Does this draft need implementations before adoption? Yes. 

RFC7543 required implementations to work the bugs.  Aijun asked for
"self-healing" networks - which involves automatic feedback network. RFC7543
provide some automatic feedback via ORF to the BGP cloud, but the wisdom to
create that feedback came through trial and error in the lab.  The lab also
showed the benefit of management tools.  The rumor also is that some of the
"trial and error" for RFC7543 also came in deployments of the technology. 

Recommendations to Authors: 

1) Revise draft after looking at CP-ORF 

2) Query chairs + Wg for feedback 

3) Implement draft.  For testing ORF types can use FCFS (64-127) or use
vendor specific.  

4) Ask for adoption after you have implemented the draft. 

Author's Alternatives to IDR WG:  Other alternatives for publication of
draft are:

1)  the Independent stream editor (ISE) as Experimental draft, or 

2)  AD-sponsored as "Experimental" draft.   

PS - I have sent the authors more details on items c and d.  If the
wonderful discussion on the list is insufficient for your reading pleasure,
please send me a request for more information. 

Thank you, Susan Hares