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

["Susan Hares" <[e-mail]>]

Robert and others: 

 

The draft-snijders-idr-deprecate-30-31-129 draft should not delay an
official request for the Wide Community implementation.   The three
requirements are: 

 

1)      Stable draft, 

2)      1 or more Implementation, and testing work toward interoperability.
Implementers must be able to switch to another reference point if needed. 

3)      Approval by the IDR working group for early adoption. 

 

https://www.ietf.org/mail-archive/web/idr/current/msg16814.html

 

What is needed is a stable draft.   I recommend you work with Jie Dong, Mach
Chen, and Shunwan Zhang to make sure the next Wide communities draft aligns
with their implementation.  At that point, these teams can apply for an
early allocation. 

 

If you complete a stable draft by the beginning of IETF week, and the
implementers align their code with your draft - we can begin step 3.  Your
challenge is to get the stable specification that aligns with the code work
so the code work can progress quickly. 

 

Sue 

 

From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Thursday, November 3, 2016 9:23 PM
To: 'John G. Scudder'; 'Robert Raszuk'
Cc: 'IETF IDR Working Group'
Subject: Re: [Idr] Working group adoption call for
draft-snijders-idr-deprecate-30-31-129

 

John: 

 

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

 

https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-11

 

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.


 

Sue 

 

From: Idr [mailto:[e-mail]] 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
draft-snijders-idr-deprecate-30-31-129

 

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.)

 

Thanks,

 

--John

 

On Nov 1, 2016, at 10:02 AM, Robert Raszuk <[e-mail]> wrote:

 

Hi Job,

 

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

 

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.

 

Cheers,

R.

 

 

On Tue, Nov 1, 2016 at 2:32 PM, Job Snijders <[e-mail]> 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.

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

NEW:
    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,

Job

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
draft-snijders-idr-deprecate-30-31-129.
>
> 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.:
https://tools.ietf.org/html/draft-snijders-idr-deprecate-30-31-129-01
>
> Abstract
>
>    This document requests IANA to deprecate the following BGP path
>    attributes values: 30, 31 and 129.
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr

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