Subject: [spring] Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 21 Sep 2020 11:24:14 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-19: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 3.1.  (In case I missed it, please provide the obvious reference) Per
“In such a case, the semantics and format of the ARG bits are defined as part
of the SRv6 endpoint behavior specification”, is “endpoint behavior
specification” Section 4 or another document?  If the former, I don’t see any
references to argument bits in the pseudo-code of the Section 4.* subsections. 
If the latter, what document?  Can the behaviors be polymorphic (i.e., same
network behavior accepting different arguments)?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for responding to the SECDIR review (and thank you to Brian Weis for
doing it)

** Section 3.2.  Per “An SR Source Node cannot infer the behavior by
examination of the FUNCT value of a SID”, isn’t there at least some hint
provided by the use of the FUNCT from the IANA registry?

** Section 3.2.
Per “Function 11 associated with the behavior End.X …” AND

Per “Function 12 associated with the behavior End.X …”

The initial registrations for Endpoint Behavior per Section 10.2.1 suggest that
Function 11 and 12 are End.T.

** Section 4.1.  Pseudo-code without formal definition might be open to
interpretation.  My nits (which likely apply to other sections) are that: -- it
might not be clear that S03, S06 and S10 are effectively returns/exits from
this “behavior”, and if they are run, S12-S15 should never be reached
(otherwise Segments Left or Hop Limit = -1)

-- (for consistency) the IF … ELSEIF … END construct is used in Section 4.8,
but not here.

-- What does it mean to indent the code?  For example S06 is:
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.

I can see why “Code 0 …” is indented under “Send an … “ as this is a line wrap,
but why is “Interrupt packet processing?”

** A few other psuedo code nits:
-- Section 4.1.  S05 uses “IPv6 Hop Limit” but S12 uses “Hop Limit”.  Recommend
consistency.

-- Section 4.4.  Per S05.  Is “next header” purposely lower case?  I asked
because it looks like explicit field names are in upper case (e.g., S03 says
“Segments Left field”).

-- Section 4.16.3.  As a style/consistency note, the other sections which check
the upper header type seem use of a construct of != 41 or 4 to “Process per
Section 4.1.1”. (e.g., Section 4.4, 4.5, 4.6, etc.)

** Section 8.  Given how meticulously the Section 4 guidance was described, it
would be helpful to say that the HMAC TLV processing, if present, happens as a
notional Step “S0” per guidance in Section 2.1.2.1 of RFC8754.

** Editorial Nits:
-- Section 3.2. Typo. s/an network/a network/

-- Section 3.2. Typo. s/is minimum/is minimal/

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 22 Sep 2020 19:58:57 +0000

Hi Roman,

Many thanks for your thorough review. Please see inline with [PC].

Thanks,
Pablo.

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: lunes, 21 de septiembre de 2020 20:24
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>; [email-masked]
Subject: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Section 3.1.  (In case I missed it, please provide the obvious reference) Per “In such a case, the semantics and format of the ARG bits are defined as part of the SRv6 endpoint behavior specification”, is “endpoint behavior specification” Section 4 or another document?  If the former, I don’t see any references to argument bits in the pseudo-code of the Section 4.* subsections. 
If the latter, what document?  Can the behaviors be polymorphic (i.e., same network behavior accepting different arguments)?

[PC] The End.DT2M behavior in section 4.12 has an argument called “Arg.FE2”. The behavior specification explains the semantics of the argument and the pseudocode describes how it is handled. The arguments to the function can indeed vary.

Thanks for responding to the SECDIR review (and thank you to Brian Weis for doing it)

** Section 3.2.  Per “An SR Source Node cannot infer the behavior by examination of the FUNCT value of a SID”, isn’t there at least some hint provided by the use of the FUNCT from the IANA registry?
[PC] Recall that Section 3.1 says the following (there is no hint):
   The FUNCT is an opaque identification of a local behavior bound to
   the SID.
   The term "function" refers to the bit-string in the SRv6 SID.  The
   term "behavior" identifies the behavior bound to the SID.  The
   behaviors are defined in Section 4 of this document.

[PC] The FUNCT is part of the SID value assigned by the operator. This SID is associated with a behavior (defined in the IANA registry). The control plane is going to advertise the association of the SID (including the FUNCT) and the particular behavior (using the IANA codepoint).
An intermediate node that only has access to the SRv6 user traffic, only by looking at the FUNCT value (and with no control plane information), cannot know what the behavior is associated to such SID. Looking ahead at your next comment, I believe the confusion might arise from the values used in the example in this section.

** Section 3.2.

The initial registrations for Endpoint Behavior per Section 10.2.1 suggest that Function 11 and 12 are End.T.
[PC] Please see response to previous comment. Indeed, the example can be improved.  I’ll replace 11 and 12 for 100 and 101 that are unassigned on the IANA registry to more clearly differentiate between FUNCT and Behavior.

** Section 4.1.  Pseudo-code without formal definition might be open to interpretation.  My nits (which likely apply to other sections) are that: -- it might not be clear that S03, S06 and S10 are effectively returns/exits from this “behavior”, and if they are run, S12-S15 should never be reached (otherwise Segments Left or Hop Limit = -1)
[PC] Indeed, it would be clearer if we call out where there is a return/exit.
<OLD>
   S03.      Proceed to process the next header in the packet,
                whose type is identified by the Next Header field in
                the routing header.
</OLD>
<NEW>
   S03.      Stop processing the SRH, proceed to process the next
                header in the packet, whose type is identified by the 
                Next Header field in the routing header.
</NEW>

[PC] For lines S06 and S10 currently include “Interrupt packet processing and discard the packet”. Do you think this is sufficient to indicate there is no more SRH processing done?

-- (for consistency) the IF … ELSEIF … END construct is used in Section 4.8, but not here.
[PC] Indeed, pseudocodes should be consistent.

I can see why “Code 0 …” is indented under “Send an … “ as this is a line wrap, but why is “Interrupt packet processing?”
[PC] Yes. The indentation of interrupt packet processing is incorrect. It should be part of the same statement as above (the period should not be there). I’ll review the indentation of all pseudocodes.

** A few other psuedo code nits:
-- Section 4.1.  S05 uses “IPv6 Hop Limit” but S12 uses “Hop Limit”.  Recommend consistency.
[PC] Ack. Fixed for next next rev.

-- Section 4.4.  Per S05.  Is “next header” purposely lower case?  I asked because it looks like explicit field names are in upper case (e.g., S03 says “Segments Left field”).
[PC] Ack. Fixed for next next rev.

-- Section 4.16.3.  As a style/consistency note, the other sections which check the upper header type seem use of a construct of != 41 or 4 to “Process per Section 4.1.1”. (e.g., Section 4.4, 4.5, 4.6, etc.)
[PC] Ack. Fixed for next next rev.

** Section 8.  Given how meticulously the Section 4 guidance was described, it would be helpful to say that the HMAC TLV processing, if present, happens as a notional Step “S0” per guidance in Section 2.1.2.1 of RFC8754.
[PC] Ack. I would propose the following addition at the end of the security considerations.
<NEW>
When enabled by local configuration, HMAC processing occurs at the beginning of SRH processing as defined in Sec 2.1.2.1 of RFC8754.
</NEW>

** Editorial Nits:
-- Section 3.2. Typo. s/an network/a network/
-- Section 3.2. Typo. s/is minimum/is minimal/
[PC] Acking both. Fixed for next next rev.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 23 Sep 2020 16:25:50 +0000

Hi Roman,

We have posted an updated version of the I-D with the proposed changes below (together with other comments from Barry, Rob and Eric).
Please review and let me know your feedback.

Many thanks,
Pablo.

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-20
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-20

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: martes, 22 de septiembre de 2020 21:59
To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>
Subject: RE: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

Hi Roman,

Thanks,
Pablo.

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]>
Sent: lunes, 21 de septiembre de 2020 20:24
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>; [email-masked]
Subject: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

** Section 3.2.

** Section 4.1.  Pseudo-code without formal definition might be open to interpretation.  My nits (which likely apply to other sections) are that: -- it might not be clear that S03, S06 and S10 are effectively returns/exits from this “behavior”, and if they are run, S12-S15 should never be reached (otherwise Segments Left or Hop Limit = -1) [PC] Indeed, it would be clearer if we call out where there is a return/exit.
<OLD>

-- Section 4.16.3.  As a style/consistency note, the other sections which check the upper header type seem use of a construct of != 41 or 4 to “Process per Section 4.1.1”. (e.g., Section 4.4, 4.5, 4.6, etc.) [PC] Ack. Fixed for next next rev.

** Editorial Nits:
-- Section 3.2. Typo. s/an network/a network/
-- Section 3.2. Typo. s/is minimum/is minimal/ [PC] Acking both. Fixed for next next rev.

---

From: <[email-masked]>
Date: Thu, 24 Sep 2020 09:49:47 +0800 (CST)

Hi Pablo,

The following questions have been sent before, but I didn't see the corresponding discussion. So send it again. Hope to get your reply. Thanks!

1) Is it necessary to distinguish between USP and USD ?

It is not very clear when to use USP-flavor SID and when to use USD-flavor SID.

According to the pseudo code in this document, USP does not strip the outer IPv6 header, while USD does.

Let's discuss it in two ways:

    a) According to the H.encaps mode only supported in the current version, it is assumed that there is only one routing extension header SRH whthin the IPv6 header. In this case, I think both USP and USD should remove the IPv6 header, i.e, there's no need to make a difference.

    b) If the H.insert mode may be supported later, it means that the IPv6 header will contain multiple routing extension headers. In this case, if the current route extension header is terminated, the next header will be active, and outer IPv6 header needs to be kept. This is the behavior of USP, and, USD cannot be used. The question is that, the node implementing the insert operation cannot predict what kind of routing extension header may appear in the packet, thus, for the SID in the outer segment list, to be on the safe side, should we always try to use USP flavor ?

After all, is USP flavor enough and USD flavor redundant ?

2) Processing of upper layer header does not support MPLS payload type.

The pseudo code is considered that under normal circumstances, the inner layer payload is IPv4, IPv6, or ICMPv6, why not MPLS ? When we implement the SRv6 function, we face the requirements of traditional PW/L3VPN label over SRv6 policy. I don't think any pseudo code in this document covers this scenario.

3) The application scenario of End.T is not clear and the description is very vague. Although it is said (see section 8.1) that it can represent topology information and be announced with IGP, but we don't see the relevant description in any IGP extension draft.

4) I think the SRv6 Endpoint Behaviors Registry (see section 9.2) is cumbersome. As long as a new flavor is added, it is necessary to combine the existing batched basic behaviors and old flavors with the new flavor, to define multiple new codepoints. This will result in a poor readability of the table (see 9.2.1. Initial Registrations). Why not split this field in two, for example, high 8 bits represent basic behavior, and low 8 bits indicate flavor ?

Regards,

PSF

原始邮件

发件人：PabloCamarillo(pcamaril)
收件人：Pablo Camarillo (pcamaril);Roman Danyliw;The IESG;
抄送人：Bruno Decraene;[email-masked];Joel Halpern;[email-masked];[email-masked];
日 期 ：2020年09月24日 00:26
主 题 ：Re: [spring] Roman Danyliw's Discuss ondraft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

Hi Roman,

Many thanks,
Pablo.

-----Original Message-----
From: Pablo Camarillo (pcamaril) <[email-masked]> 
Sent: martes, 22 de septiembre de 2020 21:59
To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>
Subject: RE: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

Hi Roman,

Thanks,
Pablo.

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]>
Sent: lunes, 21 de septiembre de 2020 20:24
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>; [email-masked]
Subject: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

** Section 3.2.

** Editorial Nits:

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

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 24 Sep 2020 13:20:27 +0000

Hi Pablo!

Thanks for the updates in -20.  A few more comments inline ...

> Sent: Tuesday, September 22, 2020 3:59 PM
> Cc: [email-masked]; spring-
> [email-masked]; [email-masked]; Bruno Decraene
> <[email-masked]>; Joel Halpern <[email-masked]>
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-
> programming-19: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> Cc: [email-masked]; spring-
> [email-masked]; [email-masked]; Bruno Decraene
> <[email-masked]>; Joel Halpern <[email-masked]>;
> [email-masked]
> Subject: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-
> programming-19: (with DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Section 3.1.  (In case I missed it, please provide the obvious reference) Per “In
> such a case, the semantics and format of the ARG bits are defined as part of the
> SRv6 endpoint behavior specification”, is “endpoint behavior specification”
> Section 4 or another document?  If the former, I don’t see any references to
> argument bits in the pseudo-code of the Section 4.* subsections.
> [PC] The End.DT2M behavior in section 4.12 has an argument called “Arg.FE2”.
> The behavior specification explains the semantics of the argument and the
> pseudocode describes how it is handled. The arguments to the function can
> indeed vary.

Thanks for pointing this out.  What I still don't understand is whether End.DT2M the only behavior that uses the arguments?

> [PC] The FUNCT is part of the SID value assigned by the operator. This SID is
> associated with a behavior (defined in the IANA registry). The control plane is
> going to advertise the association of the SID (including the FUNCT) and the
> particular behavior (using the IANA codepoint).
> An intermediate node that only has access to the SRv6 user traffic, only by
> looking at the FUNCT value (and with no control plane information), cannot
> know what the behavior is associated to such SID. Looking ahead at your next
> comment, I believe the confusion might arise from the values used in the
> example in this section.
> 
> ** Section 3.2.
> [PC] Please see response to previous comment. Indeed, the example can be
> improved.  I’ll replace 11 and 12 for 100 and 101 that are unassigned on the
> IANA registry to more clearly differentiate between FUNCT and Behavior.

Understood.

> might not be clear that S03, S06 and S10 are effectively returns/exits from this
> “behavior”, and if they are run, S12-S15 should never be reached (otherwise
> Segments Left or Hop Limit = -1) [PC] Indeed, it would be clearer if we call out
> where there is a return/exit.
> <OLD>
> [PC] For lines S06 and S10 currently include “Interrupt packet processing and
> discard the packet”. Do you think this is sufficient to indicate there is no more
> SRH processing done?

I'd recommend using consistent language.  Since you're using "stop" in S03, I'd recommend using the same thing in S06 and S10

> [PC] Yes. The indentation of interrupt packet processing is incorrect. It should
> be part of the same statement as above (the period should not be there). I’ll
> review the indentation of all pseudocodes.
>
>
> -- Section 4.4.  Per S05.  Is “next header” purposely lower case?  I asked because
> it looks like explicit field names are in upper case (e.g., S03 says “Segments Left
> field”).
> Section 4.1.1”. (e.g., Section 4.4, 4.5, 4.6, etc.) [PC] Ack. Fixed for next next rev.
> 
> When enabled by local configuration, HMAC processing occurs at the beginning
> of SRH processing as defined in Sec 2.1.2.1 of RFC8754.
> </NEW>
> 
> ** Editorial Nits:

Thanks for all of the changes described above.

Regards,
Roman

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 25 Sep 2020 18:29:10 +0000

Hi Roman,

Please see inline with [PC2].

Thanks,
Pablo.

-----Original Message-----
From: Roman Danyliw <[email-masked]> 
Sent: jueves, 24 de septiembre de 2020 15:20
To: Pablo Camarillo (pcamaril) <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>
Subject: RE: Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)

Hi Pablo!

> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> Section 3.1.  (In case I missed it, please provide the obvious 
> reference) Per “In such a case, the semantics and format of the ARG 
> bits are defined as part of the
> Section 4 or another document?  If the former, I don’t see any 
> If the latter, what document?  Can the behaviors be polymorphic (i.e., 
> same network behavior accepting different arguments)?
> 
> The behavior specification explains the semantics of the argument and 
> the pseudocode describes how it is handled. The arguments to the 
> function can indeed vary.

Thanks for pointing this out.  What I still don't understand is whether End.DT2M the only behavior that uses the arguments?
[PC2] Correct, the only behavior defined in this document with arguments is End.DT2M.

> examination of the FUNCT value of a SID”, isn’t there at least some 
> hint provided by the use of the FUNCT from the IANA registry?
> [PC] The FUNCT is part of the SID value assigned by the operator. This 
> SID is associated with a behavior (defined in the IANA registry). The 
> control plane is going to advertise the association of the SID 
> (including the FUNCT) and the particular behavior (using the IANA codepoint).
> An intermediate node that only has access to the SRv6 user traffic, 
> only by looking at the FUNCT value (and with no control plane 
> information), cannot know what the behavior is associated to such SID. 
> Looking ahead at your next comment, I believe the confusion might 
> arise from the values used in the example in this section.
> 
> ** Section 3.2.
> The initial registrations for Endpoint Behavior per Section 10.2.1 
> suggest that Function 11 and 12 are End.T.
> [PC] Please see response to previous comment. Indeed, the example can 
> be improved.  I’ll replace 11 and 12 for 100 and 101 that are 
> unassigned on the IANA registry to more clearly differentiate between FUNCT and Behavior.

Understood.

> ** Section 4.1.  Pseudo-code without formal definition might be open 
> to interpretation.  My nits (which likely apply to other sections) are 
> that: -- it might not be clear that S03, S06 and S10 are effectively 
> returns/exits from this “behavior”, and if they are run, S12-S15 
> should never be reached (otherwise Segments Left or Hop Limit = -1) 
> [PC] For lines S06 and S10 currently include “Interrupt packet 
> processing and discard the packet”. Do you think this is sufficient to 
> indicate there is no more SRH processing done?

I'd recommend using consistent language.  Since you're using "stop" in S03, I'd recommend using the same thing in S06 and S10
[PC2] We believe that it might be good to use "Stop" on S03 because we are only stopping the SRH processing, but proceeding to process the next headers in the chain. While S06 and S10 are really stopping the packet processing at all (packet will be discarded after generating an ICMP error). If you still believe we should use the same word in the three, please let me know and Ill do in the next revision of the document.

> I can see why “Code 0 …” is indented under “Send an … “ as this is a 
> line wrap, but why is “Interrupt packet processing?”
> [PC] Yes. The indentation of interrupt packet processing is incorrect. 
> It should be part of the same statement as above (the period should 
> not be there). I’ll review the indentation of all pseudocodes.
>
>
> -- Section 4.4.  Per S05.  Is “next header” purposely lower case?  I 
> asked because it looks like explicit field names are in upper case 
> (e.g., S03 says “Segments Left field”).
> -- Section 4.16.3.  As a style/consistency note, the other sections 
> which check the upper header type seem use of a construct of != 41 or 
> 4 to “Process per Section 4.1.1”. (e.g., Section 4.4, 4.5, 4.6, etc.) [PC] Ack. Fixed for next next rev.
> 
> ** Section 8.  Given how meticulously the Section 4 guidance was 
> described, it would be helpful to say that the HMAC TLV processing, if 
> present, happens as a notional Step “S0” per guidance in Section 2.1.2.1 of RFC8754.
> When enabled by local configuration, HMAC processing occurs at the 
> beginning of SRH processing as defined in Sec 2.1.2.1 of RFC8754.
> </NEW>
> 
> ** Editorial Nits:

Regards,
Roman

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 28 Sep 2020 19:27:43 +0000

Hi Pablo!

Thanks for the explanation.  I've cleared my DISCUSS.

Regards,
Roman

> Sent: Friday, September 25, 2020 2:29 PM
> Thanks for pointing this out.  What I still don't understand is whether
> End.DT2M the only behavior that uses the arguments?
> I'd recommend using consistent language.  Since you're using "stop" in S03, I'd
> recommend using the same thing in S06 and S10 [PC2] We believe that it might
> be good to use "Stop" on S03 because we are only stopping the SRH processing,
> but proceeding to process the next headers in the chain. While S06 and S10 are
> really stopping the packet processing at all (packet will be discarded after
> generating an ICMP error). If you still believe we should use the same word in
> the three, please let me know and Ill do in the next revision of the document.
>