Hi Alvaro, Many thanks for the feedback. Inline below with PC3. Note that we have just posted rev24 as per the comments below.
Cheers, Pablo. -----Original Message----- From: Alvaro Retana <aretana.i...@gmail.com> Sent: miércoles, 7 de octubre de 2020 17:04 To: The IESG <i...@ietf.org>; Pablo Camarillo (pcamaril) <pcama...@cisco.com> Cc: draft-ietf-spring-srv6-network-programm...@ietf.org; Bruno Decraene <bruno.decra...@orange.com>; spring-cha...@ietf.org; Joel Halpern <j...@joelhalpern.com>; spring@ietf.org Subject: RE: Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) On September 30, 2020 at 9:18:37 AM, Pablo Camarillo wrote: Pablo: Hi! Just leaving below the points I still want to talk about. Thanks! Alvaro. ... > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- ... > > (1b) It would be nice if the behavior in §4.1.1 were also specified > > using pseudocode... ... > §4.1.1 is called from different places, while processing different > behaviors. Is it expected that the "local configuration" will cover > each behavior individually, or will the operator be able to configure > a single policy for all? In either case, it would be good to mention it. > [PC2] In the document we've left 'local configuration' up to an [PC2] implementation. Whether an implementation implements the local [PC2] configuration on an interface as an ACL or globally for all SIDs or per [PC2] SID via some API is not for this document to decide, and has no impact [PC2] on interoperability. True, it has no impact on interoperability, but it can have an impact on the operation of the network. While not including details about local configuration, I would like to see some guidance on the definition of proper policies. For example, considering your example of allowing ICMPv6, OAM may be important, but forwarding a packet that is not in line with the behavior would not be. [PC3] Indeed, it's a good point. We have posted in rev24 the following diff: <OLD> Notes: S01. As an example, an operator may not wish to have any TCP traffic destined to a local SID, but may want to enable ICMPv6 packet processing for OAM purposes. </OLD> <NEW> Allowing processing of specific Upper-Layer Headers types is useful for OAM. As an example, an operator might permit pinging of SIDs. To do this they may enable local configuration to allow Upper-layer Header type 58 (ICMPv6). It is RECOMMENDED that an implementation of local configuration only allows Upper-layer Header processing of types that do not result in the packet being forwarded (e.g. ICMPv6). </NEW> Along those lines, the headend policy should be consistent with the behavior and any local configuration. This expectation should also be mentioned somewhere. [PC3] Indeed. We've included that in the Security Considerations section. <OLD> This document introduces SRv6 Endpoint and SR Policy Headend behaviors for implementation on SRv6 capable nodes in the network. As such, this document does not introduce any new security considerations. </OLD> <NEW (third line)> This document introduces SRv6 Endpoint and SR Policy Headend behaviors for implementation on SRv6 capable nodes in the network. The headend policy definition should be consistent with the specific behavior used and any local configuration (as specified in Section 4.1.1). As such, this document does not introduce any new security considerations. </NEW> ... > > (3) The description of the flavors in §4.16 is also unclear. > ... > For an endpoint behavior that indicates more than one flavor, which > one should be applied? > > For some of the behaviors, 29 (End with PSP&USD) for example, the > flavor used seems to depend on the number of SLs: if received with SL > == 0, then the flavor is USD, but if received with SL == 1 then use > PSP. But for other behaviors, 30 (End with USP&USD) for example, which > flavor should be applied if both are supported? > [PC2] When a behavior (e.g. End) is combined with one or more flavors (e.g. [PC2] USP & USD), their combined pseudocode is what determines the packet [PC2] processing. In the specific example of USP&USD (when SL=0), the [PC2] pseudocode would end up first removing the processed SRH and then, [PC2] depending on the next upper-layer header, also removing the outer IPv6 [PC2] encapsulation header if/when there is an inner IP packet. Oh, it's the combination; that is not mentioned anywhere. [PC3] Currently we have the following text present in 4.16. > The End, End.X and End.T behaviors can support these flavors either > individually or in combinations. Thank you for your time! _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
