Re: [Idr] BGP autodiscovery design team

[Robert Raszuk <[e-mail]>]

Hi Job,

>  Perhaps the design team’s mailing list should be [e-mail]

Indeed !

I do not understand why there is any need for "design team" if required
functionality is about one of the core protocol functionality. What are we
trying to achieve - if someone on IDR is not interested given mail thread
can be easily moved to trash.

Hi Jim,

Many thx for your opinion. Very much appreciated here.

Also as we see from some proposals the core DC auto peering (also called by
some as "autodiscovery") can be done with the assistance of existing L2
protocols. So I think the fundamental first question is if this work even
belongs to IDR.

Thx,
R.



On Thu, Dec 5, 2019 at 2:50 PM Job Snijders <[e-mail]> wrote:

> On Thu, Dec 5, 2019 at 14:46 UTTARO, JAMES <[e-mail]> wrote:
>
>> *I agree with Roberts’ point. Prior to crafting or selecting a draft as
>> the basis for a proposal the design team should clearly articulate the
>> scope, use cases and requirements that need to be addressed. IMO stating
>> that in an informational RFC is a good way to ensure that all stakeholders
>> are in agreement as to what the eventual specification/draft addresses, and
>> as important does not address. When creating EVPN we first crafted an
>> informational RFC https://tools.ietf.org/html/rfc7209
>> <https://tools.ietf.org/html/rfc7209> that specified Active/Active
>> Multi-homing, flooding and multicast optimization etc… which formed the
>> basis for the RFC 7432. This focused the design team on realizing the
>> requirements articulated there.*
>>
>
> I think the above is good feedback.
>
> Also, it appears the entire working groep is interested to be part of the
> design team. Perhaps the design team’s mailing list should be [e-mail]?
> :-)
>
> Kind regards,
>
> Job
>