Subject: Re: [Isis-wg] [spring] I-D Action: draft-previdi-isis-segment-routing-extensions-05.txt

From: Loa Andersson <[email-masked]>
Date: Thu, 27 Feb 2014 12:45:45 +0100

Alvaro,

Yes you are right - the request for early allocation should go though
the isis wg; however I think it is partly a SPRING problem since
this has happened in other drafts also doing segment routing extensions
to one or the other protocol.

/Loa

On 2014-02-26 17:57, Alvaro Retana (aretana) wrote:
> On 2/26/14 5:43 AM, "Loa Andersson" <[email-masked]> wrote:
>
>> Yes it would, but I think there are more drafts intended for the sping
>> working group that does the same thing.
>
> Just a quick clarification given that this thread is in spring and not
> isis (cc'd now).
>
> The protocol extension drafts don't belong in spring.  The charter is
> clear in that any modifications must take place is the WG that owns the
> protocol.
>
> I think it is not inappropriate to have this discussion in spring (or
> maybe cc'ing spring) so that we're all on the same page..but it is clearly
> an issue that isis (in this case) has to resolve.
>
> Thanks!
>
> Alvaro.
>
>
>>
>> /Loa
>>
>> On 2014-02-26 09:31, Les Ginsberg (ginsberg) wrote:
>>> Hannes -
>>>
>>> The requested code points are specified in Section 4 of the draft.
>>> Could we bring this thread to closure by having you (or one of the other
>>> co-authors) formally request that the code points specified in the draft
>>> be given early allocation by Dave/Chris?
>>>
>>> I think that would address Loa's concern.
>>> ??
>>>
>>>      Les
>>>
>>>
>>>> -----Original Message-----
>>>> From: spring [mailto:[email-masked]] On Behalf Of Loa
>>>> Andersson
>>>> Sent: Tuesday, February 25, 2014 2:04 AM
>>>> To: Hannes Gredler
>>>> Cc: [email-masked];
>>>> [email-masked]; Christian Hopps; [email-masked]; Stefano
>>>> Previdi (sprevidi); [email-masked]
>>>> Subject: Re: [spring] I-D Action: draft-previdi-isis-segment-routing-
>>>> extensions-05.txt
>>>>
>>>> Hannes, et.al.,
>>>>
>>>> All of this are good arguments for doing an early allocation of code
>>>> points. My point is that this has not been done and that we now have
>>>> several documents that are doing allocation of code points without
>>>> coordinating with the IANA.
>>>>
>>>> To allocate code points early you need to request that the wg chairs
>>>> bring this to the ADs and IANA. Process is simple but need to be done
>>>> before we claim that the code points are allocated.
>>>>
>>>> /Loa
>>>>
>>>> On 2014-02-23 18:49, Hannes Gredler wrote:
>>>>> loa,
>>>>>
>>>>> quoting from rfc7120:
>>>>>
>>>>> ---   In protocol specifications documented in RFCs, there is often a
>>>>> need
>>>>>       to allocate code points for various objects, messages, or other
>>>>>       protocol entities so that implementations can interoperate.
>>>>> Many of
>>>>>       these code point spaces have registries handled by the Internet
>>>>>       Assigned Number Authority (IANA).  Several IETF policies for IANA
>>>>>       allocation of protocol parameters are described in  RFC 5226.
>>>>>       Some of them, such as "First Come First Served" or
>>>>>       "Expert Review", do not require a formal IETF action before the
>>>>> IANA
>>>>>       performs allocation.  However, in situations where code points
>>>>> are a
>>>>>       scarce resource and/or the IETF community has consensus to retain
>>>>>       tight control of the registry content, policies such as "IETF
>>>>> Review"
>>>>>       (formerly "IETF Consensus"), or "Standards Action" have been
>>>>> used.
>>>>>       Such allocation policies present a problem in situations where
>>>>>       implementation and/or deployment experience are desired or
>>>>> required
>>>>>       before the document becomes an RFC.
>>>>> ---
>>>>>
>>>>> couple of thoughts:
>>>>>
>>>>> 1. ISIS-WG code-point allocation is under 'expert review';
>>>>>       Experts being 'Dave Ward' and 'Chris Hopps' - i.e. my read of
>>>>>       the 7120 intro is that it does not apply here.
>>>>>
>>>>> 2. IGP WGs are these days 'low-maintenance', i.e. not many
>>>>>       new protocols do contend for code-points.
>>>>>
>>>>> 3. ISIS-WG chairs are keeping an eye on their submitted I-Ds
>>>>>       for potential clashes.
>>>>>
>>>>> 4. in that specific environment, as a WG-chair i do encourage
>>>>>       authors to specify their code-points such that interop testing
>>>>>       can be done. (my guess is that is better to document code-points
>>>>>       early on, rather than standardize the
>>>>> 'informal-single-vendor-standard'
>>>>>       in the eleventh hour.
>>>>>
>>>>> thanks,
>>>>>
>>>>> /hannes
>>>>>
>>>>>
>>>>> On Feb 20, 2014, at 11:47 AM, Loa Andersson wrote:
>>>>>
>>>>>> Stefano,
>>>>>>
>>>>>> While i agree to what you say about the consensus about the SPRING
>>>>>> architecture and that it would be great if you#d could benefit from
>>>>>> RFC 7120.
>>>>>>
>>>>>> However, to allocate code points in existing register you have to go
>>>>>> through the 7120 procedures, and the request to allocate code points
>>>>>> early the requests need to come from wg-chair and AD's.
>>>>>>
>>>>>> As far as I can you have not gone through that procedure. The code
>>>>>> points should be TBA until that is done.
>>>>>>
>>>>>> /Loa
>>>>>>
>>>>>> On 2014-02-17 10:41, Stefano Previdi (sprevidi) wrote:
>>>>>>> Loa,
>>>>>>>
>>>>>>> On Feb 14, 2014, at 8:41 AM, Loa Andersson wrote:
>>>>>>>> Authors,
>>>>>>>>
>>>>>>>> I've a question on this draft. If I understand correctly you are
>>>>>>>> making
>>>>>>>> allocations of code points from an already existing IANA registry.
>>>>>>>>
>>>>>>>> Publishing codes come with the "risk" that someone think they are
>>>>>>>> truly
>>>>>>>> allocated and implement using these code points.
>>>>>>>
>>>>>>>
>>>>>>> Ideally, we'd like to benefit from RFC7120 which states:
>>>>>>>
>>>>>>>      This memo describes the process for early allocation of code
>>>>>>> points
>>>>>>>      by IANA from registries for which "Specification Required", "RFC
>>>>>>>      Required", "IETF Review", or "Standards Action" policies apply.
>>>>>>> This
>>>>>>>      process can be used to alleviate the problem where code point
>>>>>>>      allocation is needed to facilitate desired or required
>>>>>>> implementation
>>>>>>>      and deployment experience prior to publication of an RFC, which
>>>>>>> would
>>>>>>>      normally trigger code point allocation.  The procedures in this
>>>>>>>      document are intended to apply only to IETF Stream documents.
>>>>>>>
>>>>>>> So, terms such as "implementation" and "deployment" are used and
>>>>>>> knowing
>>>>>>> that:
>>>>>>>
>>>>>>> . Segment Routing architecture as a large consensus among vendors
>>>>>>>       and operators
>>>>>>> . Segment Routing protocol extensions have an even larger consensus
>>>>>>>       among vendors and operators since the protocol extensions
>>>>>>> required
>>>>>>>       for Segment Routing do also address requirements from other
>>>>>>> label
>>>>>>>       distribution mechanisms
>>>>>>> . Segment Routing is being shipped by multiple interoperable vendors
>>>>>>>      (reports will follow shortly)
>>>>>>> . Segment Routing is in deployment plans of several operators
>>>>>>>
>>>>>>> I believe all conditions are met in order for us to benefit from
>>>>>>> RFC7120
>>>>>>> and get early allocation code points.
>>>>>>>
>>>>>>> This would allow the industry to move on with this new technology
>>>>>>> and
>>>>>>> IETF to still lead the innovation and standardization of it.
>>>>>>>
>>>>>>>
>>>>>>> Thanks.
>>>>>>> s.
>>>>>>>
>>>>>>>
>>>>>>>> Now what will you do if some document in the pipe allocate one of
>>>>>>>> the
>>>>>>>> code-points you are allocating through the normal process? You
>>>>>>>> will have
>>>>>>>> a code point deployed, that belongs to another protocol.
>>>>>>>>
>>>>>>>> /Loa
>>>>>>>>
>>>>>>>> On 2014-02-13 23:27, [email-masked] wrote:
>>>>>>>>>
>>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>           Title           : IS-IS Extensions for Segment Routing
>>>>>>>>>           Authors         : Stefano Previdi
>>>>>>>>>                             Clarence Filsfils
>>>>>>>>>                             Ahmed Bashandy
>>>>>>>>>                             Hannes Gredler
>>>>>>>>>                             Stephane Litkowski
>>>>>>>>>                             Jeff Tantsura
>>>>>>>>> 	Filename        : draft-previdi-isis-segment-routing-extensions-
>>>> 05.txt
>>>>>>>>> 	Pages           : 27
>>>>>>>>> 	Date            : 2014-02-13
>>>>>>>>>
>>>>>>>>> Abstract:
>>>>>>>>>      Segment Routing (SR) allows for a flexible definition of
>>>>>>>>> end-to-end
>>>>>>>>>      paths within IGP topologies by encoding paths as sequences of
>>>>>>>>>      topological sub-paths, called "segments".  These segments are
>>>>>>>>>      advertised by the link-state routing protocols (IS-IS and
>>>>>>>>> OSPF).
>>>>>>>>>
>>>>>>>>>      This draft describes the necessary IS-IS extensions that need
>>>>>>>>> to be
>>>>>>>>>      introduced for Segment Routing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>>>>
>>>>>>>>> https://datatracker.ietf.org/doc/draft-previdi-isis-segment-routing
>>>>>>>>> -
>>>> extensions/
>>>>>>>>>
>>>>>>>>> There's also a htmlized version available at:
>>>>>>>>> http://tools.ietf.org/html/draft-previdi-isis-segment-routing-
>>>> extensions-05
>>>>>>>>>
>>>>>>>>> A diff from the previous version is available at:
>>>>>>>>>
>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-previdi-isis-segment-routing
>>>>>>>>> -
>>>> extensions-05
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>>>>>>> until the htmlized version and diff are available at
>>>>>>>>> tools.ietf.org.
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Loa Andersson                        email: [email-masked]
>>>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> spring mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> spring mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Loa Andersson                        email: [email-masked]
>>>>>> Senior MPLS Expert                          [email-masked]
>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> spring mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Loa Andersson                        email: [email-masked]
>>>> Senior MPLS Expert                          [email-masked]
>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>
>>>> _______________________________________________
>>>> spring mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>> _______________________________________________
>>> spring mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>
>> --
>>
>>
>> Loa Andersson                        email: [email-masked]
>> Senior MPLS Expert                          [email-masked]
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>
>> _______________________________________________
>> spring mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 26 Feb 2014 16:57:27 +0000

Thanks!

Alvaro.