Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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 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, > 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 < >> nore...@ietf.org> 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 >> MPL
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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, 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 < > nore...@ietf.org> 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 > E
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
Hi Alvaro, We've posted an update to address some of your comments below. Please see inline below for responses and would appreciate your suggestions to address any outstanding issues. https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-12 On Sat, Feb 19, 2022 at 3:58 AM Alvaro Retana wrote: > On February 18, 2022 at 10:53:20 AM, Ketan Talaulikar wrote: > > Hi! > > We're still not on the same page. > > > [Cut the indentation to make it more readable.] > > > > > > > -- > > > > > 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? > > > > KT> So, this would be a result of a bug (?) on the egress PE that > signals a > > wrong behavior. Since the receiver is not validating, the service traffic > > would still arrive at the egress PE but the handling might be erroneous > due > > to wrong behavior. The issue still manifests on the egress PE due to its > bug. > > Somewhat similar to what might happen if the egress PE were to signal a > label > > associated with a wrong context/service as a VPN label in MPLS VPNs. > > Verifying that a label is correct is not the same as confirming that > the Behavior is plausible for the service. > > I understand how the ingress PE cannot validate an unknown Behavior, > but not validating a known Behavior is not right. If the Behavior is > unknown, the ingress doesn't have any idea of what the egress may do, > but if the Behavior is known, it does! > KT> My concern is with us getting into very loosely and not well-defined validation at the ingress - that too when the ingress doesn't need to bother about the local behavior (except for those with arguments) applied at the egress. It is better for extensibility and interoperability to not do validation instead. This will enable the smooth and easier introduction of new behaviors on the egress as long as there is no hard dependency on the ingress. Please see further below. > > §2 lists Behaviors that may correspond to L2/L3 Services. The > subsections in §5 and §6 list the Endpoint Behaviors used "in > practice" for each of the services. > > This is what I would like to see: For example, §5.1 (IPv4 VPN Over > SRv6 Core) says that "In practice, the SRv6 Endpoint behavior is > End.DX4 or End.DT4." The ingress PE should then be able to validate > that the Endpoint Behavior is one of these...and take appropriate > actions if it isn't. Why is that not the case? Not taking this > simple step opens up (as you mention) the possibility of a bug > creeping in, but also the ability of the egress to signal any behavior > which could result in an unexpected or incorrect action. > KT> Since the SRv6 SID belongs to and is instantiated on the egress, it can signal any behavior. E.g. tomorrow someone may define behavior that subjects the packet received at the egress router to be submitted to Firewall/DPI before being forwarded to the CE. Except for behaviors with arguments where the ingress needs to know in order to supply the argument values, there is nothing behavior-specific that the ingress needs to do. We have clarified the latter in the updated text. > > This type of checking is the minimum that should be done. > KT> We can add text for some checking for the purpose of raising warnings/alerts for the operator if that helps. > > > > ... > > > > > > -- > > > > > COMMENT: > > > > > > > ... > > KT> I believe we were discussing the part of the "SID being routable" as > in > > via routing protocol (i.e. IGP/BGP transport). The next paragraph is one > that > > covers the base BGP "resolvability" part and does elaborate on the > various > > mechanisms like "alternate steering mechanisms" (e.g. any tunnel, SR > Policy, > > etc.). > > Yes (let me reset a little) -- this is the current text (from §5): > >The SRv6 Service SID SHOULD be routable within the AS of the egress >PE and serves the dual purpose of provid
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
On February 18, 2022 at 10:53:20 AM, Ketan Talaulikar wrote: Hi! We're still not on the same page. [Cut the indentation to make it more readable.] > > > > -- > > > > 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? > > KT> So, this would be a result of a bug (?) on the egress PE that signals a > wrong behavior. Since the receiver is not validating, the service traffic > would still arrive at the egress PE but the handling might be erroneous due > to wrong behavior. The issue still manifests on the egress PE due to its bug. > Somewhat similar to what might happen if the egress PE were to signal a label > associated with a wrong context/service as a VPN label in MPLS VPNs. Verifying that a label is correct is not the same as confirming that the Behavior is plausible for the service. I understand how the ingress PE cannot validate an unknown Behavior, but not validating a known Behavior is not right. If the Behavior is unknown, the ingress doesn't have any idea of what the egress may do, but if the Behavior is known, it does! §2 lists Behaviors that may correspond to L2/L3 Services. The subsections in §5 and §6 list the Endpoint Behaviors used "in practice" for each of the services. This is what I would like to see: For example, §5.1 (IPv4 VPN Over SRv6 Core) says that "In practice, the SRv6 Endpoint behavior is End.DX4 or End.DT4." The ingress PE should then be able to validate that the Endpoint Behavior is one of these...and take appropriate actions if it isn't. Why is that not the case? Not taking this simple step opens up (as you mention) the possibility of a bug creeping in, but also the ability of the egress to signal any behavior which could result in an unexpected or incorrect action. This type of checking is the minimum that should be done. ... > > > > -- > > > > COMMENT: > > > > ... > KT> I believe we were discussing the part of the "SID being routable" as in > via routing protocol (i.e. IGP/BGP transport). The next paragraph is one that > covers the base BGP "resolvability" part and does elaborate on the various > mechanisms like "alternate steering mechanisms" (e.g. any tunnel, SR Policy, > etc.). Yes (let me reset a little) -- this is the current text (from §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. When steering for SRv6 services is based on shortest path forwarding (e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) to the egress PE, the ingress PE encapsulates the IPv4 or IPv6 customer packet in an outer IPv6 header (using H.Encaps or H.Encaps.Red flavors specified in [RFC8986]) where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. The resolvability is evaluated as per [RFC4271]. If the SRv6 SID is reachable via more than one forwarding table, local policy is used to determine which table to use. The result of an SRv6 Service SID resolvability (e.g., when provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows an alternate steering mechanism to reach the egress PE. The details of such steering mechanisms are outside the scope of this document. My point is that it is a requirement for the SID to be reachable -- independent of how it is resolved: IGP, BGP, "alternate steering mechanisms", etc. Otherwise it can't be used. If we agree with that then the requirement should be reflected in the text: s/SHOULD/MUST/g Thanks! Alvaro. ___ BESS mailing list BESS@ietf.org https://www
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
Hi Alvaro, Please check inline below for a few responses. On Fri, Feb 18, 2022 at 5:52 PM Alvaro Retana wrote: > 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? > KT> So, this would be a result of a bug (?) on the egress PE that signals a wrong behavior. Since the receiver is not validating, the service traffic would still arrive at the egress PE but the handling might be erroneous due to wrong behavior. The issue still manifests on the egress PE due to its bug. Somewhat similar to what might happen if the egress PE were to signal a label associated with a wrong context/service as a VPN label in MPLS VPNs. > > > > > > > > > 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. > KT> Thanks. > > Also, if the verification fails then what? > KT> That is already covered by the existing text in sec 8 - such a route would be considered ineligible during the selection of the best path by the receiver. > > > > > > > > > -- > > > > > 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.)
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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 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
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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 sh
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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 < nore...@ietf.org> 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 so
[bess] Alvaro Retana's Discuss on draft-ietf-bess-srv6-services-10: (with DISCUSS and COMMENT)
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. 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? 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? 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? -- 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? 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. (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. (3) §3.1: "SRv6 Endpoint Behavior...The opaque endpoint behavior (i.e., value 0x)...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. (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? (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? (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 (7) §5: s/MUST choose to perform IPv6 encapsulation/MUST perfor
