On February 18, 2022 at 12:23:03 AM, Ketan Talaulikar wrote:
Hi! > > > > ---------------------------------------------------------------------- > > > > 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? > > > > 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... :-( > > KT> The behavior definition may or may not specify requirements of argument > lengths - the currently defined ones do not pose any limitation and so the > draft talks about zero or non-zero. We can clarify by saying something on the > lines that for behaviors where arguments apply, the argument length's > consistency must be verified against the behavior definition. Would that > address your comment? Yes, it would. Also, if the verification fails then what? > > > > ---------------------------------------------------------------------- > > > > 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. > > KT> The should is to allow for use-cases such as the one specified in > https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing- > policy-18#section-8.5 - in this case, there may not be any reachability but > the local policy indicates triggering a request to a controller to compute SR > Policy path to the BGP NH on demand and then the resolution can happen once > such an SR Policy is successfully instantiated on the node. The end result is that the SID MUST be reachable before the ingress node can do anything with it. As you say: "the resolution can happen once such an SR Policy is successfully instantiated on the node". The mechanisms to provide that resolution (IGP, manual configuration, controller, etc.) is independent of the requirement for there to be reachability. Alvaro. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
