Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt

From: Yakov Rekhter <[email-masked]>
Date: Wed, 12 Jun 2013 07:33:32 -0700

Sue and John,

The authors of draft-rosen-idr-extcomm-iana-00.txt would like
the IDR WG to accept this draft as an IDR WG document.

Yakov & Eric.
------- Forwarded Message

Date:    Fri, 31 May 2013 11:47:38 -0400
From:    Eric Rosen <[email-masked]>
To:      IDR WG <[email-masked]>
Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt

- --=-=-=
Content-Type: text/plain

I would like to call this draft to the attention of the WG.

This draft proposes to reorganize the IANA registries for BGP Extended
Communities, so that there are separate registries for types and sub-types,
and so that the values that are available for assignment in one registry do
not depend upon the values that have already been assigned in another.

Yakov and I put this proposal together after hearing some complaints from
IANA about the difficulty of figuring out which values are available in
which registries.  We also found some mistakes in the registries and some
inconsistencies in the drafts that define the registries.  The intention of
this draft is to make it easier for IANA to fulfill its clerical function,
and to make it easier to understand what to request of IANA when a new
Extended Community is defined.  No changes to existing implementations or
deployments are required.

If you care about this sort of stuff, please review and provide your
comments.

- --=-=-=
Content-Type: message/rfc822
Content-Disposition: inline; filename=3423
Content-Description: forwarded message

MIME-Version: 1.0
Received: from mail.cisco.com [173.37.183.72]
	by erosen-linux with IMAP (fetchmail-6.3.6)
	for <erosen@localhost> (single-drop); Thu, 30 May 2013 13:51:50 -0400 (
EDT)
kJFCiCJQEBBAEBNwYBAQQKHgwCAwECBgJACAgDASNJBQSIBQIJqFCEPgEFjkoGjzmDQYkjik2DUAGBK
Yp3hEKEDQ
fix)
 with ESMTP id 7792021F968D	for <[email-masked]>; Thu, 30 May
 2013 10:50:49 -0700 (PDT)
y
 2013 10:50:46 -0700 (PDT)
From: <[email-masked]>
To: <[email-masked]>
Subject: I-D Action: draft-rosen-idr-extcomm-iana-00.txt
Date: Thu, 30 May 2013 10:50:46 -0700
Reply-To: <[email-masked]>
Sender: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IANA Registries for BGP Extended Communities
	Author(s)       : Eric C. Rosen
                          Yakov Rekhter
	Filename        : draft-rosen-idr-extcomm-iana-00.txt
	Pages           : 17
	Date            : 2013-05-30

Abstract:
   This document reorganizes the IANA Registries for the type values and
   sub-type values of BGP Extended Communities attribute and the BGP
   IPv6-Address-Specific Extended Communities attribute.  This is done
   in order to remove inter-dependencies among the registries, thus
   making it easier for IANA to determine which codepoints are available
   for assignment in which registries.  This document also clarifies the
   information that must be provided to IANA when requesting an
   allocation from one or more of these registries.  These changes are
   compatible with the existing allocations, and thus do not affect
   protocol implementations.  The changes will however impact the "IANA
   Considerations" sections of future protocol specifications.  This
   document updates RFCs 4360 and 5701.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rosen-idr-extcomm-iana

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-rosen-idr-extcomm-iana-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

- --=-=-=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

- --=-=-=--

------- End of Forwarded Message

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jun 2013 17:07:43 +0200

> the IDR WG to accept this draft as an IDR WG document.

i have read and support adoption

as to content, i find the process for adding, especially a new type, a
little loosey goosey.  perhaps an expert or a wg consultation would
reduce regrets

randy

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 14 Jun 2013 00:34:49 -0400

> the IDR WG to accept this draft as an IDR WG document.

Support adoption, comments below can be sorted out after acceptance...

A few comments or questions - not an implementor so possibly off base
on a few of these:

Section 3 - nit - it's not totally clear that RFC5701 defines the two
high order octets as "Type Field".  It certainly implies it, but calls
it by various other names throughout.

Section 4 - Can I suggest "Standards Action" for new Types, or at
least something more specific than request to IANA.

Section 5.1.1 - first thought it was mistake that simpson draft had
full type considering all other flowspec actions are sub-type of
experimental, but guess this is a point to take up with those authors
(although draft expired).  Might be easier if you specify in
paranthesis no sub-types for 0x04, 0x05, 0x08.  0x06 could use
standard wording of "Sub-types are defined in..."

Section 5.2 - it would be easier to understand I think if you split
transitive and non-transitive sub-types into seperate sub-sections.

Section 5.2.1 - this doesn't mention if it's transitive /
non-transitive, mute if you follow advice above.  Also - would it make
sense to order these sub-sections by type order?

Section 5.2.2 - Section header says Transitive, Registry Name says
Non-Transitive?

Section 5.2.10 - this section nor anywhere else in document talks
about Traffic Actions (for flow spec) which is currently referenced in
BGP Extended Communities registry - will it be removed from the
registry or should 0x07 just have a comment/reference to it's 
seperate registry? 

Section 6 - should you just change title of Section 5 then?

Section 10 - Considering this redefines every registry and has content
in it, maybe a note to IANA/RFC Editor to hold publication until URL
references to the actual re-organized IANA registries, which will be
more useful to future readers than stale content in Section 5.

Thanks,

-Jon

---

From: Eric Rosen <[email-masked]>
Date: Mon, 17 Jun 2013 09:11:06 -0400

Thanks for taking the time to read through all the tedious details!

> Section 6 - should you just change title of Section 5 then?

Yes, that seems like a sensible idea.

> Considering this redefines every registry and has content

Generally an RFC is not published until the IANA actions are completed;
there's a "waiting for IANA" state as part of the RFC Editor's workflow, and
IANA always (at least in my experience) verifies with the authors that the
proper IANA actions are being taken.

> Section 5.2.2 - Section header says Transitive, Registry Name says

Did you mean section 5.2.10?  The registry name should say "transitive".

> Section 5.2.10 - this section nor anywhere else in document talks about
> Traffic Actions (for flow spec) which is currently referenced in BGP
> Extended Communities registry - will it be removed from the registry or
> should 0x07 just have a comment/reference to it's separate registry?

I overlooked this one.  I think the proper way to handle it is with the
following entry in the "BGP Generic Non-Transitive Experimental Use
Extended Community Sub-Types" registry:

    0x07         Flow spec traffic-action (Use of the Value field is defined
                 in the "Traffic Actions Field" registry.)

> experimental, but guess this is a point to take up with those authors

Looking at draft-simpson-idr-flowspec-redirect, I see it defines a
transitive type (0x08), but it doesn't seem to define any sub-types, even
though it requests an "extended type".  Under the proposed reorganization,
the authors would have specify whether they want a Sub-Type registry for the
second octet, or whether they want to treat the second octet as part of the
value field. 

> 0x06 could use standard wording of "Sub-types are defined in..."

Yes, good point.

> transitive and non-transitive sub-types into seperate sub-sections.

I don't think that would be right, because the transitive/intransitive
distinction is part of the Type field, not part of the Sub-Type field.  It
should be possible for a Sub-Type registry to be shared between a transitive
Type and an intransitive Type (although there are no current examples of
that).

> least something more specific than request to IANA.

Both Type registries (and the Sub-Type registries as well) have defined
registration policies for specific value ranges.

---

From: "Hyojeong Kim (hyojekim)" <[email-masked]>
Date: Mon, 17 Jun 2013 18:22:41 +0000

Looking at your comment below, you treat all the flowspec action extcomms
as transitive. However, RFC 5575 says that traffic-rate is a
non-transitive extended community across the AS boundary. Have you checked
about it?

Thanks,
Hyojeong

---

From: Jon Mitchell <[email-masked]>
Date: Mon, 17 Jun 2013 17:33:21 -0400

> proper IANA actions are being taken.

Eric - this is understood - what I meant to ask is explicitly put a
normative reference to the existing URL (assuming it will be rebuilt
in same place), and reference that in section 5.  Also, putting a note
in the draft with instructions to RFC Editor (for removal upon
publication), to ensure that the proper final URL reference is
included in the RFC.  By the current reading of the draft, this could
be published as an RFC and all the IANA actions to re-organize the
registries coudld be done and this RFC would not have a URL reference
to the registry.

> Did you mean section 5.2.10?  The registry name should say "transitive".

Yes, sorry.

>                  in the "Traffic Actions Field" registry.)

Sounds good.

> Type and an intransitive Type (although there are no current examples of

OK - I thought a sub-type registry would be required to be defined for
each seperately (even if the values matched).  Thanks for clarifying.

> registration policies for specific value ranges.

Yes, I see it more clearly on second pass it's mentioned in Section 5
and Section 2.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Jun 2013 14:52:02 -0400

> the IDR WG to accept this draft as an IDR WG document.

I support adopting this draft.

I was always mildly cheesed about the fact that the transitive bit really
meant that you could have a code point such that masking the transitive bit
doesn't guarantee a distinct set of encodings.  At the moment, the registry
continues to contain values that could let this be the case, but I think
that particular ship has sailed.

(E.g. 0x5 is Cos, but there's no non-transitive form of it. If someone asks
for a new non-transitive value, 0x5 may be assigned and mean something
completely different.)

Since the draft cites a number of code points for specifications in-flight,
getting this draft all the way through RFC status will be fun.  Please make
sure to update the normative references to cover all of those code points.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 24 Jun 2013 14:24:28 -0400

Yakov and John: 

I've not seen John's official call for the acceptance of this draft as
WG-Draft.  We will extend this call until 7/5/13. 

Sue Hares 

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Wednesday, June 12, 2013 10:34 AM
To: [email-masked]; Susan Hares
Cc: [email-masked]; [email-masked]
Subject: [Idr] draft-rosen-idr-extcomm-iana-00.txt

Sue and John,

The authors of draft-rosen-idr-extcomm-iana-00.txt would like the IDR WG to
accept this draft as an IDR WG document.

Yakov & Eric.

- --=-=-=
Content-Type: text/plain

- --=-=-=

MIME-Version: 1.0
Received: from mail.cisco.com [173.37.183.72]
	by erosen-linux with IMAP (fetchmail-6.3.6)
	for <erosen@localhost> (single-drop); Thu, 30 May 2013 13:51:50
-0400 (
EDT)
Received: from rcdn-iport-3.cisco.com (173.37.86.74) by mail.cisco.com
 (173.36.12.79) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 30 May
 2013 12:51:06 -0500
Received: from rcdn-core-3.cisco.com ([173.37.93.154])  by
rcdn-iport-3.cisco.com with ESMTP; 30 May 2013 17:51:06 +0000
Received: from rcdn-inbound-h.cisco.com (rcdn-inbound-h.cisco.com
 [72.163.7.177])	by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP
id
 r4UHp50T018972;	Thu, 30 May 2013 17:51:05 GMT
Authentication-Results: rcdn-inbound-h.cisco.com; dkim=pass (signature
verified
 [TEST]) header.i=@ietf.org
X-from-outside-Cisco: 12.22.58.30
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result:
AiwBAMCQp1EMFjoenGdsb2JhbABZgmhRjG22JxYOAQEBAQEGDQ
kJFCiCJQEBBAEBNwYBAQQKHgwCAwECBgJACAgDASNJBQSIBQIJqFCEPgEFjkoGjzmDQYkjik2DUA
GBK
Yp3hEKEDQ
X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; 
   d="scan'208";a="108541937"
Received: from mail.ietf.org ([12.22.58.30])  by rcdn-inbound-h.cisco.com
with  ESMTP; 30 May 2013 17:51:02 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1])	by ietfa.amsl.com
 (Postfix) with ESMTP id EC2E521F968F;	Thu, 30 May 2013 10:50:53 -0700
(PDT)
(Post
fix)
 with ESMTP id 7792021F968D	for <[email-masked]>; Thu, 30
May
 2013 10:50:49 -0700 (PDT)
Ma
y
 2013 10:50:46 -0700 (PDT)
From: <[email-masked]>
To: <[email-masked]>
Subject: I-D Action: draft-rosen-idr-extcomm-iana-00.txt
Date: Thu, 30 May 2013 10:50:46 -0700
Reply-To: <[email-masked]>
Sender: <[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

- --=-=-=

- --=-=-=--

---

From: <[email-masked]>
Date: Tue, 25 Jun 2013 08:21:59 +0000

Hi Sue, John, all,

I've read and support WG adoption.

Bruno

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan
>Hares
>Sent: Monday, June 24, 2013 8:24 PM
>To: 'Yakov Rekhter'; [email-masked]
>Subject: Re: [Idr] draft-rosen-idr-extcomm-iana-00.txt
>
>Yakov and John:
>
>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
>	t=1369936254; bh=f9K8hgMBlrC6IvJlZGQ7gsMdJ1y8H9QLf1OKoW85G7s=;
>	h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id:
>	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
>	 Content-Type:Content-Transfer-Encoding:Sender;
>	b=OVexJgUO33kxYqNt/rg6+OrLmO1a2+GxCT13wCvsmy3Pm41a2DfP7BKhFbwdocfzE
>	 PGEjASzZW82rK5JwD/dI59+Byy9b13OLAN/U6q48AApj52j4T0/LrM22gJw89RXKcc
>	 llbJsjQFt0J6nZEn99e+BEszFZa7emUMWv8s2npY=
>X-Original-To: [email-masked]
>Delivered-To: [email-masked]
>Received: from localhost (localhost [127.0.0.1])	by ietfa.amsl.com
>(Post
>fix)
>X-Virus-Scanned: amavisd-new at amsl.com
>X-Spam-Flag: NO
>X-Spam-Score: -102.521
>X-Spam-Level:
>X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5
>	tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001,
>	USER_IN_WHITELIST=-100]
>Received: from mail.ietf.org ([12.22.58.30])	by localhost (ietfa.amsl.com
> [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id H1yYnbYGT9sp for
> <[email-masked]>;	Thu, 30 May 2013 10:50:48 -0700 (PDT)
> (Postfix) with ESMTP id 4A9AE21F9413	for <[email-masked]>; Thu,
>30
>Ma
>y
>X-Test-IDTracker: no
>X-IETF-IDTracker: 4.50
>Message-ID: <[email-masked]>
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.12
>Precedence: list
>List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>
>List-Unsubscribe: <https://www.ietf.org/mailman/options/i-d-announce>,
>	<mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://www.ietf.org/mail-archive/web/i-d-announce>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www.ietf.org/mailman/listinfo/i-d-announce>,
>	<mailto:[email-masked]?subject=subscribe>
>Errors-To: [email-masked]
>Return-Path: [email-masked]
>X-MS-Exchange-Organization-AuthSource: xhc-aln-x05.cisco.com
>X-MS-Exchange-Organization-AuthAs: Internal
>X-MS-Exchange-Organization-AuthMechanism: 10
>
>

_________________________________________________________________________________________________________________________

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.

---

From: "Dickson, Brian" <[email-masked]>
Date: Tue, 25 Jun 2013 15:11:20 +0000

I too have read this, and support WG adoption.

Brian

On 6/25/13 4:21 AM, "[email-masked]"
<[email-masked]> wrote:

>__________________________________________________________________________
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>As emails may be altered, France Telecom - Orange is not liable for
>messages that have been modified, changed or falsified.
>Thank you.
>