Re: [Idr] Early allocation request for draft-ietf-idr-segment-routing-te-policy

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 10 October 2017 16:52 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CFA134EBB for <idr@ietfa.amsl.com>; Tue, 10 Oct 2017 09:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfjGycFKaLO8 for <idr@ietfa.amsl.com>; Tue, 10 Oct 2017 09:52:52 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB9213510C for <idr@ietf.org>; Tue, 10 Oct 2017 09:43:34 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9AGhSI7024934; Tue, 10 Oct 2017 17:43:28 +0100
Received: from 950129200 (62.192.112.87.dyn.plus.net [87.112.192.62]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id v9AGhRlD024913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Oct 2017 17:43:28 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Jeff Tantsura' <jefftant.ietf@gmail.com>, "'Acee Lindem (acee)'" <acee@cisco.com>
Cc: idr@ietf.org, shares@ndzh.com
References: <D52C5D5F-3161-450E-A9E8-F03BBA46DD9E@juniper.net> <5021b09f13dd48468385583e31b0dd3e@XCH-ALN-001.cisco.com> <D5FCE067.CD304%acee@cisco.com> <ABDC5F4F-AD97-4E71-98E9-FE26B316F661@gmail.com>
In-Reply-To: <ABDC5F4F-AD97-4E71-98E9-FE26B316F661@gmail.com>
Date: Tue, 10 Oct 2017 17:43:28 +0100
Message-ID: <03fb01d341e6$e6e99e70$b4bcdb50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLsSp6/9z2TmpRg9BP7SuNJyisWtwIL/hG0AwV/fR8BkMpyEqB2JZpA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23384.000
X-TM-AS-Result: No--42.780-10.0-31-10
X-imss-scan-details: No--42.780-10.0-31-10
X-TMASE-MatchedRID: 9vvqFUF7IWnW/bDrA6VrLX4f9De+CyQCPxXiWH/cMXUC5WKtSs0Iv0+z yRCAu91i4OxaxlOc4J3vaFFFh/+qoNcUNjoF7YuV+8AO9OcJ/m/4uJ1REX4MHeFtzfyKYkVBvql B4fqMN6SlXUU7yxjrIPaIgZUXBHUYm/FNQJtMghF2cLm5pLq1v1NDrIPosXvF9+Cxv5vwbwoM2b 9SLN604iN/GvIEBz8REVAqpT+ASb9Y08jGTVCttAz4VsCc1YW+oprEeoZHCQIwyfWtyopBqK0Ro mhWPJaQw4ZPMwcO9heWO1pAoWOSDpcqz3g0A4fynhHKNOYbLL5bAoaK+wS4jbrfxlRjqBJ3U3m+ JXAyVvAEPX3EhxdnYr/duX0pgBjTKyG2Dpa679qzI1v7J4hECoHYSO53TbTgwEz5jkq73mUuu9H toCYkWHrIXxviGvIMavq0oj6mbr4P7YVDZjlcy+YAh37ZsBDC6WNmYQcB5ExhOIJLkQ75WP4e8u mIMMidPTe4Or1oyA+Cu5K/DoutfCyHCOdCTVPdtLDu9qtqKeHtMsBKGEjbqbKeTtOdjMy6CPxTH CQe5Snk0G8Qxre9VQiT+uMyEXZCwM+yBrP9nY+puD25aEtgt/ioIsi7Sa0gsneuamRRT5M6W33U wHDV5uLzNWBegCW2XC3N7C7YzrftNz9YYotrJEnbrC9RP+JRBTmtD+MNluqOhzOa6g8KrZRMZUC EHkRt
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T6Jqq17PW9BxvW2FdNGxSfkTGIU>
Subject: Re: [Idr] Early allocation request for draft-ietf-idr-segment-routing-te-policy
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 16:52:55 -0000

In full agreement.

Let's get the "early" allocation done using some nice clean codepoints from the
good folk at IANA.

John, what's the next step?

A

> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Tantsura
> Sent: 06 October 2017 17:32
> To: Acee Lindem (acee)
> Cc: idr@ietf.org; shares@ndzh.com
> Subject: Re: [Idr] Early allocation request for
draft-ietf-idr-segment-routing-te-
> policy
> 
> +1
> Having code points allocated early would save early implementations from
> changing later on, de-allocation for drafts that didn't make it should be
quite
> straightforward process.
> 
> Regards,
> Jeff
> 
> > On Oct 6, 2017, at 04:28, Acee Lindem (acee) <acee@cisco.com> wrote:
> >
> > Hi John, Les,
> >
> > On 10/6/17, 1:53 AM, "Idr on behalf of Les Ginsberg (ginsberg)"
> > <idr-bounces@ietf.org on behalf of ginsberg@cisco.com> wrote:
> >
> >> John -
> >>
> >> Thanx for the detailed analysis.
> >> Inline.
> >>
> >>> -----Original Message-----
> >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of John G. Scudder
> >>> Sent: Tuesday, October 03, 2017 2:17 PM
> >>> To: idr@ietf.org
> >>> Cc: shares@ndzh.com
> >>> Subject: [Idr] Early allocation request for
> >>> draft-ietf-idr-segment-routing-te-
> >>> policy
> >>>
> >>> Hi WG,
> >>>
> >>> Over a month ago we had a request for early allocation of the code
> >>> points in
> >>> draft-ietf-idr-segment-routing-te-policy. I think that means the TBD
> >>> code
> >>> points listed in section 8.3, the Preference, Binding SID, and Segment
> >>> List
> >>> sub-TLVs, since all the rest have been properly allocated by IANA
> >>> already.
> >>> The draft appears to fulfill the requirements for early allocation,
> >>> with one
> >>> possible exception.
> >>>
> >>> RFC 7120 says
> >>>
> >>>   c.  The specifications of these code points must be stable; i.e., if
> >>>       there is a change, implementations based on the earlier and later
> >>>       specifications must be seamlessly interoperable.
> >>>
> >>> On the face of it the current version of the spec fulfills this
> >>> requirement. I'm
> >>> slightly concerned that up through draft-previdi-idr-segment-routing-te-
> >>> policy-02, there were specific values given for
> >>>
> >>>   o  new sub-TLVs in the registry "BGP Tunnel Encapsulation Attribute
> >>>      sub-TLVs":
> >>>
> >>>         Suggested         Description            Reference
> >>>            Value
> >>>          -----------------------------------------------------
> >>>              6           Preference sub-TLV       This document
> >>>              7           Binding SID sub-TLV      This document
> >>>              8           Segment List sub-TLV     This document
> >>>
> >>> These values conflict with values allocated for other uses in the IANA
> >>> registry. This was corrected quite some time ago, in -03 published
> >>> December
> >>> of 2016, which lists the values as "TBD" just as the current version
> >>> does, so
> >>> maybe there's no problem at all.
> >>>
> >>> I presume that if we proceed forward with early allocation, any
> >>> pre-standard
> >>> implementations will be updated to use whatever values IANA actually
> >>> allocates -- which are sure not to be 6, 7 or 8 since those are already
> >>> in use. If
> >>> that's so, then fine. If not, then we may need to have a discussion
> >>> about
> >>> whether we really meet the "stability" requirement.
> >>>
> >> [Les:] It is quite useful I think to point out this fact - but I fail to
> >> see how it is relevant to the early allocation decision.  Given that we
> >> know that these early codepoints are not available, I do not see that
> >> delaying early allocation helps in any way. If there are implementations
> >> that used these unassigned codepoints, the sooner we assign values the
> >> sooner these implementations can be updated to use values which will be
> >> interoperable - so if anything the facts argue that we should accelerate
> >> early allocation - not delay it.
> >
> > I agree totally, we'll achieve nothing by delaying this any longer.
> >
> > Thanks,
> > Acee
> >
> >
> >
> >>
> >> ???
> >>
> >>  Les
> >>
> >>
> >>> This begins a one-week period for discussion of the early allocation,
> >>> which
> >>> time period may be extended if conversation warrants it. For
> >>> completeness,
> >>> here's my evaluation of the full list of RFC 7120 criteria:
> >>>
> >>>   a.  The code points must be from a space designated as "RFC
> >>>       Required", "IETF Review", or "Standards Action".  Additionally,
> >>>       requests for early assignment of code points from a
> >>>       "Specification Required" registry are allowed if the
> >>>       specification will be published as an RFC.
> >>>
> >>> Yes.
> >>>
> >>>   b.  The format, semantics, processing, and other rules related to
> >>>       handling the protocol entities defined by the code points
> >>>       (henceforth called "specifications") must be adequately described
> >>>       in an Internet-Draft.
> >>>
> >>> Yes.
> >>>
> >>>   c.  The specifications of these code points must be stable; i.e., if
> >>>       there is a change, implementations based on the earlier and later
> >>>       specifications must be seamlessly interoperable.
> >>>
> >>> Tentatively yes but see above.
> >>>
> >>>   d.  The Working Group chairs and Area Directors (ADs) judge that
> >>>       there is sufficient interest in the community for early (pre-RFC)
> >>>       implementation and deployment, or that failure to make an early
> >>>       allocation might lead to contention for the code point in the
> >>>       field.
> >>>
> >>> Yes.
> >>>
> >>> Thanks,
> >>>
> >>> --John
> >>> _______________________________________________
> >>> Idr mailing list
> >>> Idr@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/idr
> >>
> >> _______________________________________________
> >> Idr mailing list
> >> Idr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/idr
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr