Re: [Idr] WG adoption of draft-heitz-idr-large-community; one week to comment on early code point allocation

[Job Snijders <[e-mail]>]

Dear Bertrand,

On Tue, Sep 27, 2016 at 08:34:06AM +0000, Bertrand Duvivier (bduvivie) wrote:
> Also will be great to define a ³universal² mapping between
> standard-communities and large-communities
> 
> If standard are X:Y
> 
> Then I see 3 options (of many more).
> Option 1 X:0:Y 
> Option 2 X:Y:0
> Option 3 Z:X:Y
> 
> I personally do prefer option 1.
> Could be 0 or any reserve number we agree on.

I do not think that mapping is as straight forward as it might appear at
first glance. I can see many more ways to map large & rfc1997 then the 3
you listed.

I am not sure whether mapping belongs in the draft-ietf-idr-large-community
document, or even in IDR. This was echoed earlier by John [1].

A mapping mechanism will have several requirements, those requirements
might differ from network to network. Ideally the mapping mechanism
helps you transition into your own namespace, but for others this might
not be a consideration. Maybe vendors should just provide the operator
with the tools to develop their own mappings & arithmetic.

I think both a mapping mechanism specification and the large community
draft will benefit from being able to proceed at different speeds,
possibly in different working groups.

I don't imagine that part of a mapping mechanism will be to change the
on-the-wire encoding, of negotiate bgp capabilities. If a mapping
mechanism _would_ require on-the-wire signalling of any sort, that would
be all the more reason for me to keep it separate from
draft-ietf-idr-large-community.

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/idr/7NYMcTmNJuUnQZcya4S1B4Iof3Q