Hi Alvaro, Thanks for your quick response and please see further inline below.
We will include these changes in the next update of the draft. On Fri, Feb 18, 2022 at 12:30 AM Alvaro Retana <[email protected]> wrote: > 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 > KT> Ack > > > > > 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. > KT> Thanks > > > > > > 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... :-( > 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? > > > > > 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. > 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. > > > Thanks for addressing my other comments > > Alvaro. > Thanks, Ketan
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
