Subject: [spring] WGLC - draft-ietf-spring-srv6-network-programming

From: <[email-masked]>
Date: Thu, 5 Dec 2019 17:15:26 +0000

Hello SPRING,

This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].

Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 5 Dec 2019 17:50:04 +0000

Hi authors,

As an individual contributor, please find below some comments.

Ø    S03.      Send an ICMP Parameter Problem message to the Source Address
               Code TBD-SRH (SR Upper-layer Header Error),

If TBD-SRH is defined in another document, please reference it in this text and add a normative reference.
Otherwise, please add this in the IANA consideration section of this document.
--
As a general comment, I find that there is a lack of normative keywords. Please check for "should", "cannot", "can", "can't", shouldn't", "should not"... and please consider using normative keyworks.

e.g.,
"an End SID cannot be the last SID of a SID list and cannot be the DA of a packet without an SRH"
What about using "MUST NOT"?

"Hence the Upper-layer header should never be processed."
What about using "MUST NOT"?

"any function can be attached to a local SID:"

MAY?

"The End.DX6 SID must be the last segment in a SR Policy"

MUST?

"the following must be done."

MUST?

"Any SID instance of the End.DX2V behavior must be associated with an L2 Table T. »

MUST?

....

---
§IANA consideration section

-          Do we need such large pools for both experimental and private use?

-          Do we need both an experimental and private pool?

-          Given that the range of code point is large and that we probably want to foster innovation use without requiring heavy IETF process, I would suggest having a FCFS range https://tools.ietf.org/html/rfc8126#section-4.4

-

   When code points are set aside for Experimental Use, it's important
   to make clear any expected restrictions on experimental scope.  For
   example, say whether it's acceptable to run experiments using those
  code points over the open Internet or whether such experiments should
   be confined to more closed environments.  See [RFC6994<https://tools.ietf.org/html/rfc6994>] for an
   example of such considerations.

https://tools.ietf.org/html/rfc8126#section-4.2

---
§IANA consideration section

"documents should clearly identify the registry into which each value is to be registered."
https://tools.ietf.org/html/rfc8126#section-3
---

Nits:
"Push a the MPLS label stack"
:s/a the/the

Thank you,
Regards,
--Bruno

From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 5, 2019 6:15 PM
To: 'SPRING WG List'
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 5 Dec 2019 21:14:06 +0000

< Responding to the right email this time >

Bruno,

Please record the following as last call comments:

- https://mailarchive.ietf.org/arch/msg/spring/MQLQNTzdkfHNbpwP99FV8UqUofY

- https://mailarchive.ietf.org/arch/msg/spring/trugWEW3n7Ubz7oayYwo6Qe_lGg

- https://mailarchive.ietf.org/arch/msg/spring/wCcVWXqbjwZW9-pJmYgZ1gC8Xrk

- https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E

                                                   Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, December 5, 2019 12:15 PM
To: 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05__;!8WoA6RjC81c!WtdxYG2xSF_q2rpWnOYGhgrGW8yw7jzvLa8EiJUeP05yi3TdBSyI35n-pjc7gafR$>

Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 6 Dec 2019 09:14:54 +0800

Hello Bruno and all,

I don't think the issues discussed again and again in the earlier iterations have been addressed in this version to be WGLCed.

Thanks for Durren's recap as follows.
[2019-09-06] https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o
[2019-09-27] https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo
[2019-10-14] https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c
[2019-10-21] https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI
[2019-12-04] https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E

And Ron's recap as follows.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: [email-masked]
Date: 2019-12-06 01:15
To: 'SPRING WG List'
CC: [email-masked]; draft-ietf-spring-srv6-network-programming
Subject: WGLC - draft-ietf-spring-srv6-network-programming
Hello SPRING, This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1]. Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20. You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics. If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions) Thank you,Bruno [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

---

From: Andrew Alston <[email-masked]>
Date: Fri, 6 Dec 2019 08:15:51 +0000

In addition to the below,

In Section 2:

In this version of the document, we assume that there are no other
   extension headers than the SRH.  These will be lifted in future
   versions of the document.

If the document is going to last call – what future versions and are plans to lift these restrictions going to come to fruition before this goes to last call or in separate rfc’s that update this document?  This is of concern because it assumes that there is no hop-by-hop option header, no fragment header, no ESP header, no AH header, no MH header etc etc.  Effectively making the use of this incompatible with things explicitly defined in section 4 of RFC8200, and which may run foul of the working group charter which states that SPRING should be avoiding making changes which define things incompatible with existing deployments.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, 6 December 2019 04:15
To: [email-masked]; [email-masked]
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Hello Bruno and all,

Thanks for Durren's recap as follows.
[2019-09-06] https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o<https://mailarchive.ietf.org/arch/msg/spring/7zMgIwEY9AipZCCGO9KnT2CGH3o>
[2019-09-27] https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo<https://mailarchive.ietf.org/arch/msg/spring/4_Slu3kkHwduZZPFJJmRUkmoTVo>
[2019-10-14] https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c<https://mailarchive.ietf.org/arch/msg/spring/u536YH4tv7kKRq_b9_x9gBYpO9c>
[2019-10-21] https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI<https://mailarchive.ietf.org/arch/msg/spring/4pikRli_HSECun9AbwfpmOF5KLI>
[2019-12-04] https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E<https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E>

And Ron's recap as follows.
- https://mailarchive.ietf.org/arch/msg/spring/MQLQNTzdkfHNbpwP99FV8UqUofY<https://mailarchive.ietf.org/arch/msg/spring/MQLQNTzdkfHNbpwP99FV8UqUofY>
- https://mailarchive.ietf.org/arch/msg/spring/trugWEW3n7Ubz7oayYwo6Qe_lGg<https://mailarchive.ietf.org/arch/msg/spring/trugWEW3n7Ubz7oayYwo6Qe_lGg>
- https://mailarchive.ietf.org/arch/msg/spring/wCcVWXqbjwZW9-pJmYgZ1gC8Xrk<https://mailarchive.ietf.org/arch/msg/spring/wCcVWXqbjwZW9-pJmYgZ1gC8Xrk>
- https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E<https://mailarchive.ietf.org/arch/msg/spring/oDWLbRDqKCaF5Xa-QvKY6mk_D5E>

Best Regards,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]>
Date: 2019-12-06 01:15
To: 'SPRING WG List'<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming<mailto:[email-masked]>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

[1] https://tools.ietf..org/html/draft-ietf-spring-srv6-network-programming-05<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05>

Thank you.

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2019 16:14:48 +0100

Hi,

> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

I think there are plenty of already documented reasons that this draft should have never been thrown into WGLC in the first place.

Therefore I do not consent.
Sander

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Dec 2019 15:55:52 -0000

Hi,

Thanks to the authors for the work on this draft. I've done a review

which is the first time I have looked at the draft for several

revisions.  My thoughts are included below.

I think that considerable editorial work is needed before we can claim

that this document is ready for publication.

Thanks,

Adrian

===

It would be really good if authors ran idnits before presenting drafts

as ready for WG last call. It is pretty easy to do, and fixing the

issues is not at all hard.

https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft
-ietf-spring-srv6-network-programming-05.txt

I think the most obvious thing that the tool points out is the absence

of a Security Considerations section. While section 7 is obviously

relevant, there would seem to be a significant piece of work that is

needed before the draft can progress.

---

Another 'normal' thing to do is check that the draft follows the

editorial guidelines from the RFC Editor. Most notable is that the

Requirements Language text should be moved into section 2.1.

---

It would be good if you could put all section headers into title case.

---

There are a lot of abbreviations in the document that are not deemed

well-known by the RFC Editor and should be expanded on first use.

'SRv6' is not (yet) a well-known abbreviation according to the RFC

Editor, so should be spelled out in the title, abstract, and on first

use in the main body of text.

---

The Abstract is a little terse. In particular, it should give an

overview of what 'network programming' is.

The Introduction says:

   This document defines the SRv6 Network Programming concept and aims

   at standardizing the main segment routing behaviors to enable the

   creation of interoperable overlays with underlay optimization and

   service programming.

Some of that text would be good in the Abstract.

--

Section 1

The first mention of 'Segment Routing' needs a reference.

---

Section 1

   moving forward in the segment list to any complex user-defined

   behavior.

Is there a comma missing?

---

Section 1

s/The network programming consists/Network programming consists/

---

Section 1

   This document defines the SRv6 Network Programming concept and aims

   at standardizing the main segment routing behaviors to enable the

   creation of interoperable overlays with underlay optimization and

   service programming.

The document 'aims', but does it succeed? :-)

I think you should use...

s/aims at standardizing/specifies/

---

Section 2

   We assume that the SRH may

   be present multiple times inside each packet.

It is good that you state this assumption for this draft.

But clearly this is not normative for defining whether the SRH is 

allowed to be present more than once.

I went to draft-ietf-6man-segment-routing-header to try to find a 

definitive statement and could not find one (perhaps I missed it?).

Failing that, 8200 is normative and it says:

   Each extension header should occur at most once, except for the

   Destination Options header, which should occur at most twice (once

   before a Routing header and once before the upper-layer header).

That means that your assumption:

- is necessary for this document to work

- is not a valid assumption.

Clearly that is not good and not what you want to end up with.

I think the solution is a fix to draft-ietf-6man-segment-routing-header

either by pulling it back from the RFC Editor Queue to make and agree

the change, or by writing a small bis to that draft to define and allow

multiple presence. (That bis would be a normative reference from this

draft.)

I suppose it could be possible to have this draft update draft-ietf-

6man-segment-routing-header, but that is probably not ideal and would

cause some inter-WG tensions.

One way of the other, it's an easy fix, but the bottom line of this

issue as things stand is that the assumption is false and blocks this

draft.

---

Section 2

   When a packet is intercepted on a wire, it is possible that SRH[SL]

   is different from the DA.

It is fairly obvious what this means, but you have introduced notation

without definition.

Perhaps insert some to text so that you end up with:

   SRH[n] indicates the nth one-based entry in the SID list as 

   represented in the SRH.  Thus, SRH[1] is SR3 in the example above.

   When a packet is intercepted on a wire, it is possible that SRH[SL]

   is different from the DA.

---

Section 3

   As introduced in RFC8402 an SRv6 Segment Identifier is a 128-bit

   value.

Of course, it is true that an SRv6 SID is 128-bits, and this follows 

from what is said in 8402, but it is not what 8402 says.  I suggest you

replace this text with:

   RFC8402 defines an SRv6 Segment Identifier as an IPv6 address 

   explicitly associated with the segment.  Thus, an SRv6 Segment

   Identifier is a 128-bit value.

---

3.1

   The FUNCT value zero is invalid.

That's reasonable, but I couldn't find out what happens if I set a 

zero FUNCT. Where is that described?

(Pedantically, but I don't expect a fix, if L is 128, I think FUNCT

zero may be OK.)

---

3.1

   A behavior may require additional arguments that would be placed

   immediately after the FUNCT.  In such case, the SRv6 SID will have

   the form LOC:FUNCT:ARGS::. For this reason, the SRv6 SIDs are matched

   on a per longest-prefix-match basis.

This is clear, but it conflicts with the definition of FUNCT given

earlier:

   FUNCT (function) is the 128-L least significant bits of the SID.

I would suggest that you reverse some of the text so that you start

with LOC:FUNCT:ARGS:: then describe how the split between LOC and FUNCT

is found (i.e., L), and then explain that ARGS might not always be

needed in which case FUNCT uses all of the 128-L bits.

---

I think you could usefully spend some time describing the classes of

behaviors. Notably "End behaviors" and "Transit behaviors". This would

go as a new section before section 4.

You can describe how/where in the network the behaviors are executed,

and you can describe whether the behaviors are bound to specific SIDs

(SID types) or not.

The, probably, rename section 4 to "End behaviors" which keeps it 

aligned with the name of section 5.

---

4.

This is the only place you use "Adj SID" in the document. Either spell

it out, or mention it in Section 2.

Please spell out "decaps" on each use.

---

4.1

   As a consequence, an End SID cannot be the last

   SID of a SID list and cannot be the DA of a packet without an SRH

   (unless combined with the PSP, USP or USD flavors Section 4.16).

I think you mean s/cannot/MUST NOT/

The point is that I *can* place anything in a SID list, I just can't

expect it to work.

In fact, you should catch this in the pseudo code by testing Segments

Left > 1.

---

4.1

"TBD-SRH" is mentioned many times in this document with the first time

being in this section.

I don't find this described in Section 9.

---

4.1

  S03.      Send an ICMP Parameter Problem message to the Source Address

               Pointer set to the offset of the upper-layer header,

               interrupt packet processing and discard the packet

Ambiguous punctuation. Probably...

  S03.      Send an ICMP Parameter Problem message to the Source Address

               Pointer set to the offset of the upper-layer header.

            Interrupt packet processing and discard the packet

Similarly:

  S06.      Send an ICMP Time Exceeded message to the Source Address,

               Code 0 (Hop limit exceeded in transit).

            Interrupt packet processing and discard the packet

And:

  S10.      Send an ICMP Parameter Problem to the Source Address,

               Code 0 (Erroneous header field encountered),

               Pointer set to the Segments Left field.

            Interrupt packet processing and discard the packet

There are examples of this all through Section 4.

---

4.1

I was surprised by...

  S01. When an SRH is processed {

  S02.   If (Segments Left == 0) {

  S03.      Send an ICMP Parameter Problem message to the Source Address

               Pointer set to the offset of the upper-layer header,

               interrupt packet processing and discard the packet

  S04.   }

  S05.   If (IPv6 Hop Limit <= 1) {

  S06.      Send an ICMP Time Exceeded message to the Source Address,

               Code 0 (Hop limit exceeded in transit),

               interrupt packet processing and discard the packet

  S07.   }

Are you sure that Hop Limit processing is left so late? Isn't it one of

the first things done with a packet before even the SRH is discovered to

be present?

---

4.1 (and other sections)

I spent rather too much time trying to work out

  S08.   max_LE = (Hdr Ext Len / 2) - 1

  S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {

As far as I can see, for an SRH,

   Hdr Ext Len = 7 + (16 * (Last Entry + 1) ) + sum(all TLV lengths)

So, while I see that you want to check that Last Entry doesn't point out

beyond the end of the SRH, I don't see how your computation of max_LE 

helps.

What have I missed?

---

4.2

s/with a set of J of/with a set, J, of/

Maybe

   S15.   Set the packet's egress adjacency to J

would read better as

   S15.   Set the packet's egress adjacency to a member of J

---

4.2

   Note that the End.X SID cannot be the last SID of a SID list and

   cannot be the DA of a packet without an SRH (unless combined with the

   PSP, USP or USD flavors Section 4.16).  Hence the Upper-layer header

   should never be processed.

Similar cannot/MUST NOT issue as in 4.1.

The pseudocode fix in 4.1 would cover this point.

---

4.3

   The End.T behavior is used for multi-table operation in the core.

   For this reason, an instance of the End.T behavior must be associated

   with an IPv6 FIB table T.

Is this "MUST BE" or "is"?

   Error code "SR Upper-layer Header Error", Pointer set to the

   offset of the upper-layer header.

You should call out "TBD-SRH" as the error code value. (Happens in 

several sections.)

And (again)...

   Note that the End.T SID cannot be the last SID of a SID list and

   cannot be the DA of a packet without an SRH (unless combined with the

   PSP, USP or USD flavors Section 4.16).  Hence the Upper-layer header

   should never be processed.

Similar cannot/MUST NOT issue as in 4.1.

The pseudocode fix in 4.1 would cover this point.

---

4.4

   The End.DX6 SID must be the last segment in a SR Policy, and it must

   be associated with one or more L3 IPv6 adjacencies J.

Again: is that "MUST" or "is"?

Fix to 

   S03.      Send an ICMP Parameter Problem to the Source Address,

                Code 0 (Erroneous header field encountered),

                Pointer set to the Segments Left field.

             Interrupt packet processing and discard the packet

and

   S02.    Send an ICMP Parameter Problem message to the Source Address

              Pointer set to the offset of the upper-layer header.

           Interrupt packet processing and discard the packet

I wondered why you had two code fragments rather than a longer one with

an "If" statement and two branches. Doesn't really matter, however, as a

result of the current structure, the Notes that follow are a little 

ambiguous because you have two instances of S01 and S05 in the section.

---

4.5

Identical comments to 4.4

---

4.6

   This would be equivalent to the per-VRF VPN label in

   MPLS [RFC4364].

s/would be/is/

   The End.DT6 SID must be the last segment in a SR Policy, and a SID

   instance must be associated with an IPv6 FIB table T.

Again: is that "MUST" or "is"?

---

4.7 and 4.8

Identical comments to 4.6

---

4.9

   The End.DX2 SID must be the last segment in a SR Policy, and it must

   be associated with one outgoing interface I.

Again: is that "MUST" or "is"?

This section brings back the ambiguity in the Notes.

---

4.10

   Any SID

   instance of the End.DX2V behavior must be associated with an L2

   Table T.

Again: is that "MUST" or "is"?

---

4.11

s/unicast . Any/unicast.  Any/

   Any SID instance of the End.DT2U behavior must be

   associated with an L2 Table T.

Again: is that "MUST" or "is"?

Usual issue with

   S02.    Send an ICMP Parameter Problem message to the Source Address

              Pointer set to the offset of the upper-layer header,

              interrupt packet processing and discard the packet

L2OIF is a new (unknown) term (in 4.12 you use "L2 OIF")

s/control plane/the control plane/

---

4.12

   Any SID instance of this behavior must be associated with a L2 table

   T.  Additionally the behavior may take an argument: "Arg.FE2".  It is

   an argument specific to EVPN ESI filtering and EVPN-ETREE used to

   exclude specific OIF (or set of OIFs) from L2 table T flooding.

Again: is that "MUST" or "is"?

Possibly s/may/MAY/

Where arguments are optional, I don't think you have made it clear what 

you do if no argument is supplied. I would presume you set the ARG bits

to zero, but I am not clear whether zero could be interpreted as a 

valid argument.

   S06. Forward via all L2 OIFs excluding the one specified in Arg.F2

Earlier you called it Arg.FE2

---

4.13

   An End.B6.Encaps SID is never the last segment in a SID list.  Any

   SID instantiation must be associated with an SR Policy

   B[I-D.ietf-spring-segment-routing-policy] and a source address A.

Again: is that "MUST" or "is"?

s/B[I-D/B [I-D/

This makes [I-D.ietf-spring-segment-routing-policy] a normative

reference.

---

4.13

Step 13 is

  S13.   Decrement Segments Left by 1

and the associated note is

   S13.  The SRH MAY be omitted when the SRv6 Policy B only contains one

Should the note be for S14?

Similarly, should the S16 note be for S17?

---

4.14

   In this way, the

   first segment is only introduced in the DA and the packet is

   forwarded according to it.

I believe this sentence could be written more clearly. I tried to offer

a suggestion, but discovered that I couldn't reliably guess what the 

intention is.

---

4.15

   An End.BM SID is never the last SID, and any SID instantiation must

   be associated with an SR-MPLS Policy

   B[I-D.ietf-spring-segment-routing-policy].

Again: is that "MUST" or "is"?

s/B[I-D/B [I-D/

---

4.15

  S14.   Push a the MPLS label stack for B

s/a the/the/

---

4.16.1 and 4.16.2

The term "pop the SRH" is, I think, a new concept introduced at this

point. We can deduce what it means, but not be certain that we will

do the right thing.

You need to add text to clearly define the meaning.

Furthermore (and I'm willing to bet someone ese has mentioned this!)

the PSP concept appears to move the ability to remove an SRH from

the domain border to inside the domain. I wonder whether that is 

actually allowed. I also wonder how the rest of the network knows

whether the PSP function is available at a specific node.

You might want to recast PSP if its purpose is to handle "end" nodes

that are not SRH capable. To do this you would recast the node that you

have called the PSPS node as the edge of the domain (the end node) and

set the action as "Pop and go".

---

5.1

   As per [RFC8200], if a node N receives a packet (A, S2)(S3, S2, S1;

   SL=1) and S2 is neither a local address nor a local SID of N then N

   forwards the packet without inspecting the SRH.

8200 can't possibly say this because 8200 doesn't know about SIDs.

Possibly you just want to change the reference to 8402.

---

5.1

   This means that N treats the following two packets P1 and P2 with the

   same performance:

      P1 = (A, S2)

      P2 = (A, S2)(S3, S2, S1; SL=1)

I don't think this is necessarily true since packet length and other 

things (e.g., hashing) may vary. So you either need to sharpen your

meaning of "performance" or just content yourself with "MUST NOT

examine the SRH".

---

5.1

   A transit node MUST include the outer flow label in its ECMP load-

   balancing hash [RFC6437].

I find this odd in this document. You are describing the behavior at a

node that is potentially a legacy node that is not SRH aware, yet you

are using normative language to define its behavior. You could change 

this to:

   A transit node will use the outer flow label in its ECMP load-

   balancing hash as described in [RFC6437].

Or, unless you can give a good reason to include it, you can simply

strike this paragraph.

Or, possibly, the problem comes with the text in Section 5 that says:

   We define hereafter the set of basic transit behaviors.  These

   behaviors are not bound to a SID and they correspond to source SR

   nodes or transit nodes [I-D.ietf-6man-segment-routing-header].

Perhaps it is not right that you could define a transit behavior for

a "transit node" that is not capable of processing an SRH. If you were

to fix the definition of a transit behavior to apply to "source SR 

nodes, or nodes that are capable of processing SRHs and that forward an

IPv6 packet where the destination address of that packet is not locally

configured as a segment nor a local interface." then that would fix my

concern.

There is a similar issue in 6.2

---

5.2

By definition this behavior only applies at source nodes per 8402. In

other words, you are describing domain recursion according to 8402.

---

5.2

   The SRH MAY be omitted when the SRv6 Policy only contains one segment

   and there is no need to use any flag, tag or TLV.

For complete clarity...

   The push of the SRH MAY be omitted when the SRv6 Policy only contains

   one segment and there is no need to use any flag, tag or TLV.

---

5.3

Ditto both comments for 5.2

---

I don't think 5.4 or 5.5 can happen at transit nodes. The thing to be

encapsulated is an L2 frame and so is only seen at a source node.

At this point, I think only 5.1 describes a transit behavior. 5.2 to 5.5

describe source behaviors.

---

6.1

I agree with this section, but I am concerned that you are updating 

draft-ietf-6man-segment-routing-headerby adding normative language to

describe nodes that process the SRH. Does that mean you should use an

"Updates" clause in the document header?

After describing CNT-1 and CNt-2 you say...

   Furthermore, an SRv6 capable node maintains an aggregate counter

   CNT-3 tracking the IPv6 traffic that was received with a destination

   address matching a local interface address that is not a locally

   instantiated SID and the next-header is SRH with SL>0.

That looks like s/maintains/MUST maintain/ unless you have a reference

for the assertion that it does maintain CNT-3.

---

6.3

I think you have made [I-D.ietf-6man-spring-srv6-oam] a normative

reference.

---

7.

   The SRH Section 5.1 defines how a domain of trust can operate

   SRv6-based services for internal traffic while preventing any

   external traffic from accessing the internal SRv6-based services.

Probably "The SRH Section 5.1" is meant to be a reference to another 

document.

---

Section 8 has...

   The concept of "SRv6 network programming" refers to the capability

   for an application to encode any complex program as a set of

   individual functions distributed through the network.  Some functions

   relate to underlay SLA, others to overlay/tenant, others to complex

   applications residing in VM and containers.

This looks like a useful paragraph to have at the top of the document.

---

8.1

   The End, End.T and End.X SIDs express topological behaviors and hence

   are expected to be signaled in the IGP together with the flavors PSP,

   USP and USD[I-D.ietf-lsr-isis-srv6-extensions].

I think you are conflating SIDs with behaviors. Probably...

   The End, End.T, and End.X behaviors express topological behaviors and

   hence the SIDs that have these behaviors bound to them are expected

   to be signaled in the IGP together with the supported flavors (PSP,

   USP, or USD) [I-D.ietf-lsr-isis-srv6-extensions].

Likewise...

OLD

   These three SIDs provide important topological behaviors for the IGP

   to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB

   to build SR policies.

NEW

   These SIDs provide important topological behaviors for the IGP

   to build FRR/TI-LFA solution and for TE processes relying on IGP LSDB

   to build SR policies.

---

8.2

   BGP-LS is expected to be the key service discovery protocol.  Every

   node is expected to advertise via BGP-LS its SRv6 capabilities (e.g.

   how many SIDs it can insert as part of a T.Encaps behavior) and any

   locally instantiated SID [I-D.ietf-idr-bgpls-srv6-ext].

We shouldn't write text that expresses expectations about the future. It

doesn't age well in an RFC, and it is just unsubstantiated speculation.

What about...

   [I-D.ietf-idr-bgpls-srv6-ext] describes a mechanism to enable each

   node to use BGP-LS to advertise its SRv6 capabilities (e.g., how many

   SIDs it can insert as part of a T.Encaps behavior) and any locally

   instantiated SIDs.  This enables BGP-LS to be the key service

   discovery protocol.

---

8.3

OLD

   The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V,

   End.DT2U and End.DT2M SIDs are expected to be signaled in BGP

   [I-D.ietf-bess-srv6-services].

NEW

   The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V,

   End.DT2U and End.DT2M SIDs can be signaled in BGP

   [I-D.ietf-bess-srv6-services].

---

8.4

OLD

   The following table summarizes which SIDs are signaled in which

   signaling protocol.

END

   The following table summarizes which behaviors can signaled for SIDs

   in which signaling protocols.

---

8.4

   The reader should also remember that any specific instantiated SR

   policy is always assigned a Binding SID.  They should remember that

   BSIDs are advertised in BGP-LS as shown in Table 1. 

This needs a citation.

---

9.

   | 0           |     0x0000    |          Reserved         | Invalid |

   | 1-32767     | 0x0001-0x7FFF |   Specification Required  |         |

   | 32768-49151 | 0x8000-0xBFFF | Reserved for experimental |         |

   |             |               |            use            |         |

   | 49152-65534 | 0xC000-0xFFFE |  Reserved for private use |         |

   | 65535       |     0xFFFF    |          Reserved         |  Opaque |

Should use the 5226 names for the assignment policies. Hence:

   | 0           |     0x0000    |          Reserved         | Invalid |

   | 1-32767     | 0x0001-0x7FFF |   Specification Required  |         |

   | 32768-49151 | 0x8000-0xBFFF |      Experimental Use     |         |

   | 49152-65534 | 0xC000-0xFFFE |        Private use        |         |

   | 65535       |     0xFFFF    |          Reserved         |  Opaque |

---

9.

I am strongly opposed to such a large range being assigned for

experimental use.  RFC 3692 gives some guidance.  The normal idea is 

that there should be enough codepoints to allow two experiments to be

run on the same nodes without conflict, but few enough that they cannot

be used as a proxy for allocating and registering values in the 

registry.

I should think that 32 code points is enough.

---

9. 

According to 5226 "Specification Required" implies the use of a 

Designated Expert. That means that your document needs to give advice to

the DE on how to make decisions about which code points are acceptable.

---

9.

Would be nice to reformat Table 4 to avoid the line wrapping.

---

9.

In table 4 you have...

   | 13   | 0x00 | End.B6.Insert  | [I-D.filsfils-spring-srv6-net-pgm- |

   |      |  0D  |                |             insertion]             |

I think you should leave 13 as unassigned, and leave it to the other

document to request assignment.

Alternatively, you make draft-filsfils-spring-srv6-net-pgm-insertion a

normative reference and block the progress of this draft until it is

complete (which I don't think it is a very good idea).

---

12.2

As shown by idnits, you have a couple of unused references you should

delete.

---

12.2

2473, 8200, and 8402 are all clearly used as normative references.

Please move them to 12.1

From: ipv6 <[email-masked]> On Behalf Of [email-masked]
Sent: 05 December 2019 17:15
To: 'SPRING WG List' <[email-masked]>
Cc: [email-masked]; draft-ietf-spring-srv6-network-programming
<[email-masked]>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,
 
This email starts a two weeks Working Group Last Call on
draft-ietf-spring-srv6-network-programming [1].
 
Please read this document if you haven't read the most recent version, and
send your comments to the SPRING WG list, no later than December 20.
 
You may copy the 6MAN WG for IPv6 related comment, but consider not
duplicating emails on the 6MAN mailing list for the comments which are only
spring specifics.
 
If you are raising a point which you expect will be specifically debated on
the mailing list, consider using a specific email/thread for this point.
This may help avoiding that the thread become specific to this point and
that other points get forgotten (or that the thread get converted into
parallel independent discussions)
 
Thank you,
Bruno
 
[1]
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05

____________________________________________________________________________
_____________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
 
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 13:22:31 -0300

> I think there are plenty of already documented reasons that this draft should have never been thrown into WGLC in the first place.

+1

Also, as noted, I support Ron Bonica's WGLC comments.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Dec 2019 15:50:50 -0300

>    versions of the document.

Can the authors clarify what this means?

That this mean "this will not work as expected if there are other EHs"?
If not, why the statement?  If yes, what happens if you do receive
packets with other EHs (say, FH, IPsec, or others)?

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Dec 2019 02:49:51 +0000

Bruno,

Please add the following to the list of last call comments to be tracked:

  *   https://mailarchive.ietf.org/arch/msg/spring/2BvW_aGaEsOfRclrE4-ctEGbTZs
  *   https://mailarchive.ietf.org/arch/msg/spring/t8Bm_kQdV2rTlxtvYss5KPY1KlI
  *   https://mailarchive.ietf.org/arch/msg/spring/nfzSTbLy24FLOd5h-52Hfr5zEnU

                                                                            Ron

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Andrew Alston <[email-masked]>
Date: Mon, 9 Dec 2019 10:07:28 +0000

I would also appreciate it if the following two can be added to the list to be tracked:

  *   https://mailarchive.ietf.org/arch/msg/spring/TJK_us3OPM60B00Wa3fhOgDX20k
  *   https://mailarchive.ietf.org/arch/msg/spring/PH_hREAN54is2wkm5s_8rkRxOP4

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: Monday, 9 December 2019 05:50
To: [email-masked]; 'SPRING WG List' <[email-masked]>
Cc: draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Bruno,

  *   https://mailarchive.ietf.org/arch/msg/spring/2BvW_aGaEsOfRclrE4-ctEGbTZs<https://mailarchive.ietf.org/arch/msg/spring/2BvW_aGaEsOfRclrE4-ctEGbTZs>
  *   https://mailarchive.ietf.org/arch/msg/spring/t8Bm_kQdV2rTlxtvYss5KPY1KlI<https://mailarchive.ietf.org/arch/msg/spring/t8Bm_kQdV2rTlxtvYss5KPY1KlI>
  *   https://mailarchive.ietf.org/arch/msg/spring/nfzSTbLy24FLOd5h-52Hfr5zEnU<https://mailarchive.ietf.org/arch/msg/spring/nfzSTbLy24FLOd5h-52Hfr5zEnU>

                                                                            Ron

Juniper Business Use Only
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, December 5, 2019 12:15 PM
To: 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-spring-srv6-network-programming <[email-masked]<mailto:[email-masked]>>
Subject: WGLC - draft-ietf-spring-srv6-network-programming

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 9 Dec 2019 15:20:33 +0000

Andrew,

You seem to be reading an outdated version of the document.  That text (and the related restrictions) have been removed since version -02.

Please read the revision that is being last-called (-05) and let me know whether you have any comment.

Thanks,
Pablo.

From: Andrew Alston <[email-masked]>
Date: Friday, 6 December 2019 at 09:16
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Friday, 6 December 2019 at 09:16

In Section 2:

Thanks

Andrew

Hello Bruno and all,

Best Regards,
Zhenqiang Li

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Andrew Alston <[email-masked]>
Date: Mon, 9 Dec 2019 17:19:06 +0000

Thanks Pablo – mistake om my part – and for this I apologise.

So just to confirm – can you confirm that with that text removed – you seen no issues using the additional EH’s as currently defined by other RFC’s in conjunction with this technology?  I ask this because considering that statement in the draft – I’d like some confirmation that this has been considered, and it is not just a removal of a piece of text

Thanks

Andrew

From: spring <[email-masked]> on behalf of "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Monday, 9 December 2019 at 18:20
To: Andrew Alston <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Andrew,

Thanks,
Pablo.

In Section 2:

Thanks

Andrew

Hello Bruno and all,

Best Regards,
Zhenqiang Li

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Dec 2019 15:31:50 -0500

Bruno,

On 5/12/19 12:15, [email-masked] wrote:
[....]>
> Please read this document if you haven't read the most recent version,
> and send your comments to the SPRING WG list, no later than December 20.
> 
>  
> 
> duplicating emails on the 6MAN mailing list for the comments which are
> only spring specifics.
> 
>  
> 
> If you are raising a point which you expect will be specifically debated
> on the mailing list, consider using a specific email/thread for this point.
> 

Penultimate Segment Popping describes/specifies the removal of a SRH at
a place other than the final destination of the packet.

Such behavior violates RFC8200, which specifies:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

Note, of course, that the reference of "Destination Address" in RFC8200
is clearly the final destination of the packet -- for instance, RFC8200
does not specify any routing header type, and hence the meaning is
unambiguous (there's no destination other than the final destination of
the packet).

This is of course in line with IPv6 being and end-to-end protocol, and
crucial for other related mechanisms to work as expected (such as IPsec
AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.

So, in order to proceed with the document, there are multiple options
forward:

1) Just remove the corresponding text/behavior

2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,
re-encap)

3) Do the necessary standards work to update RFC8200, such that it
allows this sort of behavior, and only ship the network-programming
draft for publication when at least 6man has consensus to proceed on
that path.

P.S.: I will go through the document once again... but the same
reasoning should be applied to any EH-insertion/removal at a place other
than the source of the packet or its final destination.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Dec 2019 17:55:31 -0500

<no hats>

> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

I will happily admit that I haven't been following the discussions, so
apologies in advance - I'm guessing I'm missing something really
obvious, so please point me at other documents / email threads where
this has already been answered...

RFC5095 deprecated IPv6 RH0 due to some serious security issues - it
was possible for an attacker to send traffic containing "instructions"
to make a packet ping-pong between two interfaces, steer it down
specific links, etc.

It feels to me like this re-introduces similar (and potentially more
scary) issues -- what's to stop an attacker spoofing traffic
containing a bunch of SIDs which decapsulate, push a packet into
another FIB, End.DT2M, etc?

I went to look in the Security Considerations section, but, well, the
document doesn't seem to have one?...
The word Security appears 3 times in the document - one in the section
title ("7. Basic security for intra-domain deployment"), once in the
Index, and once simply punting the reader to Section 5.1 of the SRH
document ("Future documents will detail inter-domain security
mechanisms for
 SRv6 ").

Expecting *everyone* who deploys this to perfectly apply filters which
blocks ingress traffic everywhere where a packet could enter a domain
feels like an accident just waiting to happen
Again, I'm guessing that I'm missing something obvious, and that the
entire security isn't premised on that - please point me to where this
is addressed.

"With great power comes great responsibility"
    -- sudo, via Peter Parker.

W

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Dec 2019 14:11:03 +1300

> document doesn't seem to have one?...

So why on earth is this document in WGLC? It cannot possibly be sent to the IESG without that section. (And "7.  Basic security ..." seems very unlikely to pass muster even if renamed.)

Regards
   Brian

---

From: <[email-masked]>
Date: Tue, 10 Dec 2019 17:37:02 +0000

[-6man as I believe this is spring specific]

Hi Pablo, authors,

< The
   T.Encaps behavior would describe the capability of node N to perform
   a T.Encaps behavior, specifically it would describe how many SIDs
   could be inserted by N without significant performance degradation."

Could you please explicit what is meant by 'how many SIDs'? Especially for .Red.
Is this the number of SID in the SRH?
Because for .Red, the number of SID in the SRH is N-1, with N been the number of SIDs. (as the first SID is not included in the SRH).

Any option works for me. I'm just asking for the behavior to be clear and interoperable.

Thank you,
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: <[email-masked]>
Date: Tue, 10 Dec 2019 17:41:11 +0000

Hi Pablo, authors

"4.13.  End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps"
is clear that an IPv6 encapsulation is performed. e.g with the below text
"  S14.   Push a new IPv6 header with its own SRH containing B"

However, I find that "4.14.  End.B6.Encaps.Red: [...] with reduced SRH" is a little less clear on that. E.g.,

"This is an optimization of the End.B6.Encaps behavior."
Looks good.

"   The new SRH is created as described in Section 4.1.1 of [I-D.ietf-6man-segment-routing-header<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#ref-I-D.ietf-6man-segment-routing-header>]."
Is not that specific. Could you please explicitly add that an IPv6 outer header is added ?

"  End.B6.Encaps.RED  [...] with reduced SRH insertion SRv6 instantiation of a Binding SID"
Does not looks good.
Please remove any reference to "SRH insertion". "IPv6 encapsulation with an SRH header" would be preferred.

"     4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps  20
     4.14<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.14>. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . .  21<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-21> >

May be
OLD: End.B6.Encaps.Red: [...] with reduced SRH
NEW: End.B6.Encaps.Red: End.B6.Encaps with reduced SRH

(this does fit in a single line)

Thank you,
Best regards,
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: <[email-masked]>
Date: Tue, 10 Dec 2019 18:18:03 +0000

Fernando,

Thank you for spelling out your comment, plus on the WGLC thread.
More in-line

> is clearly the final destination of the packet -- for instance, RFC8200

I hear and can understand your reading of RFC8200.
At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".
Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.
I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.

> 1) Just remove the corresponding text/behavior

That is indeed one option. But as of today, this is not my assumption.
 
> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,

SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.
We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.
 
> draft for publication when at least 6man has consensus to proceed on

Not the preferred path as of today.
 
> than the source of the packet or its final destination.

It looks to me that SRH insertion and SRH removal are to be treated differently. The difference been that for SRH insertion, in general the node doing insertion is any node on the path hence not specifically a node ' identified in the Destination Address field of the IPv6 header." While for and End* PSP behavior, the node doing SRH removal is a node '' identified in the Destination Address field of the IPv6 header.". Or at minimum this seems a possible interpretation of RFC 8200.
In all cases, while this is sorted out, let's treat both as different.

Thank you,
--Bruno

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 18:16:13 -0500

Bruno,

> I hear and can understand your reading of RFC8200.

Could you please check RFC8200, and tell me what other possible
interpretation of "Destination Address" you might have, in the context
of RFC8200.

RFC8200 does not even specify any routing header types. SO...where's the
ambiguity?

> At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".

No, I argue that there is not. IN fact, I argue that folks have been
following that strategy for way too long, and that's quite frustrating.

> Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.

The quoted text is from RFC8200. In the context of RFC8200 the
Destination Address can only contain the ultimate destination of the
packet. Where's the ambiguity?

And let me ask you, as chair, another question, that will lead you to
the same place: is IPv6 and end to end protocol?

The fact that I may claim that RFC8200 contains a receipe for BBQ does
not actually mean that that's the case.

> I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.

For the record, I think this is a major issue that should be cleared
before it can be claimed that there is consensus to request publication
of this document.

> We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a w…

It's about SRH removal, which is also forbiden by RFC8200.

> Not the preferred path as of today.

Yes, it should be evident that it seems the preferred path has been
(starting with EH insertion at the time) to circumvent existing
specifications.

> It looks to me that SRH insertion and SRH removal are to be treated differently. 

I don't see how or why. Both violate the same requirement in RFC8200.

Thanks,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Dec 2019 19:49:07 -0500

Fernando, I really wish I could agree with you.
But I can't.

In 8200, it is clear that the meaning fo "Destination Address" for an 
IPv6 packet is the value placed in the IPv6 destination address field. 
the fact that if we had looked ahead we might have said something 
different does not change what words we chose to use.  If I am going to 
insist (as I have in other contexts) that other folks live with the 
words we compromised on in 8200, then I have to live myself with the 
words we compromised on in 8200.

I have concerns about whether PSP is a good design.  I am trying to 
write a useful note on the topic.  (And without such a note, I can not 
expect anyone to care about thoughts in my head.)   But I can not and 
will not claim that PSP violates RFC 8200.

Yours,
Joel

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Dec 2019 19:51:36 -0500

> before it can be claimed that there is consensus to request publication

[ .. and once again / still with no hats ]

I'd suggest that *everyone* read RFC7282 - "On Consensus and Humming
in the IETF" - being a Pete Resnick document, it is clear, concise and
a pleasant read.

Unfortunately it's also descriptive, rather than prescriptive, and so
people may take away different things from it, but it's *still* a
useful read...

W

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Dec 2019 01:55:32 +0100

Bravo Joel !

On Wed, Dec 11, 2019 at 1:49 AM Joel M. Halpern <[email-masked]> wrote:

> >> At minimum, I think that we can agree that there is another reading, as
> expressed by other WG participants, and hence I disagree with "of course".
> >
> >> Personally, I understand "Destination Address" as "Destination Address
> field of the IPv6 header." as indicated explicitly in the text quoted.
> >
> >> I'm fine with having this clarified with 6MAND chairs and AD. That been
> said, the Internet AD would have an opportunity to DISCUSS this.
> >
> >>> AH). Please also check:
> draft-smith-6man-in-flight-eh-insertion-harmful.
> >>>
> >> We are talking SRH removal. I'm assuming that you are referring to PSP.
> My understanding is that this function (PSP) is to distribute the
> (forwarding plane) load between the PSP and the USP. In a way similar to
> MPLS PHP. But in all cases, this is not about SRH insertion.
> >
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 11 Dec 2019 01:07:08 +0000

+1
Kindly remind that, there are ‘final destination’ wording 5 times in RFC8200. The 8200 is aware of difference of ‘destination’ and ‘final destination’.

         Line 375:       note 3: for options to be processed only by the final destination
         Line 443:    packet's final destination.  When an Authentication header is present
         Line 576:                           before reaching the final destination.
         Line 650:    present, the Destination Address of concern is that of the final
         Line 838:          The Fragment header is not present in the final, reassembled
         Line 1130:          Address used in the pseudo-header is that of the final

Thanks
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, December 11, 2019 8:56 AM
To: Joel M. Halpern <[email-masked]>
Cc: Fernando Gont <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Bravo Joel !

On Wed, Dec 11, 2019 at 1:49 AM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
Fernando, I really wish I could agree with you.
But I can't.

Yours,
Joel

On 12/10/2019 6:16 PM, Fernando Gont wrote:
> Bruno,
>
> On 10/12/19 13:18, [email-masked]<mailto:[email-masked]> wrote:
>> Fernando,
>>
>>> On 5/12/19 12:15, [email-masked]<mailto:[email-masked]> wrote:
>>> [....]>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Tom Herbert <[email-masked]>
Date: Tue, 10 Dec 2019 17:43:51 -0800

> words we compromised on in 8200.
Joel,

That might be the wording, but don't believe that was the intent. The
real intent is revealed by some of the earlier text that said
(draft-ietf-6man-rfc2460bis-07):

"The insertion of Extension Headers by any node other than the source
of the packet breaks PMTU-discovery and can result in ICMP error
messages being sent to the source of the packet that did not insert
the header."

That is true, and breaking ICMP is an issue that has been raised
repeatedly. It also breaks AH as pointed out. Furthermore, if RFC8200
allows SRH insertion to occur, then we'd have to accept that it allows
ANY type EH insertion (except maybe fragmentation?) to occur at any
destination address! Not only that, we also need to accept that this
would allow NAT devices to insert EH when the destination address is
the NAT address.

So the possibility that destination address wasn't spelled out as
being final destination seems to be an unfortunate omission, but even
so, that omission doesn't somehow magically make EH insertion robust
or mitigate the problems of EH insertion that have already been
discussed. Neither does it provide the rationale why encapsulation
with the EH can't be used instead which is clearly the option that
most closely adheres to the Robustness principle.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 10 Dec 2019 21:18:52 -0500

Tom, I was and am commenting on OSP.  Header insertion is a separate, lo8sely related, topic.I think it is quite important that we use the words we ended up with, both when they support what we want and when they do not.Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Tom Herbert <[email-masked]> Date: 12/10/19  20:44  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]> Cc: Fernando Gont <[email-masked]>, SPRING WG List <[email-masked]>, [email-masked] Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming On Tue, Dec 10, 2019 at 4:49 PM Joel M. Halpern <[email-masked]> wrote:>> Fernando, I really wish I could agree with you.> But I can't.>> In 8200, it is clear that the meaning fo "Destination Address" for an> IPv6 packet is the value placed in the IPv6 destination address field.> the fact that if we had looked ahead we might have said something> different does not change what words we chose to use.  If I am going to> insist (as I have in other contexts) that other folks live with the> words we compromised on in 8200, then I have to live myself with the> words we compromised on in 8200.>Joel,That might be the wording, but don't believe that was the intent. Thereal intent is revealed by some of the earlier text that said(draft-ietf-6man-rfc2460bis-07):"The insertion of Extension Headers by any node other than the sourceof the packet breaks PMTU-discovery and can result in ICMP errormessages being sent to the source of the packet that did not insertthe header."That is true, and breaking ICMP is an issue that has been raisedrepeatedly. It also breaks AH as pointed out. Furthermore, if RFC8200allows SRH insertion to occur, then we'd have to accept that it allowsANY type EH insertion (except maybe fragmentation?) to occur at anydestination address! Not only that, we also need to accept that thiswould allow NAT devices to insert EH when the destination address isthe NAT address.So the possibility that destination address wasn't spelled out asbeing final destination seems to be an unfortunate omission, but evenso, that omission doesn't somehow magically make EH insertion robustor mitigate the problems of EH insertion that have already beendiscussed. Neither does it provide the rationale why encapsulationwith the EH can't be used instead which is clearly the option thatmost closely adheres to the Robustness principle.Tom> I have concerns about whether PSP is a good design.  I am trying to> write a useful note on the topic.  (And without such a note, I can not> expect anyone to care about thoughts in my head.)   But I can not and> will not claim that PSP violates RFC 8200.>> Yours,> Joel>> On 12/10/2019 6:16 PM, Fernando Gont wrote:> > Bruno,> >> > On 10/12/19 13:18, [email-masked] wrote:> >> Fernando,> >>> >> Thank you for spelling out your comment, plus on the WGLC thread.> >> More in-line> >>> >>> Bruno,> >>>> >>> On 5/12/19 12:15, [email-masked] wrote:> >>> [....]>> >>>> This email starts a two weeks Working Group Last Call on> >>>> draft-ietf-spring-srv6-network-programming [1].> >>>>> >>>>> >>>>> >>>> Please read this document if you haven't read the most recent version,> >>>> and send your comments to the SPRING WG list, no later than December 20.> >>>>> >>>>> >>>>> >>>> You may copy the 6MAN WG for IPv6 related comment, but consider not> >>>> duplicating emails on the 6MAN mailing list for the comments which are> >>>> only spring specifics.> >>>>> >>>>> >>>>> >>>> If you are raising a point which you expect will be specifically debated> >>>> on the mailing list, consider using a specific email/thread for this point.> >>>>> >>>> This may help avoiding that the thread become specific to this point and> >>>> that other points get forgotten (or that the thread get converted into> >>>> parallel independent discussions)> >>>> >>> Penultimate Segment Popping describes/specifies the removal of a SRH at> >>> a place other than the final destination of the packet.> >>>> >>> Such behavior violates RFC8200, which specifies:> >>>> >>     > Extension headers (except for the Hop-by-Hop Options header) are not> >>     > processed, inserted, or deleted by any node along a packet's delivery> >>     > path, until the packet reaches the node (or each of the set of nodes,> >>     > in the case of multicast) identified in the Destination Address field> >>     > of the IPv6 header.> >>>> >>> Note, of course, that the reference of "Destination Address" in RFC8200> >>> is clearly the final destination of the packet -- for instance, RFC8200> >>> >> I hear and can understand your reading of RFC8200.> >> > Could you please check RFC8200, and tell me what other possible> > interpretation of "Destination Address" you might have, in the context> > of RFC8200.> >> > RFC8200 does not even specify any routing header types. SO...where's the> > ambiguity?> >> >> >> >> At minimum, I think that we can agree that there is another reading, as expressed by other WG participants, and hence I disagree with "of course".> >> > No, I argue that there is not. IN fact, I argue that folks have been> > following that strategy for way too long, and that's quite frustrating.> >> >> >> >> Personally, I understand "Destination Address" as "Destination Address field of the IPv6 header." as indicated explicitly in the text quoted.> >> > The quoted text is from RFC8200. In the context of RFC8200 the> > Destination Address can only contain the ultimate destination of the> > packet. Where's the ambiguity?> >> > And let me ask you, as chair, another question, that will lead you to> > the same place: is IPv6 and end to end protocol?> >> >> > The fact that I may claim that RFC8200 contains a receipe for BBQ does> > not actually mean that that's the case.> >> >> >> >> I'm fine with having this clarified with 6MAND chairs and AD. That been said, the Internet AD would have an opportunity to DISCUSS this.> >> > For the record, I think this is a major issue that should be cleared> > before it can be claimed that there is consensus to request publication> > of this document.> >> >> >> >>> >>> does not specify any routing header type, and hence the meaning is> >>> unambiguous (there's no destination other than the final destination of> >>> the packet).> >>>> >>> This is of course in line with IPv6 being and end-to-end protocol, and> >>> crucial for other related mechanisms to work as expected (such as IPsec> >>> AH). Please also check: draft-smith-6man-in-flight-eh-insertion-harmful.> >>>> >>> So, in order to proceed with the document, there are multiple options> >>> forward:> >>>> >>> 1) Just remove the corresponding text/behavior> >>> >> That is indeed one option. But as of today, this is not my assumption.> >>> >>> 2) Implement a similar mechanism in an RFC8200-compliant manner (e.g.,> >>> re-encap)> >>> >> SRH insert is out of scope of this specification. So yes, IPv6 encaps is used.> >> We are talking SRH removal. I'm assuming that you are referring to PSP. My understanding is that this function (PSP) is to distribute the (forwarding plane) load between the PSP and the USP. In a way similar to MPLS PHP. But in all cases, this is not about SRH insertion.> >> > It's about SRH removal, which is also forbiden by RFC8200.> >> >> >> >> >>> 3) Do the necessary standards work to update RFC8200, such that it> >>> allows this sort of behavior, and only ship the network-programming> >>> draft for publication when at least 6man has consensus to proceed on> >>> that path.> >>> >> Not the preferred path as of today.> >> > Yes, it should be evident that it seems the preferred path has been> > (starting with EH insertion at the time) to circumvent existing> > specifications.> >> >> >> >>> >>> P.S.: I will go through the document once again... but the same> >>> reasoning should be applied to any EH-insertion/removal at a place other> >>> than the source of the packet or its final destination.> >>> >> It looks to me that SRH insertion and SRH removal are to be treated differently.> >> > I don't see how or why. Both violate the same requirement in RFC8200.> >> >> > Thanks,> >>> --------------------------------------------------------------------> IETF IPv6 working group mailing list> [email-masked]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 21:23:10 -0500

Joel,

> IPv6 packet is the value placed in the IPv6 destination address field.

One could indeed argue that the wording in RFC8200 could have been
better. However, the intent is clear, and also since RFC8200 does not
specify any routing header type, in the context of RFC8200 packets
there's no possible destination other than the ultimate destination.

Maybe an errata is warranted.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 21:29:47 -0500

> Maybe an errata is warranted.

FWIW, Appendix B notes:

   o  Clarified that extension headers (except for the Hop-by-Hop
      Options header) are not processed, inserted, or deleted by any
      node along a packet's delivery path.

Thanks,

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 09:27:16 +0000

[-6man]

Hi Pablo, authors,

The draft has a reference to  [I-D.filsfils-spring-srv6-net-pgm-insertion].
This reference is unused in the text and be may understood as a hint to SRH insertion which is out of scope of this draft.
Could you please remove that reference?

Thank you
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: <[email-masked]>
Date: Wed, 11 Dec 2019 18:37:39 +0000

Fernando,

> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Wednesday, December 11, 2019 12:16 AM
> 
> Bruno,
> 

Another interpretation is
"the node [...] identified in the Destination Address field of the IPv6 header."
https://tools.ietf.org/html/rfc8200#section-4

 Actually, that's verbatim the text from RFC 8200.

> RFC8200 does not even specify any routing header types. SO...where's the

- Read the mailing list and you will see that everyone do not share your opinion. So at least one person is wrong. I think that it would help if everyone, including you, could consider that they/you _may_ be wrong, at least to better understand the comments been made by others.  And possibly the text from RFC 8200 is not clear, but this is what we have. And this is the text to use to support the claim that this text is violated.
- Why have _you_ filled an errata against RFC 8200, in order to change the technical content of this section, if you don't agree that one may red " Destination Address field of the IPv6 header" as the IPv6 address present in the Destination Address field of the IPv6 header been received by the End node (or even sent by the source node)
https://www.rfc-editor.org/errata/eid5933

> No, I argue that there is not.IN fact, I argue that folks have been

That's not a question for a spring chair to answer.
I'm reading the sentence in RFC8200. If we can't agree on the meaning of this explicit sentence, I don't think that discussing philosophical r religious question is going to help.

> not actually mean that that's the case.

You do realize that your above sentence also applies to yourself? So how is this helping to progress?
Can we please focus on the RFC8200 sentence?  I'm really trying to understand your point. 
Let's stick to the texts of documents.

> before it can be claimed that there is consensus to request publication

OK, this is recorded. 
> I don't see how or why. 

SRH insertion is done by a node, on the path, which is not the destination of the IPv6 addresses.
SRH removal is done by a node which is receiving the packet because it's IPv6 address is in the destination of the IPv6 packet.

> Both violate the same requirement in RFC8200.

We are not having a conversation, so let's not repeats the same point again and again.

Your opinion has been noted. So does opinions on this same point expressed by other wg participants.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:00:59 +0000

Andrew,

No big deal. :-)

In reply to your question: I confirm that draft-ietf-spring-srv6-network-programming does not present any restriction to combine the SRH in conjunction with other EHs from other RFCs.

Thanks,
Pablo.

From: Andrew Alston <[email-masked]>
Date: Monday, 9 December 2019 at 18:19
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Thanks

Andrew

Andrew,

Thanks,
Pablo.

In Section 2:

Thanks

Andrew

Hello Bruno and all,

Best Regards,
Zhenqiang Li

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:00:35 +0000

Removed 6man

Hi Bruno,

I agree with all your changes and I have applied them to the latest version of the draft (rev06).

Many thanks,
Pablo.

From: "[email-masked]" <[email-masked]>
Date: Tuesday, 10 December 2019 at 18:41
To: draft-ietf-spring-srv6-network-programming <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 'SPRING WG List' <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Tuesday, 10 December 2019 at 18:41

Hi Pablo, authors

“4.13.  End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps”
is clear that an IPv6 encapsulation is performed. e.g with the below text
“  S14.   Push a new IPv6 header with its own SRH containing B”

However, I find that “4.14.  End.B6.Encaps.Red: [...] with reduced SRH” is a little less clear on that. E.g.,

“This is an optimization of the End.B6.Encaps behavior.”
Looks good.

“   The new SRH is created as described in Section 4.1.1 of [I-D.ietf-6man-segment-routing-header<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#ref-I-D.ietf-6man-segment-routing-header>].”
Is not that specific. Could you please explicitly add that an IPv6 outer header is added ?

“  End.B6.Encaps.RED  [...] with reduced SRH insertion SRv6 instantiation of a Binding SID”
Does not looks good.
Please remove any reference to “SRH insertion”. “IPv6 encapsulation with an SRH header” would be preferred.

“     4.13. End.B6.Encaps: Endpoint bound to an SRv6 policy w/ encaps  20
     4.14<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.14>. End.B6.Encaps.Red: [...] with reduced SRH . . . . . . . .  21<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-21> »

May be

Thank you,
Best regards,
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:01:27 +0000

Hi Bruno,

This paragraph is in the context of BGP-LS advertisement for SRv6 capabilities. The text in there is an example of a potential advertised capability.
The detailed definition of how capabilities are advertised belongs to draft-ietf-idr-bgpls-srv6-ext. In my opinion it should be the BGPLS draft the one detailing it.

Thanks,
Pablo.

From: "[email-masked]" <[email-masked]>
Date: Tuesday, 10 December 2019 at 18:37
To: draft-ietf-spring-srv6-network-programming <[email-masked]>
Cc: 'SPRING WG List' <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Tuesday, 10 December 2019 at 18:37

Hi Pablo, authors,

« The
   T.Encaps behavior would describe the capability of node N to perform
   a T.Encaps behavior, specifically it would describe how many SIDs
   could be inserted by N without significant performance degradation.”

Could you please explicit what is meant by ‘how many SIDs’? Especially for .Red.
Is this the number of SID in the SRH?
Because for .Red, the number of SID in the SRH is N-1, with N been the number of SIDs. (as the first SID is not included in the SRH).

Any option works for me. I’m just asking for the behavior to be clear and interoperable.

Thank you,
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:02:03 +0000

Hi Bruno,

Thanks. Agreed and done on the latest revision. (I had also spotted it).

Thanks,
Pablo.

From: "[email-masked]" <[email-masked]>
Date: Wednesday, 11 December 2019 at 10:27
To: draft-ietf-spring-srv6-network-programming <[email-masked]>
Cc: 'SPRING WG List' <[email-masked]>, Brian E Carpenter <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Wednesday, 11 December 2019 at 10:27

[-6man]

Hi Pablo, authors,

Thank you
--Bruno

Hello SPRING,

Thank you,

Bruno

Thank you.

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:03:15 +0000

Hi Adrian,

Many thanks for the detailed review. Editorial comments are very welcomed as I’m not a native English speaker.
See inline below for each comment. Note that this has been published as part of rev06.

Thank you,
Pablo.

From: Adrian Farrel <[email-masked]>
Organisation: Old Dog Consulting
Reply to: "[email-masked]" <[email-masked]>
Date: Friday, 6 December 2019 at 16:56
To: "[email-masked]" <[email-masked]>, 'SPRING WG List' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 'draft-ietf-spring-srv6-network-programming' <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Friday, 6 December 2019 at 16:56

Hi,

Thanks,
Adrian

===

https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-srv6-network-programming-05.txt

PC: Done. Thanks.

PC: Being discussed in a different thread.

---

PC: Moved into 2.1.
Just for my knowledge, why should it be moved into 2.1 and not into 1.1?

---

PC: Done.

---

PC: Added SRv6. Added more abbreviations as well.

---

The Introduction says:

PC: Thanks. I have rewritten the abstract among those lines.

--

Section 1

PC: Done.

---

Section 1

PC: Comma added.
---

Section 1

PC: Done.
---

Section 1

PC: Done.

---

Section 2

PC: Sentence has been removed.
---

Section 2

PC: Added SRH[n] to definitions.
---

Section 3

PC: Done.

---

3.1

PC: See in the next comment.

---

3.1

PC: I have rewritten the entire text as you suggested. This point and the previous one should be clear in the new text.

---

PC: The SRH draft is defining the different types of nodes accurately. (Transit node, Source SR node, SR Endpoint).
This draft has

Section1:
   Familiarity with the Segment Routing Header
   [I-D.ietf-6man-segment-routing-header<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#ref-I-D.ietf-6man-segment-routing-header>] is assumed.

Section 5:
These
   behaviors are not bound to a SID and they correspond to source SR
   nodes or transit nodes [I-D.ietf-6man-segment-routing-header<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#ref-I-D.ietf-6man-segment-routing-header>].

Don’t you think that is enough?

---

4.

PC: Added to Section2  together with Prefix SID.

PC: It does not fit in a single line and brakes table alignment.

---

4.1

PC: Paragraph removed as the (unless combined... has been reported as unclear by others.

---

4.1

PC: The IANA allocations for SRH have been completed. I have replaced all TBD-SRH for the proper codepoint.

---

4.1

Similarly:

And:

PC: I don’t see the difference in between both punctuation options.
Since I’m not a native English speaker I take your proposal and use it throughout all the ICMP sentences in the document.

---

4.1

I was surprised by...

PC: Is there any difference on the hop limit check if I do it two lines earlier? I believe that the end result is the same.

---

4.1 (and other sections)

What have I missed?

PC: How do you propose to check whether Last Entry value exceeds the maximum possible theoretical Last Entry value?
The only information you have is the Header Extension Length. Based on this I compute the maximum theoretical Last Entry possible value, and then just compare the values.

Maybe I am the one who have missed something. If you have a simpler proposal please let me know.

---

4.2

Maybe

PC: Ack to both.

---

4.2

PC: Same as before

---

4.3

PC: Is.

PC: Fixed.

And (again)...

PC: Same as before.

---

4.4

PC: Fixed.

Fix to

PC: Fixed.
and

PC: Fixed.

PC: We reproduced the same format of the SRH draft that had consensus. Two different pieces of code.

PC: Maybe one option to brainstorm about is to create two sub-sections for each behavior.
One sub-section represents the SRH processing and the other the upper-layer processing. Not sure this would improve it though.

---

4.5

PC: Ack and fixed.

---

4.6

s/would be/is/

PC: Ack and fixed both.

---

4.7 and 4.8

PC: Ack and fixed.

---

4.9

PC: Fixed.

---

4.10

   Any SID

PC: Fixed.

---

4.11

Usual issue with

PC: Fixed.
---

4.12

PC: Ack.

Possibly s/may/MAY/
PC: Ack.

Where arguments are optional, I don't think you have made it clear what
you do if no argument is supplied. I would presume you set the ARG bits
to zero, but I am not clear whether zero could be interpreted as a
valid argument.
PC: On a per deployment basis the operator decides which value of ARG represent “No arguments”.

PC: Ack.

---

4.13

PC: Ack.

s/B[I-D/B [I-D/
PC: Ack.

PC: I disagree. Example RFC8660 (Segment Routing with the MPLS Data Plane).

---

4.13

Step 13 is

PC: Indeed. Fixed.

PC: Indeed. Fixed.

---

4.14

   In this way, the

PC: Replaced

---

4.15

s/B[I-D/B [I-D/

PC: Fixed both.

---

4.15

s/a the/the/

PC: Fixed.

---

4.16.1 and 4.16.2

PC: Indeed, this has been pointed out in other threads and I will add text to clarify it in the next revision.

PC: This is done through the advertisement in the control plane. See the table “IETF- SRv6 Endpoing Behaviors” in section 9.

PC: This is one use-case indeed.  I don’t follow you in the notion of “Pop and Go”.

---

5.1

PC:
The point is to highlight/remind that the SRH is not inspected or processed if the IPv6 DA of the packet is not a local address of that node.

---

5.1

      P1 = (A, S2)

PC: If the SRH or anything below is not being processed, there is no performance impact, no?

---

5.1

PC: I have rewritten the sentence.

---

5.2

PC: Not sure what resolution you are looking for here.

---

5.2

For complete clarity...

PC: Included.

---

5.3

---

PC:
There are two types of source nodes.
You can have a source node that is doing plain IP transit. You have a local policy to encapsulate all packets matching X to be steered into a segment routing policy with behavior T.Encaps.
The other type of source node is the SR endpoints that instantiate a BindingSID. This is also an Source node that steers all packets received with IPv6 DA = BSID.
Section 5 is describing transit behaviors.

---

6.1

PC: I disagree that this is an update to the SRH. The SRH defines a header and one type of segment processing.
Defining a counter is not related to the SRH at all.

---

6.3

PC: Why? Its defining new behaviors for the purpose of OAM, but those are not required in NET-PGM.

---

7.

Probably "The SRH Section 5.1" is meant to be a reference to another
document.
PC: Fixed.
PC: Changed also title of that section.

---

Section 8 has...

PC: Thanks for hint.
---

8.1

Likewise...
OLD

PC: Fixed.

---

8.2

What about...

PC: Rewrote the paragraph.
---

8.3

OLD

PC: Ack.

---

8.4

OLD

PC: Ack. Changing also second instance of signaling for control plane.

---

8.4

This needs a citation.

PC: acking.

---

9.

PC: Ack.
---

9.

PC: This comment has also been raised by Bruno (as individual). I agree and I have proposed to Bruno this:
Experimental and Private use deleted
Specification Required changed to FCFS as per Bruno’s suggestion
New block in the previous space of experimental and private that is reserved for future use of IETF.

---

9.

PC: No longer applicable.

---

9.

PC: Ack.

---

9.

In table 4 you have...

PC: Indeed. Droped.
---

12.2

PC : Ack.

---

12.2

PC: Ack.

Many thanks!

Hello SPRING,

Thank you,

Bruno

Thank you.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 11 Dec 2019 20:06:15 +0000

Hi Warren, Brian,

Thank you for your comments.

Previous versions of this draft contained a more verbose Security section (e.g. https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-03#section-7).
However, the content of that section was already covered in the SRH. Hence in the latest revision of SRv6 Network Programming we decided to replace those security considerations for a reference to the SRH. This was discussed during the IETF106 SPRING meeting and no-one expressed concerns about it.

The authors consider that Network Programming only defines new SID behaviors and this does not pose any threat others to those already discussed in the SRH.
I have rewritten the Security Considerations of draft-ietf-spring-srv6-network-programming in rev06 to reflect this.

Thank you,
Pablo.

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Tuesday, 10 December 2019 at 02:11
To: Warren Kumari <[email-masked]>, Bruno Decraene <[email-masked]>
Cc: SPRING WG List <[email-masked]>, draft-ietf-spring-srv6-network-programming <[email-masked]>
Subject: Re: WGLC - draft-ietf-spring-srv6-network-programming
Resent from: <[email-masked]>
Resent to: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Tuesday, 10 December 2019 at 02:11

    
    Regards
       Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 11 Dec 2019 22:10:06 -0000

Hi Pablo,

Very good progress. Thanks for the work.

I have snipped down to the conversation points below.

The document has gone through a lot of changes in -06 and clearly there is a -07 in the pipe. I'll wait for that before doing a re-read.

Best,
Adrian

[snip]

> Just for my knowledge, why should it be moved into 2.1 and not into 1.1?
 
1.1 would be acceptable, but since 2. Is all about terminology and stuff, it sits there quite well.

[snip]

> PC: The SRH draft is defining the different types of nodes accurately. 
> (Transit node, Source SR node, SR Endpoint).

I have no issue with the definition of nodes (other than the way the concept is used in section 5).

>   [I-D.ietf-6man-segment-routing-header] is assumed.

Sure.

> Don’t you think that is enough?

Well, obviously I found it unclear. In fact, section 4 had (at the time of my review) "Behaviors Associated with a SID" and I think I struggled with how "associated with" was different to "bound to".

But now you have renamed section 4, this helps.

Nevertheless, in Section 2 you have:
   SRv6 segment behavior: A packet processing behavior executed at an
   SRv6 segment endpoint.  Section 4 of this document defines behaviors
   related to traffic-engineering and overlay use-cases.  Other
   behaviors (e.g. service programming) are outside the scope of this
   document.

This must have confused me, too. Looking at it now, it seems to constrain "behaviour" to the SR Endpoint Behaviors of section 4, meaning that section 5 comes as a "surprise". Indeed, section 2 seems to say that section 5 is out of scope of this document :-Z

All I am asking for is some text early in the document that sets the scene. What is a behaviour? What classes of behaviour are we considering (end, transit, ...)? Who decides what behaviour to apply to what SID at which node? Not looking for pages of text. Probably you could do it in 5 lines.

[snip]
 
> PC: Is there any difference on the hop limit check if I do it two lines earlier? 
> I believe that the end result is the same.
 
It makes a difference which ICMP error is sent. I would argue that you shouldn't be looking at the SRH of a packet when the Hop Limit has expired.

[snip]
 
> PC: How do you propose to check whether Last Entry value exceeds
> the maximum possible theoretical Last Entry value?
> The only information you have is the Header Extension Length. Based
> on this I compute the maximum theoretical Last Entry possible value,
> and then just compare the values.
>

OK, we agree that the right thing to do is work out the largest possible Last Entry value (max_LE) and compare it to the actual Last Entry value. That is good.

I also agree that all you have in hand is the Header Extension Length (Hdr Ext Len)

I just don't think that you are computing the right value for max_LE using max_LE = (Hdr Ext Len / 2) - 1.

I would agree that max_LE < (Hdr Ext Len / 2) - 1  so that comparing Last Entry with that value provides a check. I just don't think it is a very precise check.

Perhaps my understanding of the actual value of Hdr Ext Len is incorrect, but if I am right, then you could probably get closer to a good number.

[snip] 
 
> PC: On a per deployment basis the operator decides which value of ARG represent “No arguments”.

Oh, well, I understand that the ARG bits apply to a function that is (presumably) known across the network, so I suppose that what you are saying is that when an operator deploys a function that may take arguments she must configure all participating nodes to have the same understanding of those arguments and how to set the bits when no arguments are supplied (in the case where arguments were optional for the function).

Now, it would be good to make some of that clear (perhaps in the last paragraph of 3.1).

But, we are in the business of making interoperable implementations, so this need to configure this feature needs to be spelled out.

> PC: I disagree. Example RFC8660 (Segment Routing with the
 
It is a very different usage made in that document.
Here you are saying that an implementation of this document must do something related to [I-D.ietf-spring-segment-routing-policy].
To me, that means that you can't implement this document without reading [I-D.ietf-spring-segment-routing-policy]

[snip]

>> 4.16.1 and 4.16.2
[snip] 
> PC: This is one use-case indeed.  I don’t follow you in the notion of

An MPLS concept associated with determining the forwarding behaviour, stripping the label, and forwarding.

[snip]

> PC: If the SRH or anything below is not being processed, there is no
 
Oh, you meant "speed of throughput" not "treated identically". The use of "treats" confuses the sentence.

OK. That comes under "sharpen your meaning of performance".

Perhaps:
   This means that N forwards the following two packets P1 and P2 at the
   same rate:

?

[snip]
 
> PC: Not sure what resolution you are looking for here.
 
I'm not sure either 😊

I think I am wondering how you can have "Transit with Encapsulation" since "Transit" means in the middle of the network (at a transit node) and "Encapsulation" means at a source node.
If a transit node is doing encapsulation, then you are recursing (which is OK).

When I waffled about behaviors before, it seemed to me that you have source, transit, and end behaviors. What you are describing in this section is a source behaviour. The fact that the source is encapsulating a packet that is already SRv6, is not so interesting as the fact that it is encapsulating a packet.

But then see also 5.3 and this discussion below.

> You can have a source node that is doing plain IP transit. You have a
> local policy to encapsulate all packets matching X to be steered into
> a segment routing policy with behavior T.Encaps.
> The other type of source node is the SR endpoints that instantiate a
> BindingSID. This is also an Source node that steers all packets received
> with IPv6 DA = BSID.

Confused me here. You say that these source nodes are transit nodes? That makes the definition of the two node types very unclear.

Just because the node is not a host does not make it a transit node. We have a good and clear definition of a transit node as a node that receives and sends an SRv6 packet. Nodes that add an SRH are source nodes. Nodes that remove the SRH are end nodes.
 
But in 5.4 the thing that is encapsulated is an L2 frame. So not plain IP transit, and not a packet received with a BSID in the DA.
At least, the text in 5.4 appears to say that.
So really, is this transit behaviour?

>> draft-ietf-6man-segment-routing-header by adding normative language to
> PC: I disagree that this is an update to the SRH. The SRH defines a
> header and one type of segment processing.
 
Well, perhaps you didn't just say what you meant to say because the text I quoted most clearly says that the counter is counting events related to the SRH.

But to the point: the document says...
   Any SRv6 capable node SHOULD implement the following set of combined
   counters (packets and bytes):
"Any SRv6 capable node" is clearly in the scope of draft-ietf-6man-segment-routing-header

> those are not required in NET-PGM.

You're right. Section 6.3 doesn't actually say anything.

[snip]
 
>   is reserved for future use of IETF.

That works.
The correct language for the last block is "Reserved. Not to be allocated."
(Note for you: a future standards track document can change the allocation policy for that block meaning it can then be used.)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Dec 2019 17:41:23 -0500

On 11/12/19 13:37, [email-masked] wrote:
[....]
>  Actually, that's verbatim the text from RFC 8200.

IN the context of RFC8200, that does not specify any routing header
type, what could be in the Destination Address other than the final
destination?

> - Read the mailing list and you will see that everyone do not share your opinion.

Yes, folks have also argued in the past that RFC2460 allowed EH insertion.

> So at least one person is wrong. I think that it would help if everyone, including you, could consider 
>that they/you _may_ be wrong, at least to better understand the
comments been made by others.  And possibly the text from RFC 8200 is
not clear, but this is what we have. And this is the text to use to
support the claim that this text is violated.
> https://www.rfc-editor.org/errata/eid5933

For the very same reason that the wg agreed including myself) to try to
clarify that EH insertion wasn't allowed: because folks were making
claims that they could.

FWIW, the errata does not change the technical meaning, but is provided
a clarification.

Thanks,

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 19 Dec 2019 11:58:56 +0000

Hi Adrian,

I have reviewed your suggested changes and incorporated them in the latest revision of the document. 
Please see below inline for more detail.

Many thanks,
Pablo.

-----Original Message-----
From: Adrian Farrel <[email-masked]>
Organisation: Old Dog Consulting
Reply to: "[email-masked]" <[email-masked]>
Date: Wednesday, 11 December 2019 at 23:10
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "[email-masked]" <[email-masked]>, 'SPRING WG List' <[email-masked]>
Cc: 'draft-ietf-spring-srv6-network-programming' <[email-masked]>
Subject: RE: WGLC - draft-ietf-spring-srv6-network-programming

    Hi Pablo,

    
    
    Best,
    Adrian
    
    [snip]

    
    [snip]

    
    
    Sure.

    

    

PC: After reviewing all your comments on this topic: I have removed the previously known as "Transit" behavior.  Section 5 now is only about SR Policy Headend behaviors. All sub-sections have been renamed as well. I believe this helps the document.
    
    [snip]

PC: I've checked with the SRH draft and the ICMP check is the last check happening in the pseudocode. I would tend to agree that this should be the last thing done once you have determined that the packet needs to be forwarded. 
    
    [snip]

    

    
   
PC: Ok. I rechecked it and I believe that we cannot get any better than that.
[RFC8200]
Hdr Ext Len         8-bit unsigned integer.  Length of the Routing
                              header in 8-octet units, not including the
                              first 8 octets.
[draft-ietf-6man-segment-routing-header-26]
o  Last Entry: contains the index (zero based), in the Segment List,
   of the last element of the Segment List.

Let us consider an SRH containing k SIDs and 0 or more TLVs.
Hdr Ext Len >= k x (16 / 8) = k x 2
Last Entry = k - 1

Isolating k on one side of each equation:
k <= Hdr Ext Len / 2
k = Last Entry + 1

Combining the two equations together:
Last Entry + 1 <= Hdr Ext Len / 2

Isolating Last Entry on one side of the equation:
Last Entry <= Hdr Ext Len / 2 - 1

Further note that, if no TLV is present, we have:
Last Entry = Hdr Ext Len / 2 - 1

PC: If I'm still missing the point let me know!

    [snip] 

    

PC: Added a paragraph about it at the end of 3.1.

PC: All the definitions required by this paragraph are covered in RFC8402 section 5. I have removed the reference to draft ietf-spring-segment-routing-policy from the draft.
    
    [snip]
    
    [snip] 

    [snip]

    
    
    Perhaps:
    
    ?

PC: Text removed  (entire section) as per my comment above. 

    [snip]

    I'm not sure either 😊

    

    

PC: See comment above about the entire section 5.

    

PC: This document talks of the processing and behaviours of SRv6. And hence the counters are included in this draft.

    
    [snip]

    That works.

PC: Thanks for the correction. Fixed. Thanks.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 27 Dec 2019 19:28:33 -0000

Thanks Pablo and Happy Imminent New Year.

> in the latest revision of the document. 

Great. I will try to pull that and review it soon.

> Please see below inline for more detail.

[snipped]

AF: So, just to check I understand what you are saying. If a packet arrives with Hop Limit already at zero you would still look inside the SRH?

    

    

AF: Very (very) sorry. My bad.
I entirely missed " Length of the Routing header *in*8-octet*units*, not including the first 8 octets"
Now I feel stupid.

    

AF: Last try before I give up on this one (you may be relieved to know).
Does every device that supports SRv6 have to support this document? I had formed the impression not: that is a simple SRv6 routing node functions fine without this document (even if this document also describes it's behaviour). But, in the quoted text you are adding description of function for all "SRv6 capable nodes" that is not described elsewhere. So either:
- it is not possible to have an SRv6 capable node prior to this draft
or
- you are updating some other document that describes SRv6 capable nodes

Many thanks for the work,
Adrian