Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129

"Susan Hares" <> Fri, 04 November 2016 01:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE6CE1296E8 for <>; Thu, 3 Nov 2016 18:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XC4mSBMVfY77 for <>; Thu, 3 Nov 2016 18:25:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50B761296B7 for <>; Thu, 3 Nov 2016 18:25:17 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=;
From: "Susan Hares" <>
To: "'John G. Scudder'" <>, "'Robert Raszuk'" <>
References: <> <> <> <>
In-Reply-To: <>
Date: Thu, 3 Nov 2016 21:22:57 -0400
Message-ID: <034a01d23639$fa2c78e0$ee856aa0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_034B_01D23618.731C3870"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQG4XNVJbFLLu0eQmTL8gVJbAkCFVwDjdK5pAXaolZsCtVg7VaDTO0EQ
Content-Language: en-us
Archived-At: <>
Cc: 'IETF IDR Working Group' <>
Subject: Re: [Idr] Working group adoption call for draft-snijders-idr-deprecate-30-31-129
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Nov 2016 01:25:19 -0000



My understanding with the IESG and IANA is that this is true.   The best
reference is the BIS for RFC226bis below:


The RFC5226bis-11.txt got stalled due to the IESG wandering if the revision
is needed.  Based on our experience, I think it is needed.  Alvaro will kick
off this work, but the process of updating a "process" document should not
impede this document's process.  We need to think outside the box. 


I suggest we complete this adoption of
draft-snijders-idr-deprecate-30-31-129 draft by 11/13/2016, and do a WG LC
on the draft directly following this process draft (11/14 to 11/28).    This
should allow the draft-idr-large-communities to have the necessary registry
"glue" ready so the IESG publication of large communities can go quickly.




From: Idr [] On Behalf Of John G. Scudder
Sent: Tuesday, November 1, 2016 10:24 AM
To: Robert Raszuk
Cc: IETF IDR Working Group
Subject: Re: [Idr] Working group adoption call for


AFAICT the function of the draft is simply to kick the IANA code point state
to "deprecated". It doesn't anchor it there for all time. Presumably a later
request can move the state to assigned or whatever, as we've previously
discussed. I don't think any update to the current "deprecate" document
would be needed to achieve this (I guess maybe the later document might list
this one in its "updates" header).


I'll confirm this understanding with IESG and IANA before the end of the WG
adoption call. (Unless someone can point me to chapter-and-verse of a
reference that explains the process clearly enough, unfortunately I have not
found such.)






On Nov 1, 2016, at 10:02 AM, Robert Raszuk <> wrote:


Hi Job,


Have you consider marking those codepoints as "RESERVED" rather then


Reason being that if any of the applications they have been squatted on
behalf of want to use them - it would be pretty easy to allocate them.


The other alternative would be to allocate them to those applications now
(for which the drafts exist) as IANA early allocations. If you depreciate
them now and we know that as example Contrail Multicast is important either
your draft will need to quickly be moved to historic or yet another types
will need to be allocated again. 


In any of the above Large Communities will get virgin BGP attribute type
which I believe is the main point here.






On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <> wrote:

Dear working group,

To prevent having multiple drafts in quick succession covering the same
style of issue - I'd like your feedback on the following:

I believe that bgp path attribute 241, 242, 243 should also be added to
this draft for the same reasons as 30, 31 and 129 are listed.

    This document requests IANA to deprecate the following BGP Path
    attributes: 30, 31, and 129.

    This document requests IANA to deprecate the following BGP Path
    attributes: 30, 31, 129, 241, 242, and 243.

Does anyone object? If so, why?

Unilaterally changing the document while in its mid-flight through the
working group adoption process might be considered bad form, hence my
request for feedback on the 241,242,243 topic.

Please note - the deprecation of an attribute can be undone if proper
process is followed. The priority here is to prevent IANA from assigning
tainted codepoints to innocent bystanders, thus a deprecation document
needs to exist. In time the working group has the power to undeprecate
them for specific purposes.

Kind regards,


On Mon, Oct 31, 2016 at 05:18:57PM -0400, John G.Scudder wrote:

> Hi Everyone,
> The author has asked for the WG to adopt
> If you support or oppose adoption please reply indicating so. Reasons for
your position are helpful, as volunteering to review, comment, and/or
shepherd. As an aside, I will note that I don't think the WG has the option
of doing nothing, so if you oppose adoption please address what you think
should be done instead.
> The adoption call will end November 13.
> Thanks,
> --John
> P.S.:
> Abstract
>    This document requests IANA to deprecate the following BGP path
>    attributes values: 30, 31 and 129.
> _______________________________________________
> Idr mailing list

Idr mailing list