Subject: Re: [Idr] draft-ietf-idr-reserved-extended-communities

From: <[email-masked]>
Date: Mon, 21 May 2012 10:30:38 +0000

Jeff,

Many thanks for your review of the draft and your comments.

In short, I agree with you and I have updated the draft as per your comments.
I believe the new version (03) should address your comments. If this not the case, comments are welcomed.

Thanks,
Best regards,
Bruno

>From: Jeffrey Haas [mailto:[email-masked]] >Sent: Sunday, March 11, 2012 8:23 PM
>
>Bruno,
>
>On Wed, Feb 22, 2012 at 11:05:59AM +0000, [email-masked] wrote:
>> As a reminder, draft-ietf-idr-reserved-extended-communities currently
>proposes to use the AS number O to get a global space of "generic four-octet AS
>specific" extended community (as defined in draft-ietf-idr-as4octet-extcomm-
>generic-subtype) in order to be able to get IANA assigned extended communities
>values from. (i.e. the equivalent of formerly "well known" RFC 1997
>communities).
>>
>> Following some discussion on draft-ietf-idr-as0, another option is to use AS
>number 0x0000FFFF instead of AS 0. This seems also more in line with RFC 1997
>which use the same AS number (0xFFFF) for the same purpose (IANA assigned
>communities).
>
>I think using AS 0.65535 (as-dot notation) is probably reasonable given the
>semantics you are looking for.
>
>After spending some additional time thinking about your draft, I believe
>that the primary desired behavior is to add the ability to create
>non-transitive well-known communities.  Since transitive well-known
>communities are easiest (and most backward-compatible at the moment) to
>express as RFC 1997 4-byte communities I would make the following
>suggestion:
>
>- Recommend that IANA set aside the 0.65535 4-byte AS name space using
>  draft-ietf-idr-as4octet-extcomm-generic-subtype.
>- Recommend that only non-transitive types are registered in the above
>  registry.
>- Recommend that when a transitive well-known community is registered in the
>  IANA RFC 1997 community that, when appropriate, a non-transitive version
>  of the community be made similarly available in the new registry.
>
>The above captures the spirit of backward compatibility in
>draft-ietf-idr-as4octet-extcomm-generic-subtype:
>
>:   Therefore, for backward compatibility with existing deployments and
>:   to avoid inconsistencies between standard communities and 4-octet
>:   extended communities, Autonomous Systems that use 2-octet Autonomous
>:   System numbers SHOULD use standard 2-octet communities as defined in
>:   RFC1997 rather than the 4-octet AS specific extended community as
>:   defined in this document.
>
>-- Jeff (not officially speaking for the other as4octet authors, but
>probably capturing the spirit of our discussion)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.