Subject: [Idr] WG Call for draft-ietf-idr-rpd-14.txt - Single Vendor Implementations (12/12/21 to 12/20/21)

From: Keyur Patel <[email-masked]>
Date: Sun, 12 Dec 2021 01:21:49 +0000

Hi Folks,

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

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.

Best Regards,
Keyur

---

From: Gert Doering <[email-masked]>
Date: Fri, 17 Dec 2021 18:09:46 +0100

Hi,

> 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

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 17 Dec 2021 10:41:49 -0800

With Gert.

Seriously???

“After the route is delivered to a router, it will be successful.  This is guaranteed by the BGP protocols.

If there is a failure for the router to install the route locally, this failure is a bug of the router.  The bug needs to be fixed.”

Cheers,
Jeff

> On Dec 17, 2021, at 09:10, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Dec 2021 14:56:09 -0500

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:[email-masked]] On Behalf Of Gert Doering
Sent: Friday, December 17, 2021 12:10 PM
To: Keyur Patel
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)

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

Gert Doering
        -- Operator

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: Robert Raszuk <[email-masked]>
Date: Fri, 17 Dec 2021 21:13:43 +0100

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.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Dec 2021 15:46:57 -0500

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

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.

Gert: 

Thank you,  Sue 

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

Hi,

Gert Doering
        -- Operator

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 17 Dec 2021 15:53:25 -0500

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: 
>  
> On Fri, Dec 17, 2021 at 8:56 PM Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
>> Gert: 
>> 
>> From: Idr [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gert Doering
>> Cc: [email-masked] <mailto:[email-masked]>
>> > The draft https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd <https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd>  has
>> https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20implementations <https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-rpd%20implementations>.
>> > 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>_______________________________________________
> Idr mailing list
> [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Dec 2021 22:24:47 +0100

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
>
>
> 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.
> *From:* Idr [mailto:[email-masked] <[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,
>
> IMO we should care less about vendors here - what really matters is to
> have implementation done with at least two independent BGP code bases

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Dec 2021 18:19:21 -0500

Robert and Gert: 

Jeff message indicates our intent.  

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

Jeff message gives accurate concerns regarding different production lines within companies (controller, firewall, controller).   Rather than dismiss two implementation from different product lines, the chairs have begun to ask “was it an independent source”.   Does it follow the process we want to see? 

An open source implementation is always useful to progress drafts as it allows people to inspect the code.  For technology changes such as SR-routing, BGP-LS, and RPD (policy distribution), as an operator you may wish encourage support of these features in open source implementations.  

Back to the question for this WG LC, the question is whether the implementations followed Jeff carefully worded description. 

I suspect the authors and co-authors will provide us with some feedback. 

Sue 

From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Friday, December 17, 2021 3:53 PM
To: Sue Hares
Cc: Robert Raszuk; 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)

-- Jeff

Robert: 

Sue 

Hi Sue,

Cheers,

R.

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

Gert: 

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

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.

Gert Doering
        -- Operator

_______________________________________________
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

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Dec 2021 16:58:17 -0800

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

bingo.  and there should be no problem if they are on the same code base.

the goal here is a pragmatic test of the clarity and implementability of
the specification.

randy

---

From: "Susan Hares" <[email-masked]>
Date: Sat, 18 Dec 2021 10:08:22 -0500

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. 

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

-- Jeff

Robert: 

Sue 

Hi Sue,

Cheers,

R.

Gert: 

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

Hi,

Gert Doering
        -- Operator

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Mon, 27 Dec 2021 03:26:34 +0000

Hi Chairs,

Currently there are two implementations of this feature:
One is from the router product line, this feature is supported since VRP V800R018C00.
The other one is from controller product line, this feature is supported since NCE V100R018C00.
The code base and the versions supporting this feature are developed and maintained by two completely independent teams.

Regards,
Haibo

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

Robert and Gert:

Sue

-- Jeff

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

Robert:

Sue

Hi Sue,

Cheers,
R.

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

Thank you,  Sue

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

Hi,

Gert Doering
        -- Operator

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

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