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

From: "Clarence Filsfils (cfilsfil)" <[email-masked]>
Date: Sun, 3 Mar 2019 11:30:56 +0100

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:[email-masked]] *On Behalf Of *Pablo 
> Camarillo (pcamaril)
> *Sent:* Thursday, February 14, 2019 4:56 PM
> *To:* [email-masked]
> *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)
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 4 Mar 2019 18:53:25 +0900

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) <[email-masked]>のメール:
> 
> Dear Spring,
> 
> 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
> 
> 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
> 
> 
>> 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.
>> *From:*spring [mailto:[email-masked]] *On Behalf Of *Pablo Camarillo (pcamaril)
>> 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.
>> 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,
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Loa Andersson <[email-masked]>
Date: Mon, 4 Mar 2019 21:00:51 +0800

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 6 Mar 2019 09:27:23 +0000

Hi Cheng,

Thanks for the support. In reply to your questions:
1.- Alignment with the latest SRH draft.
2.- The End, End.X or End.T behaviors cannot be the last SID of the SID list unless combined with the USD flavor (or USP) in which case they can be the last SID. I will review the text and make the editorial changes if needed to make sure this is clear (your last sentence).

Thanks,
Pablo.

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wednesday, 27 February 2019 at 09:31
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Lizhenbin <[email-masked]>
Subject: RE: draft-filsfils-spring-srv6-network-programming

Support.  The content of these drafts has been stable for a while, I think they are ready to progress.

I have some comments regarding to PSP, USP and USD flavors in draft-filsfils-spring-srv6-network-programming-07.

1:            What is the motivation for introducing the USD flavor?  With USD, then the END, END.T and END.X can be the last SID?

2:            In section-4.1<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-06#section-4.1> , 4.2 and 4.3, the document says that End, End.X, End.T can not be the last SID of SID list.

                But in section-4.21.2<https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-06#section-4.21.2>, the End, End.X, and End.T can be the last SID when there is another SRH following.

                Even, in that case, the last SID of the SID list MUST be SID of End, End.X, and End.T, correct?

                If End, End.X, End.T can not be the last SID of SID list, then USP of End, End.X, End.T can not work.

So I think the text should be: End, End.X, and End.T SID can be the last SID if (1) it has USD flavor or (2) it has USP flavor while there is another SRH following it.

Thanks,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, February 14, 2019 4:56 PM
To: [email-masked]
Subject: [spring] draft-filsfils-spring-srv6-network-programming

Dear Spring,

Thanks,

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 6 Mar 2019 09:32:27 +0000

Hi Pablo,

Great!!  Thank you for solving my confusion. It confuses me a long time.

It is very happy to know I am correct.  Haha.

Thanks,
Cheng

From: Pablo Camarillo (pcamaril) [mailto:[email-masked]]
Sent: Wednesday, March 06, 2019 5:27 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: [email-masked]; Lizhenbin <[email-masked]>
Subject: Re: draft-filsfils-spring-srv6-network-programming

Hi Cheng,

Thanks,
Pablo.

From: "Chengli (Cheng Li)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 27 February 2019 at 09:31
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Lizhenbin <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-filsfils-spring-srv6-network-programming

Thanks,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, February 14, 2019 4:56 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] draft-filsfils-spring-srv6-network-programming

Dear Spring,

Thanks,

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 8 Mar 2019 08:58:35 +0000

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" <[email-masked]> wrote:

    Satoru and Clarence,

    Congrat's!

    
    
    1. Do we really need

    "4.8.  IETF Review

    

    
    
    /Loa

    
    --