Hi Alvaro, Regarding your discussion point, we will clarify the text related to behaviour usage for each service and for handling of unknown/new behaviour.
I'll post the update when the submission window opens next week. Thanks, Ketan On Wed, 16 Feb, 2022, 11:58 pm Ketan Talaulikar, <[email protected]> wrote: > Hi Alvaro, > > Thanks for your detailed review and comments. Please check inline below > for responses. > > We have also posted an update for the draft to address comments from you > and other reviewers: > https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-11 > > > On Tue, Feb 15, 2022 at 11:29 PM Alvaro Retana via Datatracker < > [email protected]> wrote: > >> Alvaro Retana has entered the following ballot position for >> draft-ietf-bess-srv6-services-10: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/ >> >> >> >> ---------------------------------------------------------------------- >> 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". > > >> 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. > > >> >> 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? > > >> >> 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? >> >> Why is the Endpoint Behavior included in the Sub-TLV if (from the above) >> it >> looks like it doesn't matter? >> > > KT> The endpoint behavior is something that is associated with the SID > instantiated on the Egress PE. In most cases for VPN services, the ingress > PE simply needs to use the SID to send the packet to the egress PE. This is > much like how a context/instruction is associated with the VPN label for > MPLS - it could be per-vrf or per-ce or per-prefix - normally the ingress > PE does not care. However, with SRv6, we have behaviors that have arguments > that do require the ingress PE to be aware since it needs to set up the ARG > part of the SID in the packet encapsulation. In certain other cases, the > knowledge of the behavior on the ingress PE could enable local optimization > which we do want to preclude. Having the ability to signal the SRv6 > Endpoint behavior also helps in troubleshooting and monitoring. > > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> (1) To make sure, the new "BGP SRv6 Service SID Flags" registry is >> intended to document the allocations for the "SRv6 SID Flags" field in the >> SRv6 SID Information Sub-TLV (§3.1), right? >> > > KT> Correct. > > >> >> Please say so somewhere. It would also be nice if the name of the field >> (SRv6 >> SID Flags) and the registry (SRv6 Service SID Flags) matched. I realize >> that >> fitting the full name in the figure won't work, but you can either use >> multiple >> lines (as you have already) or call the field simply "Flags," then extend >> to the full name in the description of the field...or many other ways to >> avoid >> confusion. >> > > KT> We have fixed the figure and description to match the registry name. > > >> >> >> (2) §3.1: >> >> SRv6 SID Flags (1 octet): Encodes SRv6 SID Flags - none are >> currently defined. SHOULD be set to 0 by the sender and MUST be >> ignored by the receiver. >> >> If/when the flags are defined, the behavior specified here won't be >> compatible. >> Instead, a behavior that assumes that some of the flags will be known in >> the >> future would be better. For example: any unknown flags MUST be ignored >> by the >> receiver. >> > > KT> Ack. Fixed. > > >> >> >> (3) §3.1: "SRv6 Endpoint Behavior...The opaque endpoint behavior (i.e., >> value >> 0xFFFF)...MUST NOT be considered invalid by the receiver." >> >> Ok, but the opaque behavior is not defined as invalid in rfc8986 or >> anywhere >> else (AFAIK). rfc8986 includes a note specifically for the cases in >> this document in §8.3. So this requirement is not needed. >> > > KT> Ack. It is covered by RFC8986. We have rephrased the sentence. > > >> >> >> (4) §3.2.1: "Transposition Length of 0 ... In this case, the Transposition >> Offset MUST be set to 0." >> >> What should the receiver do if the offset is not set to 0? >> > > KT> If the checks in sec 3.2.1 fail, then the error handling is done as > per sec 8. Please also see the next response. > > >> >> >> (5) §3.2.1: According to rfc8986, the sum of the Loc + Func + Agr <= >> 128. The >> inclusion of the transposition fields changes the formula to add the new >> length. Please indicate the new constraints. What should the receiver >> do if >> the sum of the lengths is not <= 128? >> > > KT> Ack. We have added the constraints for the fields of this sub-sub-tlv > as also the clarification for handling in sec 8. > > >> >> >> (6) §3.2.1: "Arguments MAY be generally applicable for SIDs of only >> specific >> SRv6 Endpoint behaviors" In this case, "MAY" is just stating a fact >> (specified >> in rfc8986): s/MAY/may >> > > KT> Ack. Fixed. > > >> >> >> (7) §5: s/MUST choose to perform IPv6 encapsulation/MUST perform IPv6 >> encapsulation >> >> To choose is not normatively enforceable; encapsulating is. >> > > KT> Ack. Fixed. > > >> >> >> (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. > > >> >> >> (9) Both §5/§6 say that the "ingress PE SHOULD perform resolvability >> check for >> the SRv6 Service SID before considering the received prefix for the BGP >> best >> path computation." >> >> By "resolvability check", do you mean the "Route Resolvability Condition" >> from >> §9.1.2.1/rfc4271?? If so, please be explicit. >> >> Given that we're talking about services, which table should be used to >> resolve >> the SID? This question is something that rfc4271 doesn't cover [1]. >> Please add >> something similar to this text from rfc9012 (where the resolvability >> condition >> is mentioned): >> >> The reachability condition is evaluated as per [RFC4271]. If the IP >> address is reachable via more than one forwarding table, local policy >> is >> used to determine which table to use. >> > > KT> Ack. Updated the text. > > >> >> [1] >> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-bestpath-selection-criteria >> >> >> (10) [nits] >> >> s/multiple instances...is encountered/multiple instances...are >> encountered/g >> > > KT> Ack. Fixed. > > >> >> Please add figure numbers to all the packet formats, etc. >> > > KT> Ack. Fixed. > > Thanks, > Ketan > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
