Loa,
Precisely one of the reasons why we asked for WG adoption is to start early
allocations since multiple deployments exists and additional deployments are
ongoing. Let’s discuss more f2f at the IETF104 about the registry.
Thanks,
Pablo.
On 04/03/2019, 14:01, "Loa Andersson" <l...@pi.nu> wrote:
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) <cfils...@cisco.com>のメール:
>>
>> 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:spring-boun...@ietf.org] *On Behalf Of *Pablo
Camarillo (pcamaril)
>>> *Sent:* Thursday, February 14, 2019 4:56 PM
>>> *To:* spring@ietf.org
>>> *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
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
--
Loa Andersson email: l...@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
