On February 18, 2022 at 10:53:20 AM, Ketan Talaulikar wrote: Hi!
We're still not on the same page. [Cut the indentation to make it more readable.] > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > ---------------------------------------------------------------------- > > > > > > > > Clearly (from looking at rfc8986), not all endpoint behaviors apply to > > > > the services defined in this document. Should a receiver accept any > > > > endpoint behavior? What should a receiver do if a known but unrelated > > > > behavior (End, for example) is received? > > ... > > > > For any specific service (IPv4 VPN Over SRv6 Core, for example, to pick > > > > one), should the behaviors used "in practice" be enforced? What if > > > > different behavior is advertised? Can it safely be ignored? > > > > These two are related: Should only specific behaviors (per service) be > > accepted? > > > > If yes, I need you to specify which are those behaviors and what > > happens if a different (known) one is received. > > > > If no, what does it mean for the service if an unrelated behavior is > > advertised? > > KT> So, this would be a result of a bug (?) on the egress PE that signals a > wrong behavior. Since the receiver is not validating, the service traffic > would still arrive at the egress PE but the handling might be erroneous due > to wrong behavior. The issue still manifests on the egress PE due to its bug. > Somewhat similar to what might happen if the egress PE were to signal a label > associated with a wrong context/service as a VPN label in MPLS VPNs. Verifying that a label is correct is not the same as confirming that the Behavior is plausible for the service. I understand how the ingress PE cannot validate an unknown Behavior, but not validating a known Behavior is not right. If the Behavior is unknown, the ingress doesn't have any idea of what the egress may do, but if the Behavior is known, it does! §2 lists Behaviors that may correspond to L2/L3 Services. The subsections in §5 and §6 list the Endpoint Behaviors used "in practice" for each of the services. This is what I would like to see: For example, §5.1 (IPv4 VPN Over SRv6 Core) says that "In practice, the SRv6 Endpoint behavior is End.DX4 or End.DT4." The ingress PE should then be able to validate that the Endpoint Behavior is one of these...and take appropriate actions if it isn't. Why is that not the case? Not taking this simple step opens up (as you mention) the possibility of a bug creeping in, but also the ability of the egress to signal any behavior which could result in an unexpected or incorrect action. This type of checking is the minimum that should be done. ... > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > -------------------------------------------------------------------- ... > KT> I believe we were discussing the part of the "SID being routable" as in > via routing protocol (i.e. IGP/BGP transport). The next paragraph is one that > covers the base BGP "resolvability" part and does elaborate on the various > mechanisms like "alternate steering mechanisms" (e.g. any tunnel, SR Policy, > etc.). Yes (let me reset a little) -- this is the current text (from §5): The SRv6 Service SID SHOULD be routable within the AS of the egress PE and serves the dual purpose of providing reachability between ingress PE and egress PE while also encoding the SRv6 Endpoint behavior. When steering for SRv6 services is based on shortest path forwarding (e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header (using H.Encaps or H.Encaps.Red flavors specified in [RFC8986]) where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. The resolvability is evaluated as per [RFC4271]. If the SRv6 SID is reachable via more than one forwarding table, local policy is used to determine which table to use. The result of an SRv6 Service SID resolvability (e.g., when provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE. The details of such steering mechanisms are outside the scope of this document. My point is that it is a requirement for the SID to be reachable -- independent of how it is resolved: IGP, BGP, "alternate steering mechanisms", etc. Otherwise it can't be used. If we agree with that then the requirement should be reflected in the text: s/SHOULD/MUST/g Thanks! Alvaro. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
