Re: [GROW] [Idr] Question about BGP Large Communities

[Randy Bush]

> To the topic of using Large Communities - I do recommend whichever encoding
> is chosen to always be able to insert and carry originator's ASN. All zeros
> are meaningless read: anonymous.

one can no longer assume all actors have good intent.

communities are arbitrary graffiti whose beauty lies in the eyes of the
beholder.  one can not assume rigor.

randy

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

Re: [GROW] [Idr] Question about BGP Large Communities

[Randy Bush]

> I'm asking for 67 million AS numbers, after which there will still be
> over 4 billion AS numbers, 
> not including the nearly 95 million private AS numbers.

should be enough.  after all, ipv6 only had 4096 possible providers

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

Re: [GROW] Question about BGP Large Communities

[Nick Hilliard]

Zhuangshunwan wrote on 05/02/2020 09:00:
In my opinion, when we apply a new function from IANA, we will have to 
deploy some extra route policies to set and parse the specific function 
as your suggested way.


With the increase of new functions, the route policies deployed will 
become more and more complicated.


A WKC will generally describe a specific function or set of actions to 
be applied to a prefix. If the WKC also encodes an administrator ASN or 
a target ASN, then it becomes a domain-specific community rather than a 
well-known community.


I'm not against the idea of LC WKCs in theory, but there would need to 
be compelling reasons as to why the existing rfc1997 wkc range didn't 
work.  IOW, we should think twice about setting aside a range unless 
there are specific deployment cases which need LCs, and where rfc 1997 
communities wouldn't work.


Nick

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

Re: [GROW] Question about BGP Large Communities

[Robert Raszuk]

Just to clarify one subtle point.

In wide communities types are either operator assigned or IANA driven - no
new code from vendor is required in contrast to extended community. That
along with variable length is what makes wide communities universal.

Sure that some vendors or individuals are scared about policy aspect of
wide communities processing - but implementing policy handling any
arbitrary types (irrespective of IANA or local assignment) is optional.

- - -

To the topic of using Large Communities - I do recommend whichever encoding
is chosen to always be able to insert and carry originator's ASN. All zeros
are meaningless read: anonymous.

Thx,
R.


On Wed, Feb 5, 2020 at 2:45 AM Brian Dickson 
wrote:

> Disagree, we want something deployed (large) and deployable (requiring
> only IANA action, no vendor activity) immediately.
> IMHO, any special handling or new code points or upgrades are non-starters.
> This particularly applies to wide and extended
> Brian
>
> On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) 
> wrote:
>
>> Agree that for this case it may be more convenient to just use extended
>> community with a new type, this could avoid any possible collision with
>> existing deployments, and save the effort of assigning a set of ASNs. Wide
>> community may be too powerful for this:)
>>
>>
>>
>> Best regards,
>>
>> Jie
>>
>
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] Question about BGP Large Communities

[Zhuangshunwan]

Hi,

In my opinion, when we apply a new function from IANA, we will have to deploy 
some extra route policies to set and parse the specific function as your 
suggested way.
With the increase of new functions, the route policies deployed will become 
more and more complicated.

Best regards,
Shunwan

From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Brian Dickson
Sent: Wednesday, February 5, 2020 9:45 AM
To: Dongjie (Jimmy) 
Cc: i...@ietf.org; grow-cha...@ietf.org; idr-cha...@ietf.org; grow@ietf.org
Subject: Re: [GROW] Question about BGP Large Communities

Disagree, we want something deployed (large) and deployable (requiring only 
IANA action, no vendor activity) immediately.
IMHO, any special handling or new code points or upgrades are non-starters.
This particularly applies to wide and extended
Brian

On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Agree that for this case it may be more convenient to just use extended 
community with a new type, this could avoid any possible collision with 
existing deployments, and save the effort of assigning a set of ASNs. Wide 
community may be too powerful for this:)

Best regards,
Jie

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Wednesday, February 5, 2020 6:38 AM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>
Cc: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>; Job 
Snijders mailto:j...@ntt.net>>; Nick Hilliard 
mailto:n...@foobar.org>>; John Heasly 
mailto:h...@shrubbery.net>>; 
i...@ietf.org; 
grow-cha...@ietf.org; 
idr-cha...@ietf.org; 
grow@ietf.org
Subject: Re: [GROW] Question about BGP Large Communities


> How would you divide the numbers?

I would not divide them at all in LCs. I would either define new type in 
extended communities or use wide communities.

But I am a bit biased here ;-)

Best,
R,

On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
The numbers are a trade off. How would you divide the numbers?
Thanks,
Jakob.

On Feb 4, 2020, at 2:19 PM, Robert Raszuk 
mailto:rob...@raszuk..net>> wrote:

And you think 255 such known large communities will be sufficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) 
mailto:jhe...@cisco.com>> wrote:
A set of well known large communities could be useful.
I have a draft that I never submitted attached to this email.
Does anyone want to co-author and suggest changes?

Regards,
Jakob.

From: Sriram, Kotikalapudi (Fed) 
mailto:kotikalapudi.sri...@nist.gov>>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) mailto:jhe...@cisco.com>>; Job 
Snijders mailto:j...@ntt.net>>; Nick Hilliard 
mailto:n...@foobar.org>>; John Heasly 
mailto:h...@shrubbery.net>>
Cc: i...@ietf.org; grow@ietf.org; 
idr-cha...@ietf.org; 
grow-cha...@ietf.org; 
a.e.azi...@gmail.com; Brian Dickson 
mailto:brian.peter.dick...@gmail.com>>
Subject: Question about BGP Large Communities


In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.

We specify this to be a "well-known transitive Large Community".



Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?



There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.





Details/background:



We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195



RFC 8195 has this table:

 +---+-+

 |   RFC8092| RFC 8195|

 +---+--+

 | Global Administrator|  ASN |

 |  Local Data Part 1   |Function  |

 |  Local Data Part 2   |   Parameter|

 ++-+

which is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.



For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).