Re: [GROW] Fwd: New Version Notification for draft-ymbk-grow-bgp-collector-communities-02.txt

[Randy Bush]

hi job

thanks for reading and commenting!

> * 32-bit ASNs don't fit in 16-bit fields. Consider using a set of
>   Extended Communities?

next you're gonna want ipv6; sheesh!  :)

i think the draft tried to finesse and not get into wire format.  but it
probably should.

extended or wide?  

> * The Local Administrator values {64994,64995,64996} might already
>   be in use and carry local significance.

point taken.  with the alternate 10/10 hack, that would be ok.  with the
per-path model, a definite problem.

> * I wouldn't avoid setting up an IANA registry merely because there are
>   'very few categories'

point.  can we have a "can not be added to" registry to inhibit the
complicators a la 4384? 

> * Section 5's 'well-known prefix' perhaps should be set to TBD, rather
>   than using widely used RFC 1918 space.

i am not so sure.  i would not want to burn precious address space for
this.  and we want something not routable, yes?  but, yes, being a bit
more formal about the choice would be good.  discuss ...

the alternate hack would also need an ipv6 well-known prefix for the
collector peers which are v6 only in 2050 .

again, thanks for review.  much appreciated.

and good luck weathering the storm.

randy

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Fwd: New Version Notification for draft-ymbk-grow-bgp-collector-communities-02.txt

[Job Snijders]

Hi Randy, Emile,

A few small notes that might be of interest should you wish to progress
this draft:

* 32-bit ASNs don't fit in 16-bit fields. Consider using a set of
  Extended Communities?
* The Local Administrator values {64994,64995,64996} might already
  be in use and carry local significance.
* I wouldn't avoid setting up an IANA registry merely because there are
  'very few categories'
* Section 5's 'well-known prefix' perhaps should be set to TBD, rather
  than using widely used RFC 1918 space.

Kind regards,

Job

On Thu, Feb 17, 2022 at 01:22:09PM -0800, Randy Bush wrote:
> six and a half year old draft rises from the dead, with modification
> 
> From: internet-dra...@ietf.org
> To: Emile Aben , Randy Bush 
> Subject: New Version Notification for 
> draft-ymbk-grow-bgp-collector-communities-02.txt
> Date: Thu, 17 Feb 2022 13:09:38 -0800
> 
> A new version of I-D, draft-ymbk-grow-bgp-collector-communities-02.txt
> has been successfully submitted by Randy Bush and posted to the
> IETF repository.
> 
> Name: draft-ymbk-grow-bgp-collector-communities
> Revision: 02
> Title:Marking Announcements to BGP Collectors
> Document date:2022-02-17
> Group:Individual Submission
> Pages:5
> URL:
> https://www.ietf.org/archive/id/draft-ymbk-grow-bgp-collector-communities-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-ymbk-grow-bgp-collector-communities/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-ymbk-grow-bgp-collector-communities
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ymbk-grow-bgp-collector-communities-02
> 
> Abstract:
>When BGP route collectors such as RIPE RIS and Route Views are used
>by operators and researchers, currently one can not tell if the
>collection of paths announced to a collector represents the ISP's
>customer cone, includes internal routes, includes paths learned from
>peerings or transits.  This greatly reduces the utility of the
>collected data.  This document specifies the use of BGP communities
>to differentiate the kinds of views being presented to the
>collectors.
> 
> ___
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow