Re: [spring] draft-filsfils-spring-srv6-network-programming

[Loa Andersson <[e-mail]>]

Satoru and Clarence,

The news of successful deployment of SRv6 is encouraging, a good step
for both V6 and SR.

Congrat's!

Since this was announced in a mail indicating draft-filsfils-spring-
srv6-network-programming, I took a look at the draft itself, in
particular the IANA section.

A few questions on on the the new sub-registry.

The registration procedure  (apart from a typo in the header) are listed
like this.

1. Do we really need

    +-------------+---------------+--------------------+----------------+
    | Range       |      Hex      |    Registration    |     Notes      |
    |             |               |     proceadure     |                |
    +-------------+---------------+--------------------+----------------+
    | 0           |     0x0000    |      Reserved      |    Invalid     |
    | 1-32767     | 0x0001-0x7FFF |    IETF review     |     Draft      |
    |             |               |                    | Specifications |
    | 32768-49151 | 0x8000-0xBFFF |    Reserved for    |                |
    |             |               |  experimental use  |                |
    | 49152-65534 | 0xC000-0xFFFE |    Reserved for    |                |
    |             |               |    private use     |                |
    | 65535       |     0xFFFF    |      Reserved      |     Opaque     |
    +-------------+---------------+--------------------+----------------+

1. Do we really need 16k code points for experimental use?
2. Do we really need 16k code points for private use?
    - experimental use and private use are quite similar, it seems to be
      overkill to allocate 32k code points for very similar purposes
3. IETF review is intended for RFCs, RFC 8126 says:


"4.8.  IETF Review

    (Formerly called "IETF Consensus" in the first edition of this
    document.)  With the IETF Review policy, new values are assigned only
    through RFCs in the IETF Stream -- those that have been shepherded
    through the IESG as AD-Sponsored or IETF working group documents
    [RFC2026] [RFC5378], have gone through IETF Last Call, and have been
    approved by the IESG as having IETF consensus.

    The intent is that the document and proposed assignment will be
    reviewed by the IETF community (including appropriate IETF working
    groups, directorates, and other experts) and by the IESG, to ensure
    that the proposed assignment will not negatively affect
    interoperability or otherwise extend IETF protocols in an
    inappropriate or damaging manner.

    Unless otherwise specified, any type of RFC is sufficient (currently
    Standards Track, BCP, Informational, Experimental, or Historic)."

It seems like this document is, in this context, to add IDs to this set
of documents. Since IETF review means IESG review, I don't see that
happen unless you are prepared to go ahead and publish an RFC.

It would be possible to describe a new registration procedure called
"Draft Specifications", but there is no such description in the
document. It should be carefully described, it is not clear if any
ID (e.g. Individual) sufficient or if this for wg documents only.

4. For what does "Opaque" for the Reserved value (65535) mean?

/Loa



On 2019-03-04 17:53, Satoru Matsushima wrote:
> Hi Spring,
> 
> It’s my pleasure that we can finally announce our successful SRv6 deployment. I think that the experience and knowledge from the project contributed to the maturity of SRv6 network programming I-D.
> 
> I hope that it helps the I-D to be adopted as a WG doc, and it also contributes to progress the discussion in Spring.
> 
> Best regards,
> --satoru
> 
> 
>> 2019/03/03 19:30、Clarence Filsfils (cfilsfil) <[e-mail]>のメール:
>>
>> Dear Spring,
>>
>> Softbank and Cisco have announced the deployment of SRv6:
>>
>> https://newsroom.cisco.com/press-release-content?type=webcontent&articleId=1969030
>>
>> Another deployment is ongoing and several others are in preparation.
>>
>> All these design and deployments extensively leverage the mature content of the SRv6 network programmability document and its various implementations:
>>
>> .. Cisco: 4 different hardware and 3 OS
>> .. Linux: Kernal and srext module
>> .. FD.io: VPP
>> .. Apps: Snort, Wireshark, tcpdump, iptables and nftables
>> .. Other vendor as previously reported on the list
>>
>> Multiple interoperable verifications took place.
>>
>> The maturity of the draft since March 2017 coupled with the large number of implementations, their interoperability and their concrete deployment on several networks indicate that the drafts are ready for adoption by the working group.
>>
>> Cheers,
>> Clarence Filsfils
>>
>>
>> On 01-03-19 04:30, Lizhenbin wrote:
>>> SRv6 network programming is an important work for the network evolution. After refining many times the draft is already stable.
>>> Besides the implementation and inter-op test info proposed, this week it was published that there was already the commercial deployment of SRv6.
>>> Hope the draft can be adopted by the working group as the co-author.
>>> Best Regards,
>>> Zhenbin (Robin)
>>> *From:*spring [mailto:[e-mail]] *On Behalf Of *Pablo Camarillo (pcamaril)
>>> *Sent:* Thursday, February 14, 2019 4:56 PM
>>> *To:* [e-mail]
>>> *Subject:* [spring] draft-filsfils-spring-srv6-network-programming
>>> Dear Spring,
>>> We have submitted a new revision of draft-filsfils-spring-srv6-network-programming. There are several minor updates to the document, mainly addressing ICMP and having better alignment with SRH draft. Also, based on WG feedback, we have split the document moving the illustrations into a new informational draft.
>>> As always, any feedback or question is more than welcome.
>>> https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-network-programming/
>>> https://datatracker.ietf.org/doc/draft-filsfils-spring-srv6-net-pgm-illustration/
>>> We believe that the content of both drafts is mature and has been stable since the first revision in March 2017. We are tracking several opensource and vendor proprietary implementations. Some of these have actually participated in a public interop more than a year ago.
>>> For these reasons we believe that both documents are ready to progress and be adopted by the working group.
>>> Thanks,
>>> Pablo (on behalf of authors&contributors)
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
> 
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]