Subject: Re: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor Implementations (12/12/21 to 12/20/21) - Summary of call (1/7/2021)

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 14:19:50 -0500

Happy New Year 2022!

The implementers have indicated that the two implementations within Huawei have been written by two independent teams for 2 independent platforms. 

Response from Implementers (Haibo Wang) 

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

updated implementation report: 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20implementations

Based on the details from the developers, it seems to fulfill the intent of the 2 implementations.   I have encouraged the authors reporting on the implementations to provide additional details for the WG. 

The implementation report for draft-ietf-idr-rpd-14.txt indicates that we have the same two 2 implementations for BGP Wide communities. 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-wide-bgp-communities

As shepherd for the wide community draft, the wide community draft needs to be refreshed and updated.   I will be working with the implementers to provide additional detail on the text.   Does anyone else have a wide communities implementation?   

I will send a note to idr when additional details are posted to the IDR Wiki on the implementation reports.  

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, December 18, 2021 10:08 AM
To: 'Robert Raszuk'; 'Jeffrey Haas'
Cc: 'Keyur Patel'; 'idr@ietf. org'
Subject: Re: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor Implementations (12/12/21 to 12/20/21)

Robert: 

I agree that that there are different levels of implementations.   As a chair, I have asked authors to increase the detail on their implementation report to report the exact scope of the implementations and the interoperability tests.   

Controllers are part of the new family of network devices. Detailed descriptions in the implementation reports will help the WG. 

Cheers, Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, December 17, 2021 4:25 PM
To: Jeffrey Haas
Cc: Keyur Patel; Sue Hares; idr@ietf. org
Subject: Re: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor Implementations (12/12/21 to 12/20/21)

Hi Jeff, 

There also a bit different spin to this discussion which may or may not be easy to capture/enforce. 

This is about scope of implementation. 

See as example if we have any proposal which relies on controller to inject BGP UPDATES to the network the amount of BGP in such case is trivial and bare minimum (to establish a TCP session and build a valid UPDATE message). Such "implementation" may not even support all BGP message types - yes seen one of those in the past with the bold claim we support BGP :)

On the other hand receiver has a much harder job as it rather needs to process the message, check correctness, run best path, store, etc .... 

So the question is if in such a case can we call a controller (even if done with completely separate code base or even scripting language) as a separate implementation or not. 

To me the answer is clear but I am just raising the point. And I think we will see more and more cases like this really soon. 

Best,
Robert

On Fri, Dec 17, 2021 at 9:53 PM Jeffrey Haas <[email-masked]> wrote:

Adding to Sue's thinking, part of our meta desire for two interoperable implementations is that they're done by different enough brains along with potentially on different code bases.  However, that's not what we've traditionally had to say.

Can two individuals, working from the same specification _independently_, produce an implementation that interoperates with the other?  

We know that that independent step often doesn't quite happen in the industry.  You have customers to satisfy, so discussion often happens.  But if that discussion results in feedback to the specification about points of clarity, we still win.

So, even for a single vendor part of the real question goes toward the above: Is it the same code with different branches and thus really the same implementation?  Is it more than one individual working on stuff independently?  Did they notice issues of clarity that gave them pause when they were doing the work?

As you say, Robert, if someone can put together an open source implementation of the feature in a weekend... then it means we probably have successful RFC text.  Getting them to do it is the necessary thing outside of the thought exercise.

-- Jeff

On Dec 17, 2021, at 3:46 PM, Susan Hares <[email-masked]> wrote:

Robert: 

Oops – You are right.  Open source implementation is important and what we are looking at is 2 interoperable implementations.  Let me reframe the query in a better way.   

I’m in the midst of a meeting.  I will send a new query. 

Thank you for catching this! 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, December 17, 2021 3:14 PM
To: Susan Hares
Cc: Keyur Patel; idr@ietf. org
Subject: Re: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor Implementations (12/12/21 to 12/20/21)

Hi Sue,

What is your definition of "a vendor" ? Legal entity building commercial products ? If so then the next step IDR will need to define is an approved list of vendors :) 

Is any open source BGP code an orphan ? 

IMO we should care less about vendors here - what really matters is to have implementation done with at least two independent BGP code bases irrespective if it comes from the same company or that there is one commercial implementation and one open source. 

For this specific draft I am not sure if NE40E-M2K V800R011C00 shares the same BGP code as iMaster NCE IP V100R018C00 so hard to tell. But smart developer can over weekend add this to FRR, BIRD, exaBGP or goBGP and submit it for review. And if that happens this thread would not be needed. 

Cheers,

R.

On Fri, Dec 17, 2021 at 8:56 PM Susan Hares < <mailto:[email-masked]> [email-masked]> wrote:

Gert: 

I'm guiding this WG LC during the time Keyur is on vacation (12/12/21 to
1/4/22).   We will not re-open the WG LC.    

This WG LC does address two implementations from the same vendor.  Thank you
for letting me know you wish 2 implementations from 2 separate vendors
before submission of this document to the IESG for publication. 

If I may ask another question that will guide the IETF chairs.  In your
opinion, should the IDR chairs 
[a] restrict publication of IDR drafts to 2 implementations from 2 separate
vendors
[b] query regarding drafts with two separate implementations from the same
vendor. 

Thank you,  Sue 

-----Original Message-----
From: Idr [mailto: <mailto:[email-masked]> [email-masked]] On Behalf Of Gert Doering
Sent: Friday, December 17, 2021 12:10 PM
To: Keyur Patel
Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor
Implementations (12/12/21 to 12/20/21)

Hi,

On Sun, Dec 12, 2021 at 01:21:49AM +0000, Keyur Patel wrote:
> The draft  <https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd> https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd  has
cited multiple implementations from a single vendor. You can see the
implementation report at
 <https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20implementations> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20implementations.
> 
> Please let us know if the working group has any objection in proceeding
forward with a single vendor implementations.  This call will end on
December 20th 2021.

Going back to the archives, I do not see much traction for this draft,
and many arguments against adding yet another Camel to BGP.

If no other vendor is interested in this, maybe it should not proceeed,
then.

Gert Doering
        -- Operator
-- 
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

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

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

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

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 8 Jan 2022 19:57:08 +0000

Susan Hares wrote on 08/01/2022 19:19:
> Based on the details from the developers, it seems to fulfill the intent 
> of the 2 implementations.

Uh, what's been written is a single bgp stack implementation with a 
separate controller implementation for injection. The two things are 
very different beasts and don't demonstrate any meaningful 
interoperability, which is the point of the 2-implementations requirement.

The same applies to the wide communities draft.

Nick

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 20:26:55 -0500

Nick: 

To help me in my discussion with the implementers on the implementation report,  Let's examine what new functionality the RPD uses:  

RPD uses a format much like the flow-specification (v1 and v2) where match (Target TLV, Exclude TLV) ends up enabling one of two actions: 
1) match and set attribute ([1a] alter MED or [1b] AS Path append). 
2) match and do not advertise the route to a peer [2a]   

Flow specification (v1) distributes flow policy allows for actions that discard all traffic [rpd 2a] or to set values [DSCP values] or to redirect traffic.  Therefore, distributing policy (routing or flow policy) that sets policy to discard traffic or set values [1a]

Are you concerned regarding the AS Path append [1b] because of GROW's document:  draft-ietf-grow-as-path-prepending-05.txt? 
draft-ietf-grow-as-path-prepending-05.txt indicates excessive AS path prepending can cause problems.  

Alternatives suggested in draft-ietf-grow-as-path-prepending-05.txt are: 
a) Altering MED for a 1 Hop change 
b) Using pre-defined communities (large communities) 
c) local preference to influence route selection on inbound paths rather than prepending. 

It appears that rpd is proposing a solution, 
(a) allows for altering of MED (rpd 1a) for a certain set of traffic
(b) allows for use of pre-defined WIDE communities to create policy (rpd match) for a specific set of route leaks, 
(c) allows a mechanism to influence route selection (rpd 2)
(d) allows for distributing prepending of AS policy for a single as or a sequence of AS (rpd 1b)  

If the prepending of the AS policy is your concern, please let me know.   
We can raise this specific issue with grow and IDR.  

Cheerily, Susan Hares 

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Saturday, January 8, 2022 2:57 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor Implementations (12/12/21 to 12/20/21) - Summary of call (1/7/2021)

Nick

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 8 Jan 2022 20:35:14 -0500

Nick: 

How do you define meaningful?   This is a question discussed and debated by IDR chairs over 30 years. 

Jeff and I defined meaningful as "quality of specification" in terms of interoperability.  This why we check for  two implementations written by two different teams where the details of the specification are clear enough to implement two inter-operable specifications.    

The current IDR chairs do not add scalable to the requirement.   The controllers and open source code (BIRD, FRR, Quagga) or some switches in data centers may not be as scalable as other implementations in core routers.  Some IDR chairs tried to restrict the requirement to vendor implementations defining these as was "scalable" and open-source "not scalable".   You will note that RFC4274 tried to answer some of these questions regarding the basic algorithm of BGP.  
 
My objective measure for measuring the interoperability is the implementation report and a discussion with the authors.   Based on your questions, I reviewed the text and the implementation reports.  I have asked to meet with Huaimo Chen who filed the implementation report for WIDE communities and RPD.   If the two teams can provide a high level of detail on the implementation reports and provide a narrative of what they learned in testing, this seems to be an objective measure of interoperability. 

Their implementation report and "lessons" learned will be on the IDR wiki.   I will send a note when I've finished the implementation report review for Wide communities and RPD.   
 
Cheerily, Susan Hares 

-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Saturday, January 8, 2022 2:57 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor Implementations (12/12/21 to 12/20/21) - Summary of call (1/7/2021)

Nick