Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

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.



...
> (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.]



...
> (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?



...
> (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.



...
> (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.


> 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...


> 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?


> (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.



...
> (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.



...
> ----------------------------------------------------------------------
> 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.


...
> (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.  ??



...
> (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.



> (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?

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.