Hi Alvaro, Many thanks for the very prompt review and feedback. Inline with [PC2]. (Note that I’ve posted rev23 with some changes as per comments below)
Cheers, Pablo. https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-23 -----Original Message----- From: Alvaro Retana <[email protected]> Sent: martes, 29 de septiembre de 2020 0:50 To: The IESG <[email protected]>; Pablo Camarillo (pcamaril) <[email protected]> Cc: Joel Halpern <[email protected]>; [email protected]; Bruno Decraene <[email protected]>; [email protected]; [email protected] Subject: RE: Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT) On September 25, 2020 at 2:28:53 PM, Pablo Camarillo wrote: Pablo: Hi! I still have a couple of comments related to the DISCUSS portion. And some non-blocking comments later on. I looked at -22. Thanks! Alvaro. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- I think we need some more discussion on 1c, 3b, 3d. 3e-3g can be resolved with a more text on the expected types of use cases. See more below. ... > (1b) It would be nice if the behavior in §4.1.1 were also specified > using pseudocode. As written, I am not sure if the intent is to > process any upper-layer header or only specific ones. Is the objective > for this operation to be similar to the one in §4.3.1.2/rfc8754? > Please be specific on what is meant by "allowed by local configuration". > [PC] Yes, we can structure the text in 4.1.1 in pseudocode form. The [PC] processing is not the same as RFC8754/Section 4.3.1.2. The “allowed by [PC] local configuration” is to enable the processing of only specific types [PC] of Upper-layer Headers for packets addressed to an SRv6 SID of the [PC] specific behaviors. E.g. An operator may not wish to have BGP sessions [PC] (or in general any TCP traffic) destined to a local SID, but may want to [PC] enable ICMPv6 packet processing for OAM purposes. ... §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 implementation. Whether an implementation implements the local configuration on an interface as an ACL or globally for all SIDs or per SID via some API is not for this document to decide, and has no impact on interoperability. ... > (1c) §4.4/§4.6: S01 of the second piece of pseudocode is an > instruction for processing a non-IPv6 upper header. However, earlier > in that section, it is specified that the SID "is associated with one > or more L3 IPv6 adjacencies/an IPv6 FIB table". How can the upper > header not be IPv6 if the specification explicitly says it has to be? > [PC] The pseudocode is convoluted. I propose to turn it around for 4.4, 4.5, [PC] 4.6 and 4.7. As an example with 4.4: ... I still have the same question. For example, in §4.4/End.DX6, I don't understand under which conditions the upper-layer won't be IPv6. The behavior in §4.1.1 now starts by saying: "Upper-Layer Header type is allowed by local configuration". Same question: For example, for End.DX6, when would something other than IPv6 be allowed by local configuration? It seems to me that if the behavior "is associated with one or more L3 IPv6 adjacencies", then the contents should either be IPv6 or be discarded. Otherwise the sender may include something else (IPv4, for example) and it may be forwarded... I may be missing something obvious, I just don't know what. [Similar concerns for other sections where the payload is sent to §4.1.1 if the contents don't match what the behavior expects.] [PC2] One common example is to allow ICMPv6 processing for packets destined to an End.DX6 SID (or any of the other behaviors) for OAM operations (e.g. ping to that SID). ... > (3) The description of the flavors in §4.16 is also unclear. ... > (3b) If a behavior with more than one flavor is signaled, how should > the receiving node determine which one to apply? I guess that the > application of behaviors 4 or 29 depends on the number of SLs -- the > expected behavior should be clearly specified. > [PC] The segment endpoint node receiving a packet destined to a SID with [PC] behavior 4 applies only the processing associated with the SID (I.e. [PC] behavior 4). Sorry, I mixed up some of the terminology. Let me try this one again. 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. USP & USD), their combined pseudocode is what determines the packet processing. In the specific example of USP&USD (when SL=0), the pseudocode would end up first removing the processed SRH and then, depending on the next upper-layer header, also removing the outer IPv6 encapsulation header if/when there is an inner IP packet. ... > (3d) §4.16.1.2: > > When a SID of PSP-flavor is processed at a non-penultimate SR Segment > Endpoint Node, the PSP behavior is not performed as described in the > pseudocode below since Segments Left would not be zero. > > For example, for the End behavior, I'm assuming that behavior 1 is > performed instead of 2 (or 4, or 29, or 31) if SL != 0. Should this be > done even if the node did not advertise the non-PSP flavor? > [PC] If a SID of END behavior (1) is instantiated at a segment endpoint node, [PC] a packet destined to that SID will only ever be processed with behavior [PC] 1. Redo: If the SID used indicates behavior 2 (End with PSP), but the node is the last one (not the penultimate one), then what should it do? This result is probably an error from the sender. Should the receiver drop the packet, or process as behavior 1? Assuming that the node instantiated SIDs for both behaviors. [PC2] The result is not an error from the sender. Since the node is the 'last one', I'll take that to mean that SL=0. When processing the SRH, lines S02/S03 of the END pseudocode says to "stop processing the SRH and proceed to process the next header". So the PSP processing defined starting at S14.1 never occurs. ... > (3e) §4.16.2 describes the USP flavor, which is one where the endpoint > consumes the packet by processing the next header. I don't understand > how the outcome due to the extended process is different from the > original one in §4.1. Can you please explain? It seems to me that the > externally observable result is the same. > [PC] We have use-cases where the packets with SRH may be destined to [PC] applications or host implementations running in containers. The USP [PC] flavor is useful to remove the consumed SRH from the extension header [PC] chain before sending over to the application stack – we’ve seen this [PC] with smartNICs. As such the perspective on externally observability [PC] differs and hence we believe it is needed to specify this. Ok. Please include the use case so that it is clear to others that the external behavior is different. [PC2] Sure. I’ve included the following text in rev23. <NEW> One of the applications of the USP flavor is when a packet with an SRH is destined to an application on hosts with smartNICs implementing SRv6. The USP flavor is used to remove the consumed SRH from the extension header chain before sending the packet to the host. </NEW> > I have the same question about the USD flavor and the externally > observable behavior related to §4.1. > [PC] The USD flavor specifically enables the de-encapsulation of inner IP [PC] packet and its further forwarding (consider use-case like TI-LFA where [PC] encapsulation is done on the PLR and de-encapsulation has to be done on [PC] the last node of the repair list). In this case the PLR node that is [PC] crafting the SID list wants to ensure that the last segment in the [PC] repair list is able to perform decapsulation. Ok. Please include the use case... [PC2] Sure. I've included the following text in rev23. <NEW> One of the applications of the USD flavor is the case of TI-LFA in P routers with encapsulation. The USD flavor allows the last Segment Endpoint Node in the repair path list to decapsulate the IPv6 header added at the TI-LFA Point of Local Repair and forward the inner packet. </NEW> > In general, the observable behavior of §4.1, USP, and USD seem the > same to me. > The next two points are related. > > (3f) §4.16.3 describes the USD flavor, which assumes that the > decapsulation results in a packet that can be forwarded. Can the FIB > lookup result in a local destination? > [PC] Please refer the previous comment about the use-case and so yes, we [PC] normally expect the decapsulation results in a packet that is forwarded [PC] out. However, the inner packet may also be destined to a local address. Just to make sure I understand, if it is ok for the destination to be a local address then the external observable behavior is equivalent to End, right? [PC2] Not quite. In order to get the same externally observable behavior you would need to configure the END Upper-layer header processing defined in 4.1.1 to allow decapsulation and processing of inner IP packets. Only in that case you would get the same externally observable behavior. This seems to be orthogonal to whether the destination of the inner packet is a local address or not. > (3g) Does the USD flavor mean that, for the End behavior (as described > in §4.1), the action of "process the next header in the packet" cannot > result in a forwarded packet? Same question for the USP behavior? > [PC] Please refer to the previous comments. There is no such assumptions on [PC] neither the base End behavior nor End with USP. Right...here again, the external behaviors may then be the same. I see how there may be differences, in line with the use cases, and how some of the behaviors may end up being the same...sometimes. Let's then add sample use case information and move on. [PC2] Indeed, I see your point. Added the information on the applications as per the replies above. ... > (4) §10.2 creates a new registry with an "FCFS" registration procedure. ... [PC] Indeed, the current text is wrong. My bad. I've updated the text with [PC] this diff below. Also, I’m not sure whether that paragraph is really [PC] needed. Maybe just putting in the table “First Come First Served [PC] [RFC8126]” is sufficient as RFC8126 already describes what is written in [PC] the text below. If it can be removed please let me know. Yes, I think you don't need the additional paragraph. [PC2] Thanks for the confirmation. Removed in rev23. ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- We may need to talk a little bit more about 5. ... > (2) All the examples in §3.2 have a /48 prefix allocated to the SRv6 > deployment (and then /64s per node). Is it possible to start with a > different SRv6 infrastructure allocation, a /64, or /96 maybe? If so, > please include an example. If not, please explain any limitations. > [PC] The examples are based on real deployments and as such reflect the [PC] practical aspects of those operators SRv6 infrastructure allocation [PC] designs. It would be counter-productive and misleading to provide [PC] artificially manufactured examples (and then why just /96 and not [PC] something else?). The document does not pose any limitations. I don't see how it can be misleading to provide a different example. The fact that all the examples have similar assumptions might give the impression that a limitation exists. I defer to you/AD. [PC2] Sure. We have also added text to indicate that these examples do not preclude other addressing and allocation schemes. <NEW>These examples do not preclude any other IPv6 addressing allocation scheme.</NEW> ... > (5) §4.11/§4.12 "S05. Learn the exposed MAC Source Address..." > > The note related to this step says that in "EVPN, the learning...is > done via the control plane"...but here it is done via the data plane. > What, if any, is the effect on EVPN operation? Are there issues with > learning conflicting information from different sources? It seems to > me that it could be relatively easy to spoof the source and create > unexpected entries in the L2 table. Please point to the EVPN documents > where this type of operation is considered. > [PC] Indeed, text is inaccurate. I've updated the note to the following: [PC] [PC] S03. In EVPN RFC7432, the learning of the exposed MAC Source Address is [PC] done via control plane. In L2VPN VPLS RFC4761 RFC4762 reachability is [PC] obtained by standard learning bridge functions in the data plane. I'm not sure if the updated note means that S03 doesn't apply to EVPN, or if it just confirms that EVPN expects to learn from the control plane. ?? [PC2] Both. In EVPN learning occurs via control plane, hence the EVPN process does not leverage line S03. In L2VPN VPLS the reachability is learned through learning bridge function in the dataplane (hence leveraging line S03). ... > (15) §8: A rogue node inside the SR domain may (on purpose) signal the > wrong behavior for a flow, which may result in the delivery of the > traffic to the wrong destination (potentially including destinations > outside the domain), among other things. Note that this action is > possible even if the rogue node is authenticated and authorized to > generate an SRH. I didn't find this threat mentioned in rfc8402/rfc8754. > [PC] The control plane protocol specifics are outside the scope of this [PC] document. I am not able to parse this comment and what is it that needs [PC] to be addressed in this document. Sorry, let me try again: In the data plane... A rogue SR headend may, on purpose, use the wrong endpoint SID. For example, an endpoint may support End.DT6 for several IPv6 tables. If the wrong SID is used, then the wrong table may be used to forward the packet. If multiple tenants have overlapping addresses, the packet may then be forwarded to the wrong destination. I believe that this is a new vulnerability introduced my this document that cannot be mitigated using the HMAC TLV, for example. IOW, the draft assumes that the SRH will be populated with the correct SIDs, but that may not always be the case if a node has been overtaken. There's not much that can be done to mitigate this issue, but I think it is important to mention. [PC2] I am trying to follow the point of this discussion. This is exactly the same in MPLS today -or in VxLAN, …-, no? If an Ingress PE sets the wrong Service label on the packet, then the packet will be sent to the wrong VPN instance, no? > (16) §9.4: I'm not sure what the purpose of §9 is, as a whole. But the > summary in §9.4 puzzles me more; what is the intent? Does Table 1 > indicate that, for example, an IGP implementation should not advertise > the End.B6.Encaps behavior? > Does Table 2 indicate that only BGP-LS should signal the ability to > H.Encaps.L2? I am confused about the value/intent because the text > clearly says that the control plane is outside the scope of this document. > [PC] The section provides an overview of the role of control plane routing [PC] protocols in the advertisements of the SRv6 Locator and the SIDs along [PC] with their behaviors – all new aspects that have been introduced in this [PC] document. Based on the SRv6 solutions developed around the behaviors [PC] introduced in this document, it indicates what information is expected [PC] to be advertised via which protocol. It does not describe “how” since [PC] that is clearly outside the scope of this document and part of the [PC] individual routing protocol extensions. "it indicates what information is expected to be advertised via which protocol" So...does that mean that an IGP is not expected to advertise H.Encaps.L2, or that it cannot advertise it? I'm trying to figure out if there is any normative expectation -- I'm assuming not because it's been said several times that the control plane if out of scope. If the control plane is not bound by whatever this section says, then why do we even have it? [PC2] This document provides a high-level view of how control plane protocols may interact with this document. This document provides what would be a logical control-plane advertising. That said, this document is not introducing any normative requirement/limitation for control planes. To your question of why having it: if I would be reading this from scratch, I would first read the SRH and then NET-PGM. After reading NET-PGM I would go into the specific routing protocol documents. To me it would be nice to already in NET-PGM provide a bit of an overview of what to expect in each one of those…even if this is not normative text. I noticed that you wrote that the text is "Based on the SRv6 solutions developed around the behaviors introduced in this document", which I guess means that this is a reflection of the existing control plane drafts (??). If that is the case, then, at best, this seems like an attempt to put the carriage in front of the horses, knowing what the outcome may be, but without making reference to them. I still don't see the value. This is a non-blocking point -- I think this section can be removed and the value of the document wouldn't be reduced. I will defer to Martin. [PC2] I believe this section eases the reading of this document and the associated ones; but I agree that this section is not giving any normative definition. I understand your point, but I do think it has value. I’ll check with Martin. Thank you for your time. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
