Re: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to end September 25

Hi, 

Here are some comments from my side:

1. I agree with Randy and Robert to take a look at this feature from a more structural point of view.

2. It says “the capability is designed more to non-production environments...”. Does this imply it will not be seen in production networks? If so, perhaps the capability code reserved for experimental use would be sufficient?

3. It mentions LLDP etc. can provide this information, while information exchange between different processes is hard not recommended in some environments. Currently this WG has a design team on BGP autoconf , in which we are exploring the possibility of using some other protocol to facilitate the setup of BGP peering. This presumption may be related to the BGP autoconf discussion. 

Best regards,
Jie

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder
> Sent: Wednesday, September 9, 2020 3:12 AM
> To: IDR List <idr@ietf.org>
> Cc: Donatas Abraitis <donatas.abraitis@hostinger.com>
> Subject: [Idr] WG adoption call for draft-abraitis-bgp-version-capability-08, to
> end September 25
> 
> Hi All,
> 
> You may recall that we had a recent discussion about
> draft-abraitis-bgp-version-capability-07, which was on the ISE track. After
> some discussion both on and off list, the author has updated the document
> and requested WG adoption of
> https://datatracker.ietf.org/doc/html/draft-abraitis-bgp-version-capability-0
> 8.
> 
> This begins the usual two-week discussion period. Please send your support,
> opposition, comments, discussion, before September 25.
> 
> The recent thread is here:
> https://mailarchive.ietf.org/arch/msg/idr/q4pUI7jKnYEL_5Cr0mUfoHopY74/
> and an earlier thread, when Donatas first brought the subject up on the list,
> is here:
> https://mailarchive.ietf.org/arch/msg/idr/zHNioWl24mdTthQA0O4OatZ2uy
> 4/
> 
> It’s my impression from these two threads that there’s potentially interest
> from the WG in tackling the problem; it’s less clear to me that the WG
> supports the particular design outlined in the current draft. It would be
> helpful if you’d address both of these when commenting, and keep in mind
> that as usual WG adoption of the draft wouldn't mean “this is the exact
> solution”, it would mean “this is a good starting point.” Finally, as a result
> of the recent discussion, there’s been some renewed interest in
> draft-ietf-idr-operational-message. One suggestion (which I can’t put my
> finger on in the archives right now, sorry) was to turn
> draft-ietf-idr-operational-message into a pure framework document, i.e.
> define no TLVs in it, just the transport. If done, IMO that might open the door
> to more easily allowing a draft like the present one to adopt it as a transport.
> 
> The floor is open for your comments!
> 
> Thanks,
> 
> —John
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr