Hi Alvaro, We've just posted the update with the text changes as suggested by you: https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-13
Thanks again for your review and input to improve the document. Thanks, Ketan On Thu, Mar 17, 2022 at 11:32 PM Ketan Talaulikar <[email protected]> wrote: > 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
