On February 16, 2022 at 1:28:43 PM, Ketan Talaulikar wrote:
Ketan: Hi! > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I am balloting DISCUSS because the document underspecifies the use of > > Endpoint Behaviors. As a result, it is unclear when they should be checked, > > enforced, or needed. Details follow. > > > > > > The descriptions of the TLVs in §2 say (twice) that the "SRv6 Endpoint > > behaviors which MAY be encoded, but not limited to, are...etc." > > > > The text above ends with "etc." which means there are other possible > > behaviors. That's not a great use of normative language, even if optional. > > KT> Agree. We have removed the "etc". Ok. Given the rest of the text, I think that "MAY" is just expressing a fact, not a normative action: s/MAY/may > > My initial instinct was to ask you to be specific, BUT... > > > > The description of the SRv6 SID Information Sub-TLV (§3.1) says that "an > > unrecognized endpoint behavior MUST NOT be considered invalid", which seems > > to mean that any behavior is ok, AND... > > > > There's no validation specified, except for the description of the SRv6 SID > > Structure Sub-Sub-TLV (§3.2.1), where it says that the "Argument length > > MUST be set to 0 for SIDs where the Argument is not applicable". AND... > > > > Several of the service descriptions in §5/§6 say that "The SRv6 Endpoint > > behavior of the SRv6 SID is entirely up to the originator of the > > advertisement. In practice, the SRv6 Endpoint behavior is..." > > > > > > The result is that any endpoint behavior (even unrecognized) can be used, > > while also requiring a specific setting for the argument length in some > > cases. > > > > How can the argument length be validated if the endpoint behavior is > > unknown? > > KT> The argument length cannot be validated unless the endpoint behavior is > known. The ingress PE needs to actually write the ARG part of the SID into > the SRv6 SID advertised by the egress PE when sending packets for that > service to the egress PE. Therefore, knowing that the behavior involves > argument and validating the argument length is important. We have clarified > this in the text. I see that the text in -11 now says this: Arguments may be generally applicable for SIDs of only specific SRv6 Endpoint behaviors (e.g., End.DT2M) and therefore the Argument length MUST be set to 0 for SIDs where the Argument is not applicable. A receiver is unable to validate the applicability of arguments for SRv6 Endpoint behaviors that are unknown to it and hence MUST ignore SRv6 SIDs with arguments (indicated by non-zero argument length) with unknown endpoint behaviors. That works for me. It addresses the cases when the Behavior is unknown -- the questions below are about known and expected Behaviors. > > 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? > > > > What should the receiver do if the endpoint behavior is known and > > applicable, but the attribute length is not set correctly? > > KT> Could you clarify which attribute length you are referring to? Sorry, I meant the argument... :-( > > 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? ... > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- ... Just one comment: ... > > (8) §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. > > > > Is it ever ok for the SID to not be routable? If so, when? The "purpose of > > providing reachability" requires the SID to be routable. IOW, why is this > > behavior recommended and not required? > > KT> An SRv6 SID may not be routable across multiple IGP domains within a > provider network when routes are not leaked. There can be other mechanisms > like SR Policies (or other forms of tunneling) that provide reachability. In > other scenarios, due to local policy, the resolution may be desired over an > SR Policy instead of the best-effort reachability provided by IGPs. If there's a route over a tunnel/SR Policy/whatever, I consider that routable. I am not just thinking about IGP-learned routes. The case that concerns me is when the ingress PE doesn't have a route at all (which is possible with the SHOULD). If a route should always exist (from any source) then it looks like the text should indicate a requirement and not a recommendation. Thanks for addressing my other comments. Alvaro. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
