Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Bruno, On 20/10/2020 14:47, bruno.decra...@orange.com wrote: Peter, From: Peter Psenak [mailto:ppse...@cisco.com] Bruno, please see inline: On 20/10/2020 11:43, bruno.decra...@orange.com wrote: Peter, From: Peter Psenak [mailto:ppse...@cisco.com] Bruno, On 19/10/2020 18:52, bruno.decra...@orange.com wrote: Ron, all, >From a use case standpoint, I have a use case for having both SR-MPLS and IP flexalgo in the same network. >From a protocol standpoint, I think that the functionality could be equally met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) to instruct the LER/LSR to not use a label in the forwarding plane. (while still advertising a label in the control plane because we have to). does not work, I could provide more explanations, but reading your email, it seems to me that you understood the proposal. So it seems to me that the opinion that you really meant is: it works but it would be an nasty hack. Regarding "nasty hack" it could be interesting to have a normative definition. This could prove useful in some other contexts. BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI... max-metric does not solve the problem, as you would need a prefix metric for non 0 algo anyway. To clarify, my text was not a technical proposal related to that draft. It was referring to your email and questioning what exactly was a hack using some examples from the past. But let's forget about this point, at least for the moment. Coming back to technical comments, note that creating yet another TLV to carry IP prefix also brings questions that the draft does not answer or even raise. - What about the sub-TLVs? Are they shared with the existing registry for prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier (we would have two algo fields, two ways to signal SIDs...) yes, these are details that needs to be addressed, but should not be a problem. Look at locator TLV in SRv6, very similar concept here. - for IPv6, the content and meaning of "ISIS MT IPv6 Flexalgo Prefix Reachability TLV" is essentially the same than the "SRv6 Locator TLV". - Only the naming and the ordering of the fields are different. - Why do we need two TLVs to advertise the same thing (essentially a Routing Algo)? Duplication means more spec, more code, more features to implement, more error and bugs. (and it did not took long: the draft defines the MTID field as 8 bits while RFC 5120 defines it a 12 bits. well, locator is a construct that is specific to SRv6. Sure you can advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs and achieve the same thing - I have already mentioned that in one of my responses, but that is again ugly. So we agree that reusing the SRv6 locator TLV would work and provide the functionality. Good. Now here comes again the "ugly" argument. If it's now becoming a technical argument, in my opinion, it's ugly to define two TLVs in order to advertise the same information and to provide the same functionality. - What is the functional different between FlexAlgo for SRv6 and FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the IPv6 FIB in the router. they are functionally the same. Good to agree on this. I believe that having a clean encoding is preferable in a long run. What do you mean by "clean encoding"? The only differences between both TLVs are the naming and the ordering of the fields. One can not advertise a prefix as SRv6 locator as well as IP flex-algo prefix (that would be an error), so duplication of data is not an issues. So one should not advertise both TLVs? If so this becomes an error/issue? This feels like my point. There is no such issue with a single TLV. I don't see that error an issue. And having a dedicated TLV for each is better from both deployment and implementation perspective. I can't see how implementing the same functionality twice would be better from an implementation perspective, but I leave this to you. I would suspect that you may consider only implementing one, not both. not really, I prefer clean encoding rather the overloading things as we extend protocol. I disagree on the deployment perspective. We would have two TLVs to advertise the same information and provide the exactly same functionality. I can only see that this would bring deployment issues. e.g. one vendor implementing TLV A while another vendor implementing TLV B; hence no interoperability or a large delay to have both vendors implement both TLVs (or at least one vendor implementing both, presumably the smaller vendor). I don't agree. If we keep things clean we would not allow "vendor implementing TLV A while another vendor implementing TLV B". Anyway, it's for the WG to decide what encodi
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Peter, > From: Peter Psenak [mailto:ppse...@cisco.com] > > Bruno, > > please see inline: > > > > On 20/10/2020 11:43, bruno.decra...@orange.com wrote: > > Peter, > > > >> From: Peter Psenak [mailto:ppse...@cisco.com] > >> > >> Bruno, > >> > >> On 19/10/2020 18:52, bruno.decra...@orange.com wrote: > >>> Ron, all, > >>> > >>> >From a use case standpoint, I have a use case for having both SR-MPLS > and > >> IP flexalgo in the same network. > >>> > >>> >From a protocol standpoint, I think that the functionality could be > equally > >> met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 > (implicit > >> null) to instruct the LER/LSR to not use a label in the forwarding plane. > (while > >> still advertising a label in the control plane because we have to). > >> > >> does not work, > > > > I could provide more explanations, but reading your email, it seems to me > that you understood the proposal. > > So it seems to me that the opinion that you really meant is: it works but it > would be an nasty hack. > > > > Regarding "nasty hack" it could be interesting to have a normative > definition. This could prove useful in some other contexts. > > BTW, is "max metric" a hack (vs creating a new tlv if you don't want the > > link > in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the > label > in the NLRI... > > max-metric does not solve the problem, as you would need a prefix metric > for non 0 algo anyway. To clarify, my text was not a technical proposal related to that draft. It was referring to your email and questioning what exactly was a hack using some examples from the past. But let's forget about this point, at least for the moment. > > Coming back to technical comments, note that creating yet another TLV to > carry IP prefix also brings questions that the draft does not answer or even > raise. > > - What about the sub-TLVs? Are they shared with the existing registry for > prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier > (we would have two algo fields, two ways to signal SIDs...) > > yes, these are details that needs to be addressed, but should not be a > problem. Look at locator TLV in SRv6, very similar concept here. > > > - for IPv6, the content and meaning of "ISIS MT IPv6 Flexalgo Prefix > Reachability TLV" is essentially the same than the "SRv6 Locator TLV". > > - Only the naming and the ordering of the fields are different. > > - Why do we need two TLVs to advertise the same thing (essentially a > Routing Algo)? Duplication means more spec, more code, more features to > implement, more error and bugs. (and it did not took long: the draft defines > the MTID field as 8 bits while RFC 5120 defines it a 12 bits. > > well, locator is a construct that is specific to SRv6. Sure you can > advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs > and achieve the same thing - I have already mentioned that in one of my > responses, but that is again ugly. So we agree that reusing the SRv6 locator TLV would work and provide the functionality. Good. Now here comes again the "ugly" argument. If it's now becoming a technical argument, in my opinion, it's ugly to define two TLVs in order to advertise the same information and to provide the same functionality. > > - What is the functional different between FlexAlgo for SRv6 and > FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and > the IPv6 FIB in the router. > > they are functionally the same. Good to agree on this. > I believe that having a clean encoding is preferable in a long run. What do you mean by "clean encoding"? The only differences between both TLVs are the naming and the ordering of the fields. > One > can not advertise a prefix as SRv6 locator as well as IP flex-algo > prefix (that would be an error), so duplication of data is not an > issues. So one should not advertise both TLVs? If so this becomes an error/issue? This feels like my point. There is no such issue with a single TLV. > And having a dedicated TLV for each is better from both > deployment and implementation perspective. I can't see how implementing the same functionality twice would be better from an implementation perspective, but I leave this to you. I would suspect that you may consider only implementing one, not both. I disagree on the deployment perspective. We would have two TLVs to advertise the same information and provide the exactly same functionality. I can only see that this would bring deployment issues. e.g. one vendor implementing TLV A while another vendor implementing TLV B; hence no interoperability or a large delay to have both vendors implement both TLVs (or at least one vendor implementing both, presumably the smaller vendor). Thanks, --Bruno > thanks, > Peter > > > > > > > > Thanks, > > Bruno > > > >> as it does not allow you to associate the prefix with > >> Flex-algo without advertising the reachability
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Bruno, please see inline: On 20/10/2020 11:43, bruno.decra...@orange.com wrote: Peter, From: Peter Psenak [mailto:ppse...@cisco.com] Bruno, On 19/10/2020 18:52, bruno.decra...@orange.com wrote: Ron, all, >From a use case standpoint, I have a use case for having both SR-MPLS and IP flexalgo in the same network. >From a protocol standpoint, I think that the functionality could be equally met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) to instruct the LER/LSR to not use a label in the forwarding plane. (while still advertising a label in the control plane because we have to). does not work, I could provide more explanations, but reading your email, it seems to me that you understood the proposal. So it seems to me that the opinion that you really meant is: it works but it would be an nasty hack. Regarding "nasty hack" it could be interesting to have a normative definition. This could prove useful in some other contexts. BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI... max-metric does not solve the problem, as you would need a prefix metric for non 0 algo anyway. Coming back to technical comments, note that creating yet another TLV to carry IP prefix also brings questions that the draft does not answer or even raise. - What about the sub-TLVs? Are they shared with the existing registry for prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier (we would have two algo fields, two ways to signal SIDs...) yes, these are details that needs to be addressed, but should not be a problem. Look at locator TLV in SRv6, very similar concept here. - for IPv6, the content and meaning of "ISIS MT IPv6 Flexalgo Prefix Reachability TLV" is essentially the same than the "SRv6 Locator TLV". - Only the naming and the ordering of the fields are different. - Why do we need two TLVs to advertise the same thing (essentially a Routing Algo)? Duplication means more spec, more code, more features to implement, more error and bugs. (and it did not took long: the draft defines the MTID field as 8 bits while RFC 5120 defines it a 12 bits. well, locator is a construct that is specific to SRv6. Sure you can advertise the prefix in a locator TLV without any SRv6 specific Sub-TLVs and achieve the same thing - I have already mentioned that in one of my responses, but that is again ugly. - What is the functional different between FlexAlgo for SRv6 and FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the IPv6 FIB in the router. they are functionally the same. I believe that having a clean encoding is preferable in a long run. One can not advertise a prefix as SRv6 locator as well as IP flex-algo prefix (that would be an error), so duplication of data is not an issues. And having a dedicated TLV for each is better from both deployment and implementation perspective. thanks, Peter Thanks, Bruno as it does not allow you to associate the prefix with Flex-algo without advertising the reachability in algo 0. Making the prefix reachability in default algo conditional based on the presence of the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack. Not to mention that advertising a Prefix SID in pure IP network would be ugly. thanks, Peter I feel that this would be less change in the protocol (no new tlv), a good fit for network requiring both MPLS and IP flex algo, and would not require implementations/network operator to duplicate the "prefix sub-TLV" [1] on both advertisements (IP based and SR-MPLS based). That would still requires a protocol extension/STD track RFC as RFC 8667 does not allow for this. That would still require change to implementations as only the signalling is different while the feature/behavior is the same (i.e. no magic). Regards, --Bruno [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica Sent: Tuesday, September 29, 2020 3:38 PM To: lsr@ietf.org Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip- flexalgo- 00.txt Please review and comment Ron Juniper Business Use Only -Original Message- From: internet-dra...@ietf.org Sent: Tuesday, September 29, 2020 9:36 AM To: Parag Kaneriya ; Shraddha Hegde ; Ron Bonica ; Rajesh M ; William Britto A J Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt [External Email. Be cautious of content] A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt has been successfully submitted by Ron Bonica and posted to the IETF repository. Name: draft-bonica-lsr-ip-flexalgo Revision: 00 T
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Peter, > From: Peter Psenak [mailto:ppse...@cisco.com] > > Bruno, > > On 19/10/2020 18:52, bruno.decra...@orange.com wrote: > > Ron, all, > > > >>From a use case standpoint, I have a use case for having both SR-MPLS and > IP flexalgo in the same network. > > > >>From a protocol standpoint, I think that the functionality could be equally > met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit > null) to instruct the LER/LSR to not use a label in the forwarding plane. > (while > still advertising a label in the control plane because we have to). > > does not work, I could provide more explanations, but reading your email, it seems to me that you understood the proposal. So it seems to me that the opinion that you really meant is: it works but it would be an nasty hack. Regarding "nasty hack" it could be interesting to have a normative definition. This could prove useful in some other contexts. BTW, is "max metric" a hack (vs creating a new tlv if you don't want the link in the IGP SPF), is "implicit null label" a hack. And for BGP, encoding the label in the NLRI... Coming back to technical comments, note that creating yet another TLV to carry IP prefix also brings questions that the draft does not answer or even raise. - What about the sub-TLVs? Are they shared with the existing registry for prefix TLV [1] ? Do we want to exclude some? E.g., Prefix Segment Identifier (we would have two algo fields, two ways to signal SIDs...) - for IPv6, the content and meaning of "ISIS MT IPv6 Flexalgo Prefix Reachability TLV" is essentially the same than the "SRv6 Locator TLV". - Only the naming and the ordering of the fields are different. - Why do we need two TLVs to advertise the same thing (essentially a Routing Algo)? Duplication means more spec, more code, more features to implement, more error and bugs. (and it did not took long: the draft defines the MTID field as 8 bits while RFC 5120 defines it a 12 bits. - What is the functional different between FlexAlgo for SRv6 and FlexAlgo for IPv6? Both use the IPv6 destination address in the packet and the IPv6 FIB in the router. Thanks, Bruno > as it does not allow you to associate the prefix with > Flex-algo without advertising the reachability in algo 0. Making the > prefix reachability in default algo conditional based on the presence of > the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack. > > Not to mention that advertising a Prefix SID in pure IP network would be > ugly. > > thanks, > Peter > > > > > I feel that this would be less change in the protocol (no new tlv), a good > > fit > for network requiring both MPLS and IP flex algo, and would not require > implementations/network operator to duplicate the "prefix sub-TLV" [1] on > both advertisements (IP based and SR-MPLS based). > > > > That would still requires a protocol extension/STD track RFC as RFC 8667 > does not allow for this. That would still require change to implementations as > only the signalling is different while the feature/behavior is the same (i.e. > no > magic). > > > > Regards, > > --Bruno > > > > [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, > MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" > > > > > >> -Original Message- > >> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica > >> Sent: Tuesday, September 29, 2020 3:38 PM > >> To: lsr@ietf.org > >> Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip- > flexalgo- > >> 00.txt > >> > >> > >> Please review and comment > >> > >> Ron > >> > >> > >> > >> Juniper Business Use Only > >> > >>> -Original Message- > >>> From: internet-dra...@ietf.org > >>> Sent: Tuesday, September 29, 2020 9:36 AM > >>> To: Parag Kaneriya ; Shraddha Hegde > >>> ; Ron Bonica ; Rajesh M > >>> ; William Britto A J > >>> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt > >>> > >>> [External Email. Be cautious of content] > >>> > >>> > >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > >>> has been successfully submitted by Ron Bonica and posted to the IETF > >>> repository. > >>> > >>> Name: draft-bonica-lsr-ip-flexalgo > >>> Revision: 00 > >>> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > >>> Document date: 2020-09-29 > >>> Group: Individual Submission > >>> Pages: 14 > >>> URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft- > >> bonica- > >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > >>> Status: > >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > >> bonica-lsr- > >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > >>> Htmlized: > >>> > https://urldefense.com/v3/__https://datatracker.ietf.o
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Bruno, On 19/10/2020 18:52, bruno.decra...@orange.com wrote: Ron, all, From a use case standpoint, I have a use case for having both SR-MPLS and IP flexalgo in the same network. From a protocol standpoint, I think that the functionality could be equally met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit null) to instruct the LER/LSR to not use a label in the forwarding plane. (while still advertising a label in the control plane because we have to). does not work, as it does not allow you to associate the prefix with Flex-algo without advertising the reachability in algo 0. Making the prefix reachability in default algo conditional based on the presence of the Prefix SID Sub-TLV with Imnplicit Null would be a nasty hack. Not to mention that advertising a Prefix SID in pure IP network would be ugly. thanks, Peter I feel that this would be less change in the protocol (no new tlv), a good fit for network requiring both MPLS and IP flex algo, and would not require implementations/network operator to duplicate the "prefix sub-TLV" [1] on both advertisements (IP based and SR-MPLS based). That would still requires a protocol extension/STD track RFC as RFC 8667 does not allow for this. That would still require change to implementations as only the signalling is different while the feature/behavior is the same (i.e. no magic). Regards, --Bruno [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica Sent: Tuesday, September 29, 2020 3:38 PM To: lsr@ietf.org Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo- 00.txt Please review and comment Ron Juniper Business Use Only -Original Message- From: internet-dra...@ietf.org Sent: Tuesday, September 29, 2020 9:36 AM To: Parag Kaneriya ; Shraddha Hegde ; Ron Bonica ; Rajesh M ; William Britto A J Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt [External Email. Be cautious of content] A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt has been successfully submitted by Ron Bonica and posted to the IETF repository. Name: draft-bonica-lsr-ip-flexalgo Revision: 00 Title: IGP Flexible Algorithms (Flexalgo) In IP Networks Document date: 2020-09-29 Group: Individual Submission Pages: 14 URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft- bonica- lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- bonica-lsr- ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft- bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ Abstract: An IGP Flexible Algorithm computes a constraint-based path and maps that path to an identifier. As currently defined, Flexalgo can only map the paths that it computes to Segment Routing (SR) identifiers. Therefore, Flexalgo cannot be deployed in the absence of SR. This document extends Flexalgo, so that it can map the paths that it computes to IP addresses. This allows Flexalgo to be deployed in any IP network, even in the absence of SR. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Ron, all, >From a use case standpoint, I have a use case for having both SR-MPLS and IP >flexalgo in the same network. >From a protocol standpoint, I think that the functionality could be equally >met by advertising SR-MPLS SID as per RFC 8667 but using a label 3 (implicit >null) to instruct the LER/LSR to not use a label in the forwarding plane. >(while still advertising a label in the control plane because we have to). I feel that this would be less change in the protocol (no new tlv), a good fit for network requiring both MPLS and IP flex algo, and would not require implementations/network operator to duplicate the "prefix sub-TLV" [1] on both advertisements (IP based and SR-MPLS based). That would still requires a protocol extension/STD track RFC as RFC 8667 does not allow for this. That would still require change to implementations as only the signalling is different while the feature/behavior is the same (i.e. no magic). Regards, --Bruno [1] aka "Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)" > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Ron Bonica > Sent: Tuesday, September 29, 2020 3:38 PM > To: lsr@ietf.org > Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo- > 00.txt > > > Please review and comment > >Ron > > > > Juniper Business Use Only > > > -Original Message- > > From: internet-dra...@ietf.org > > Sent: Tuesday, September 29, 2020 9:36 AM > > To: Parag Kaneriya ; Shraddha Hegde > > ; Ron Bonica ; Rajesh M > > ; William Britto A J > > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt > > > > [External Email. Be cautious of content] > > > > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Name: draft-bonica-lsr-ip-flexalgo > > Revision: 00 > > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > > Document date: 2020-09-29 > > Group: Individual Submission > > Pages: 14 > > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft- > bonica- > > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > > Status: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > bonica-lsr- > > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > > Htmlized: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > > Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > > > > Abstract: > >An IGP Flexible Algorithm computes a constraint-based path and maps > >that path to an identifier. As currently defined, Flexalgo can only > >map the paths that it computes to Segment Routing (SR) identifiers. > >Therefore, Flexalgo cannot be deployed in the absence of SR. > > > >This document extends Flexalgo, so that it can map the paths that it > >computes to IP addresses. This allows Flexalgo to be deployed in any > >IP network, even in the absence of SR. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Hi Tony, You are correct in that a prefix can only be associated with one Flexalgo. I will add some text about applications in the next version. Ron Juniper Business Use Only -Original Message- From: Tony Li On Behalf Of tony...@tony.li Sent: Tuesday, September 29, 2020 10:05 AM To: Ron Bonica Cc: lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt [External Email. Be cautious of content] Ron, This is nice. It makes it clear that constraint based path computation need not have MPLS overhead for those that don’t want it. One thing that you don’t talk about is how this gets used, tho that may be blindingly obvious: you’ll need all nodes placing their prefixes in the RIB/FIB, where it will need to be selected over other path computation for the same prefixes. This somewhat precludes the possibility of a given prefix being useful in multiple flex-algos. More text on application would be most welcome, just to ensure that we’re on the same page. Tony > On Sep 29, 2020, at 6:37 AM, Ron Bonica > wrote: > > > Please review and comment > > Ron > > > > Juniper Business Use Only > >> -Original Message- >> From: internet-dra...@ietf.org >> Sent: Tuesday, September 29, 2020 9:36 AM >> To: Parag Kaneriya ; Shraddha Hegde >> ; Ron Bonica ; Rajesh M >> ; William Britto A J >> Subject: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> [External Email. Be cautious of content] >> >> >> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >> >> Name: draft-bonica-lsr-ip-flexalgo >> Revision: 00 >> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks >> Document date: 2020-09-29 >> Group: Individual Submission >> Pages: 14 >> URL: >> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- >> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ >> Status: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bo >> nica-lsr- >> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ >> Htmlized: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra >> ft- >> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ >> Htmlized: >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ >> >> >> Abstract: >> An IGP Flexible Algorithm computes a constraint-based path and maps >> that path to an identifier. As currently defined, Flexalgo can only >> map the paths that it computes to Segment Routing (SR) identifiers. >> Therefore, Flexalgo cannot be deployed in the absence of SR. >> >> This document extends Flexalgo, so that it can map the paths that it >> computes to IP addresses. This allows Flexalgo to be deployed in any >> IP network, even in the absence of SR. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> > ___ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > _;!!NEt6yMaO-gk!RnM-z-O3leH_IIH06LxRzZKbRMQuuQcRs4g4RCiTbE0PleY70Sm2h3 > pFo42w7jA8$ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Les, Thanks for the review. All good catches. We will address them all in the next draft version. Ron Juniper Business Use Only -Original Message- From: Les Ginsberg (ginsberg) Sent: Wednesday, September 30, 2020 3:39 PM To: Ron Bonica ; lsr@ietf.org Subject: RE: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt [External Email. Be cautious of content] Ron - Interesting proposal. A few mundane - but I think still important - comments. New IS-IS TLVs There is no need to have two TLVs for each address-family - one for MTID #0 and one for all non-zero MTIDs. One TLV/AF will suffice. The reason we have separate TLVs today is because MT (RFC 5120) came along after TLV 135/236 had been defined/deployed. Since you have a greenfield here you can simply have one TLV/AF and allow all MTIDs (including 0). MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value. (I believe someone else pointed this out as well.) See RFC 5120. You should specify that the new TLVs inherit the sub-TLV space defined in https://urldefense.com/v3/__https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml*isis-tlv-codepoints-135-235-236-237__;Iw!!NEt6yMaO-gk!Rh_KQ_Gqclv8ar4yhZ4nGijt5s9AbhGufBcPVYsk5iEHCP_lp_nRG_C8qZvvh30w$ The U-bit - I appreciate that there is precedence for calling this the U-bit based on RFC 5308 - but I would prefer that you call it the D-bit. Regardless of name, it MUST be consistent with existing usage - meaning it is set when the prefix is leaked downwards. Currently your text says: "U (1 bit): Set indicates up. Clear indicates down." This needs to be reversed. Constraints --- I think you need to speak to various constraints including (but not limited to): 1)Algorithm is limited to flex-algo values (128-255) I don't understand why Section 6 (main part - not the sub-sections) is there. What relevance do non-flex-algos have to this draft?? I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm Sub-TLV". Unless you are proposing to use this sub-TLV in ways not related to flex-algo - in which case I think you need to provide some explanation of the use case for this. 2)How to handle advertisement of same algo both in the new Algorithm sub-TLV and the existing SR Algorithm sub-TLV (prefer SR??) Note that legacy routers may understand SR Algorithm Sub-TLV but not the new one. Les > -Original Message- > From: Lsr On Behalf Of Ron Bonica > Sent: Tuesday, September 29, 2020 6:38 AM > To: lsr@ietf.org > Subject: [Lsr] FW: New Version Notification for > draft-bonica-lsr-ip-flexalgo- 00.txt > > > Please review and comment > >Ron > > > > Juniper Business Use Only > > > -Original Message- > > From: internet-dra...@ietf.org > > Sent: Tuesday, September 29, 2020 9:36 AM > > To: Parag Kaneriya ; Shraddha Hegde > > ; Ron Bonica ; Rajesh M > > ; William Britto A J > > Subject: New Version Notification for > > draft-bonica-lsr-ip-flexalgo-00.txt > > > > [External Email. Be cautious of content] > > > > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Name: draft-bonica-lsr-ip-flexalgo > > Revision: 00 > > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > > Document date: 2020-09-29 > > Group: Individual Submission > > Pages: 14 > > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft- > bonica- > > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > > Status: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > bonica-lsr- > > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > > Htmlized: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr > > aft- > > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > > Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > > > > Abstract: > >An IGP Flexible Algorithm computes a constraint-based path and maps > >that path to an identifier. As currently defined, Flexalgo can only > >map the paths that it computes to Segment Routing (SR) identifiers. > >Therefore, Flexalgo cannot be deployed in the absence of SR. > > > >This document extends Flexalgo, so that it can map the paths that it > >computes to IP addresses. This allows Flexalgo to be deployed in any > >IP network, even in the absence of SR. > > > > > > > > > > Please note that it may take a couple of minutes from th
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
ly anchor nodes
> need to
> > support the new functionality while rest of the network
does not
> need to
> > be even aware about it.
>
> above is not really true.
>
> Algo participation needs to be signaled, one way or the
other. It's
> done
> for SR as well. There is no need for all routers to understand
> flex-algo, as only those that participate (and as a result also
> understand it) will be used during the flex-algo path
computation and
> consequently flex-algo specific forwarding. This applies to
> flex-algo in
> general, regardless of the data plane being used.
>
> thanks,
> Peter
>
>
> >
> > Many thx,
> > R.
> >
> >
> > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo
mailto:huzh...@huawei.com>
> <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>
> > <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>
<mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>>> wrote:
> >
> > Hi Joel:
> >
> > For details about the method defined in RFC 6550. It
> uses the
> > HBH option to carry the RPLInstaceID. The RPLInstaceID and
> > FlexAlgoID are similar.
> >
> > Thanks
> >
> > Zhibo
> >
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>
> <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>
> > <mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org> <mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>>>]
> On Behalf Of Joel M. Halpern
> > Sent: Wednesday, September 30, 2020 12:05 PM
> > Cc: lsr@ietf.org <mailto:lsr@ietf.org>
<mailto:lsr@ietf.org <mailto:lsr@ietf.org>> <mailto:lsr@ietf.org
<mailto:lsr@ietf.org>
> <mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
> > Subject: Re: [Lsr] New Version Notification for
> > draft-bonica-lsr-ip-flexalgo-00.txt
> >
> > I am missing something in this discussion of multiple
algorithms.
> >
> > My understanding of flex-algo whether for MPLS, SRv6,
SRH, or
> IPv6,
> > is that you need to associated a forwarding label
(e.g. MPLS
> label
> > or IPv6
> > address) with a specific algorithm so that you can compute
> the next
> > hope for the forwarding label using the proper algorithm.
> Then when
> > a packet arrives, it is simply forwarded according to the
> forwarding
> > table (e.g.
> > FIB, LIB, ..)
> >
> > If that is so, then I do not understand how a given
prefix can be
> > safely associated with more than one algorithm. I
could imagine
> > doing several calculations according to different
> algorithms. But
> > how do you decide which one applies to the packet? As
far as I
> > know, flex-algo does not look at the QoS/CoS/ToS bits.
> >
> > Yours,
> > Joel
> >
> > PS: I will admit that it took until an operator
described some
> > "interesting" constraints before I understood why one
would
> even do
> > this.
> >
> > On 9/29/2020 11:50 PM, Huzhibo wrote:
> > > Hi.
> > >
> > > Associating multiple algorithms with a given prefix
is an
> > interesting topic, and I think this can simplify the
> complexity of
> > FlexAlgo. I wonder if the author would consider using
cases with
> > multiple algorithms with a given prefix.
> > >
> > > Thanks
> > >
> > > ZHibo
> > >
> > > -Original Message-
> >
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Ron - Interesting proposal. A few mundane - but I think still important - comments. New IS-IS TLVs There is no need to have two TLVs for each address-family - one for MTID #0 and one for all non-zero MTIDs. One TLV/AF will suffice. The reason we have separate TLVs today is because MT (RFC 5120) came along after TLV 135/236 had been defined/deployed. Since you have a greenfield here you can simply have one TLV/AF and allow all MTIDs (including 0). MTID is a 16 bit field with 4 reserved bits and 12 bits used for MTID value. (I believe someone else pointed this out as well.) See RFC 5120. You should specify that the new TLVs inherit the sub-TLV space defined in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-135-235-236-237 The U-bit - I appreciate that there is precedence for calling this the U-bit based on RFC 5308 - but I would prefer that you call it the D-bit. Regardless of name, it MUST be consistent with existing usage - meaning it is set when the prefix is leaked downwards. Currently your text says: "U (1 bit): Set indicates up. Clear indicates down." This needs to be reversed. Constraints --- I think you need to speak to various constraints including (but not limited to): 1)Algorithm is limited to flex-algo values (128-255) I don't understand why Section 6 (main part - not the sub-sections) is there. What relevance do non-flex-algos have to this draft?? I also think the new sub-TLV would be better named "Native Flex-Algo Algorithm Sub-TLV". Unless you are proposing to use this sub-TLV in ways not related to flex-algo - in which case I think you need to provide some explanation of the use case for this. 2)How to handle advertisement of same algo both in the new Algorithm sub-TLV and the existing SR Algorithm sub-TLV (prefer SR??) Note that legacy routers may understand SR Algorithm Sub-TLV but not the new one. Les > -Original Message- > From: Lsr On Behalf Of Ron Bonica > Sent: Tuesday, September 29, 2020 6:38 AM > To: lsr@ietf.org > Subject: [Lsr] FW: New Version Notification for draft-bonica-lsr-ip-flexalgo- > 00.txt > > > Please review and comment > >Ron > > > > Juniper Business Use Only > > > -Original Message- > > From: internet-dra...@ietf.org > > Sent: Tuesday, September 29, 2020 9:36 AM > > To: Parag Kaneriya ; Shraddha Hegde > > ; Ron Bonica ; Rajesh M > > ; William Britto A J > > Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt > > > > [External Email. Be cautious of content] > > > > > > A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > > has been successfully submitted by Ron Bonica and posted to the IETF > > repository. > > > > Name: draft-bonica-lsr-ip-flexalgo > > Revision: 00 > > Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > > Document date: 2020-09-29 > > Group: Individual Submission > > Pages: 14 > > URL:https://urldefense.com/v3/__https://www.ietf.org/id/draft- > bonica- > > lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > > Status: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft- > bonica-lsr- > > ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > > Htmlized: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > > bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > > Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > > bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > > FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > > > > > > Abstract: > >An IGP Flexible Algorithm computes a constraint-based path and maps > >that path to an identifier. As currently defined, Flexalgo can only > >map the paths that it computes to Segment Routing (SR) identifiers. > >Therefore, Flexalgo cannot be deployed in the absence of SR. > > > >This document extends Flexalgo, so that it can map the paths that it > >computes to IP addresses. This allows Flexalgo to be deployed in any > >IP network, even in the absence of SR. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
; > Peter > > > > > > > > > > Many thx, > > > R. > > > > > > > > > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo > <mailto:huzh...@huawei.com> > > > <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>> wrote: > > > > > > Hi Joel: > > > > > > For details about the method defined in RFC 6550. It > > uses the > > > HBH option to carry the RPLInstaceID. The RPLInstaceID and > > > FlexAlgoID are similar. > > > > > > Thanks > > > > > > Zhibo > > > > > > -Original Message- > > > From: Lsr [mailto:lsr-boun...@ietf.org > > <mailto:lsr-boun...@ietf.org> > > > <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>] > > On Behalf Of Joel M. Halpern > > > Sent: Wednesday, September 30, 2020 12:05 PM > > > Cc: lsr@ietf.org <mailto:lsr@ietf.org> <mailto:lsr@ietf.org > > <mailto:lsr@ietf.org>> > > > Subject: Re: [Lsr] New Version Notification for > > > draft-bonica-lsr-ip-flexalgo-00.txt > > > > > > I am missing something in this discussion of multiple > algorithms. > > > > > > My understanding of flex-algo whether for MPLS, SRv6, SRH, or > > IPv6, > > > is that you need to associated a forwarding label (e.g. MPLS > > label > > > or IPv6 > > > address) with a specific algorithm so that you can compute > > the next > > > hope for the forwarding label using the proper algorithm. > > Then when > > > a packet arrives, it is simply forwarded according to the > > forwarding > > > table (e.g. > > > FIB, LIB, ..) > > > > > > If that is so, then I do not understand how a given prefix > can be > > > safely associated with more than one algorithm. I could > imagine > > > doing several calculations according to different > > algorithms. But > > > how do you decide which one applies to the packet? As far as > I > > > know, flex-algo does not look at the QoS/CoS/ToS bits. > > > > > > Yours, > > > Joel > > > > > > PS: I will admit that it took until an operator described > some > > > "interesting" constraints before I understood why one would > > even do > > > this. > > > > > > On 9/29/2020 11:50 PM, Huzhibo wrote: > > > > Hi. > > > > > > > > Associating multiple algorithms with a given prefix is an > > > interesting topic, and I think this can simplify the > > complexity of > > > FlexAlgo. I wonder if the author would consider using cases > with > > > multiple algorithms with a given prefix. > > > > > > > > Thanks > > > > > > > > ZHibo > > > > > > > > -Original Message- > > > > From: Lsr [mailto:lsr-boun...@ietf.org > > <mailto:lsr-boun...@ietf.org> > > > <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>] > > On Behalf Of tony...@tony.li <mailto:tony...@tony.li> > > > <mailto:tony...@tony.li <mailto:tony...@tony.li>> > > > > Sent: Tuesday, September 29, 2020 10:05 PM > > > > To: Ron Bonica > <mailto:40juniper@dmarc.ietf.org> > > > <mailto:40juniper@dmarc.ietf.org > > <mailto:40juniper@dmarc.ietf.org>>> > > > > Cc: lsr@ietf.org <mailto:lsr@ietf.org> > > <mailto:lsr@ietf.org <mailto:lsr@ietf.org>> > > > > Subject: Re: [Lsr] New Version Notification for > > > > draft-bonica-lsr-ip-flexalgo-00.txt > > > > > > > > > > > > Ron, > > > > > > > > This is nice. It makes it clear that constraint based path > > > computation need not have MPLS overhead for those that don’t > >
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Robert,
On 30/09/2020 16:28, Robert Raszuk wrote:
Peter,
Let's see if we are talking about the same thing ...
Take SRv6 as example ... You can run flex algorithm only on selected
segment endpoints as you do encap and dst rewrite. So rest of the
network (P/transit routers) do not need to have a clue about any
flex-algo other then plain old SPF.
if all transit nodes do not participate/understand flex-algo, you will
not be able to route the traffic between the segment endpoints based on
the flex-algo, in other words algo specific locators will not be reachable.
Now in Ron's case where there is no encap and you are applying flex-algo
to naked packets don't you think there is a difference and a bit of
deployment difficulty to make it work ?
it is the same as with SRv6 locator - prefix associated with algorithm,
with some additional SRv6 data. From the flex-algo calculation and
forwarding perspective there is no difference.
So assume one P node will not support it. This is native IP switching so
BGP advertises routes with new flex-algo next hop. If that next hop is
unreachable as signalling to that flex algo loopback was not understood
by P (new signalling extension) packets will be dropped.
such P node would never ever be in the flex-algo forwarding path for
prefix associated with flex-algo. We are talking underlay here, not BGP.
BGP service allocates the SRV6 SID from the algo specific locator in
case of SRv6. It can pick the NH as algo specific prefix I assume and
the rest is the same.
But what if that next hop would happen to be covered by some aggregate
route not subject perhaps to intended IP TE ?
aggregation needs to be algo aware for it to work.
thanks,
Peter
Cheers,
R.
On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak <mailto:ppse...@cisco.com>> wrote:
Hi Robert,
On 30/09/2020 09:28, Robert Raszuk wrote:
> Hi,
>
> > It uses the HBH option
>
> Currently Ron's proposal seems to work well for both IPv4 and IPv6
> addresses. I hope this discussion will not try to derail it to
IPv6 only
> track.
>
> I see no issue with loopback to flexible algorithm mapping in 1:1
fashion.
>
> I do however see some issues in deploying such technology as it will
> only work well if *all* nodes in the network support this new
> functionality. In contrast in SR world or control plane based TE I
> proposed or any encapsulation based proposal only anchor nodes
need to
> support the new functionality while rest of the network does not
need to
> be even aware about it.
above is not really true.
Algo participation needs to be signaled, one way or the other. It's
done
for SR as well. There is no need for all routers to understand
flex-algo, as only those that participate (and as a result also
understand it) will be used during the flex-algo path computation and
consequently flex-algo specific forwarding. This applies to
flex-algo in
general, regardless of the data plane being used.
thanks,
Peter
>
> Many thx,
> R.
>
>
> On Wed, Sep 30, 2020 at 6:10 AM Huzhibo mailto:huzh...@huawei.com>
> <mailto:huzh...@huawei.com <mailto:huzh...@huawei.com>>> wrote:
>
> Hi Joel:
>
> For details about the method defined in RFC 6550. It
uses the
> HBH option to carry the RPLInstaceID. The RPLInstaceID and
> FlexAlgoID are similar.
>
> Thanks
>
> Zhibo
>
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>
> <mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>>]
On Behalf Of Joel M. Halpern
> Sent: Wednesday, September 30, 2020 12:05 PM
> Cc: lsr@ietf.org <mailto:lsr@ietf.org> <mailto:lsr@ietf.org
<mailto:lsr@ietf.org>>
> Subject: Re: [Lsr] New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
> I am missing something in this discussion of multiple algorithms.
>
> My understanding of flex-algo whether for MPLS, SRv6, SRH, or
IPv6,
> is that you need to associated a forwarding label (e.g. MPLS
label
> or IPv6
> address) with a specific algorithm so that you can compute
the next
> hope for the forwarding label using the proper algorithm.
Then when
> a packet arrives, it is simply forwarded according to the
forwarding
> table (e.g.
> FIB, LIB, ..)
>
> If that is so, then I do not understand how a given prefix can be
&
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Hi, While it is possible to define algorithm-specific IP reachability TLVs to advertise IP Prefixes associated with different algorithms, this would introduce several new IS-IS top TLVs. One quick question is: can similar function be provided with extensions to existing IP reachability TLVs and MT IP reachability TLVs, instead of defining top TLVs for MT, Flex-Algo, and the combination of Flex-Algo and MT respectively? And one nit in the encoding: the length of MT-ID in IS-IS should be 12 bits. Best regards, Jie From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Wednesday, September 30, 2020 3:28 PM To: Huzhibo mailto:huzh...@huawei.com>> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Joel M. Halpern mailto:j...@joelhalpern.com>> Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Hi, > It uses the HBH option Currently Ron's proposal seems to work well for both IPv4 and IPv6 addresses. I hope this discussion will not try to derail it to IPv6 only track. I see no issue with loopback to flexible algorithm mapping in 1:1 fashion. I do however see some issues in deploying such technology as it will only work well if *all* nodes in the network support this new functionality. In contrast in SR world or control plane based TE I proposed or any encapsulation based proposal only anchor nodes need to support the new functionality while rest of the network does not need to be even aware about it. Many thx, R. On Wed, Sep 30, 2020 at 6:10 AM Huzhibo mailto:huzh...@huawei.com>> wrote: Hi Joel: For details about the method defined in RFC 6550. It uses the HBH option to carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are similar. Thanks Zhibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf Of Joel M. Halpern Sent: Wednesday, September 30, 2020 12:05 PM Cc: lsr@ietf.org<mailto:lsr@ietf.org> Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt I am missing something in this discussion of multiple algorithms. My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you need to associated a forwarding label (e.g. MPLS label or IPv6 address) with a specific algorithm so that you can compute the next hope for the forwarding label using the proper algorithm. Then when a packet arrives, it is simply forwarded according to the forwarding table (e.g. FIB, LIB, ..) If that is so, then I do not understand how a given prefix can be safely associated with more than one algorithm. I could imagine doing several calculations according to different algorithms. But how do you decide which one applies to the packet? As far as I know, flex-algo does not look at the QoS/CoS/ToS bits. Yours, Joel PS: I will admit that it took until an operator described some "interesting" constraints before I understood why one would even do this. On 9/29/2020 11:50 PM, Huzhibo wrote: > Hi. > > Associating multiple algorithms with a given prefix is an interesting topic, > and I think this can simplify the complexity of FlexAlgo. I wonder if the > author would consider using cases with multiple algorithms with a given > prefix. > > Thanks > > ZHibo > > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On > Behalf Of tony...@tony.li<mailto:tony...@tony.li> > Sent: Tuesday, September 29, 2020 10:05 PM > To: Ron Bonica > mailto:40juniper....@dmarc.ietf.org>> > Cc: lsr@ietf.org<mailto:lsr@ietf.org> > Subject: Re: [Lsr] New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > > > Ron, > > This is nice. It makes it clear that constraint based path computation need > not have MPLS overhead for those that don’t want it. > > One thing that you don’t talk about is how this gets used, tho that may be > blindingly obvious: you’ll need all nodes placing their prefixes in the > RIB/FIB, where it will need to be selected over other path computation for > the same prefixes. This somewhat precludes the possibility of a given prefix > being useful in multiple flex-algos. > > More text on application would be most welcome, just to ensure that we’re on > the same page. > > Tony > > >> On Sep 29, 2020, at 6:37 AM, Ron Bonica >> mailto:40juniper@dmarc.ietf.org>> >> wrote: >> >> >> Please review and comment >> >>Ron >> >> >> >> Juniper Business Use Only >> >>> -Original Message- >>> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> >>> mailto:internet-dra...@ietf.org>> >>> Sent: Tuesday, September 29, 202
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Peter, Let's see if we are talking about the same thing ... Take SRv6 as example ... You can run flex algorithm only on selected segment endpoints as you do encap and dst rewrite. So rest of the network (P/transit routers) do not need to have a clue about any flex-algo other then plain old SPF. Now in Ron's case where there is no encap and you are applying flex-algo to naked packets don't you think there is a difference and a bit of deployment difficulty to make it work ? So assume one P node will not support it. This is native IP switching so BGP advertises routes with new flex-algo next hop. If that next hop is unreachable as signalling to that flex algo loopback was not understood by P (new signalling extension) packets will be dropped. But what if that next hop would happen to be covered by some aggregate route not subject perhaps to intended IP TE ? Cheers, R. On Wed, Sep 30, 2020 at 2:11 PM Peter Psenak wrote: > Hi Robert, > > On 30/09/2020 09:28, Robert Raszuk wrote: > > Hi, > > > > > It uses the HBH option > > > > Currently Ron's proposal seems to work well for both IPv4 and IPv6 > > addresses. I hope this discussion will not try to derail it to IPv6 only > > track. > > > > I see no issue with loopback to flexible algorithm mapping in 1:1 > fashion. > > > > I do however see some issues in deploying such technology as it will > > only work well if *all* nodes in the network support this new > > functionality. In contrast in SR world or control plane based TE I > > proposed or any encapsulation based proposal only anchor nodes need to > > support the new functionality while rest of the network does not need to > > be even aware about it. > > above is not really true. > > Algo participation needs to be signaled, one way or the other. It's done > for SR as well. There is no need for all routers to understand > flex-algo, as only those that participate (and as a result also > understand it) will be used during the flex-algo path computation and > consequently flex-algo specific forwarding. This applies to flex-algo in > general, regardless of the data plane being used. > > thanks, > Peter > > > > > > Many thx, > > R. > > > > > > On Wed, Sep 30, 2020 at 6:10 AM Huzhibo > <mailto:huzh...@huawei.com>> wrote: > > > > Hi Joel: > > > > For details about the method defined in RFC 6550. It uses the > > HBH option to carry the RPLInstaceID. The RPLInstaceID and > > FlexAlgoID are similar. > > > > Thanks > > > > Zhibo > > > > -Original Message----- > > From: Lsr [mailto:lsr-boun...@ietf.org > > <mailto:lsr-boun...@ietf.org>] On Behalf Of Joel M. Halpern > > Sent: Wednesday, September 30, 2020 12:05 PM > > Cc: lsr@ietf.org <mailto:lsr@ietf.org> > > Subject: Re: [Lsr] New Version Notification for > > draft-bonica-lsr-ip-flexalgo-00.txt > > > > I am missing something in this discussion of multiple algorithms. > > > > My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, > > is that you need to associated a forwarding label (e.g. MPLS label > > or IPv6 > > address) with a specific algorithm so that you can compute the next > > hope for the forwarding label using the proper algorithm. Then when > > a packet arrives, it is simply forwarded according to the forwarding > > table (e.g. > > FIB, LIB, ..) > > > > If that is so, then I do not understand how a given prefix can be > > safely associated with more than one algorithm. I could imagine > > doing several calculations according to different algorithms. But > > how do you decide which one applies to the packet? As far as I > > know, flex-algo does not look at the QoS/CoS/ToS bits. > > > > Yours, > > Joel > > > > PS: I will admit that it took until an operator described some > > "interesting" constraints before I understood why one would even do > > this. > > > > On 9/29/2020 11:50 PM, Huzhibo wrote: > > > Hi. > > > > > > Associating multiple algorithms with a given prefix is an > > interesting topic, and I think this can simplify the complexity of > > FlexAlgo. I wonder if the author would consider using cases with > > multiple algorithms with a given prefix. > > > > > > Thanks > > > > > > ZHibo > > > > > > -Original Message- >
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Hi Robert,
On 30/09/2020 09:28, Robert Raszuk wrote:
Hi,
> It uses the HBH option
Currently Ron's proposal seems to work well for both IPv4 and IPv6
addresses. I hope this discussion will not try to derail it to IPv6 only
track.
I see no issue with loopback to flexible algorithm mapping in 1:1 fashion.
I do however see some issues in deploying such technology as it will
only work well if *all* nodes in the network support this new
functionality. In contrast in SR world or control plane based TE I
proposed or any encapsulation based proposal only anchor nodes need to
support the new functionality while rest of the network does not need to
be even aware about it.
above is not really true.
Algo participation needs to be signaled, one way or the other. It's done
for SR as well. There is no need for all routers to understand
flex-algo, as only those that participate (and as a result also
understand it) will be used during the flex-algo path computation and
consequently flex-algo specific forwarding. This applies to flex-algo in
general, regardless of the data plane being used.
thanks,
Peter
Many thx,
R.
On Wed, Sep 30, 2020 at 6:10 AM Huzhibo <mailto:huzh...@huawei.com>> wrote:
Hi Joel:
For details about the method defined in RFC 6550. It uses the
HBH option to carry the RPLInstaceID. The RPLInstaceID and
FlexAlgoID are similar.
Thanks
Zhibo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] On Behalf Of Joel M. Halpern
Sent: Wednesday, September 30, 2020 12:05 PM
Cc: lsr@ietf.org <mailto:lsr@ietf.org>
Subject: Re: [Lsr] New Version Notification for
draft-bonica-lsr-ip-flexalgo-00.txt
I am missing something in this discussion of multiple algorithms.
My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6,
is that you need to associated a forwarding label (e.g. MPLS label
or IPv6
address) with a specific algorithm so that you can compute the next
hope for the forwarding label using the proper algorithm. Then when
a packet arrives, it is simply forwarded according to the forwarding
table (e.g.
FIB, LIB, ..)
If that is so, then I do not understand how a given prefix can be
safely associated with more than one algorithm. I could imagine
doing several calculations according to different algorithms. But
how do you decide which one applies to the packet? As far as I
know, flex-algo does not look at the QoS/CoS/ToS bits.
Yours,
Joel
PS: I will admit that it took until an operator described some
"interesting" constraints before I understood why one would even do
this.
On 9/29/2020 11:50 PM, Huzhibo wrote:
> Hi.
>
> Associating multiple algorithms with a given prefix is an
interesting topic, and I think this can simplify the complexity of
FlexAlgo. I wonder if the author would consider using cases with
multiple algorithms with a given prefix.
>
> Thanks
>
> ZHibo
>
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>] On Behalf Of tony...@tony.li
<mailto:tony...@tony.li>
> Sent: Tuesday, September 29, 2020 10:05 PM
> To: Ron Bonica mailto:40juniper....@dmarc.ietf.org>>
> Cc: lsr@ietf.org <mailto:lsr@ietf.org>
> Subject: Re: [Lsr] New Version Notification for
> draft-bonica-lsr-ip-flexalgo-00.txt
>
>
> Ron,
>
> This is nice. It makes it clear that constraint based path
computation need not have MPLS overhead for those that don’t want it.
>
> One thing that you don’t talk about is how this gets used, tho
that may be blindingly obvious: you’ll need all nodes placing their
prefixes in the RIB/FIB, where it will need to be selected over
other path computation for the same prefixes. This somewhat
precludes the possibility of a given prefix being useful in multiple
flex-algos.
>
> More text on application would be most welcome, just to ensure
that we’re on the same page.
>
> Tony
>
>
>> On Sep 29, 2020, at 6:37 AM, Ron Bonica
mailto:40juniper@dmarc.ietf.org>> wrote:
>>
>>
>> Please review and comment
>>
>> Ron
>>
>>
>>
>> Juniper Business Use Only
>>
>>> -Original Message-
>>> From: internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org> mailto:internet-dra...@ietf.org>>
>>> Sent: Tuesday, September 29, 2020 9:36 AM
>>> To: Parag Kaneriya mailto
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Hi Joel, On 30/09/2020 06:04, Joel M. Halpern wrote: I am missing something in this discussion of multiple algorithms. not really. My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you need to associated a forwarding label (e.g. MPLS label or IPv6 address) with a specific algorithm so that you can compute the next hope for the forwarding label using the proper algorithm. Then when a packet arrives, it is simply forwarded according to the forwarding table (e.g. FIB, LIB, ..) right. For SR MPLS, the flex-algo forwarding is associated with the algo specific label that is derived from the algo specific SID. That unique algo specific label allows the traffic for the same prefix to be forwarded using many algorithms by simply using the right MPLS label. For SRv6, the SRv6 Locator is associated with a single Algorithm. The proposal here is to associate the prefix with the unique flex-algo only and use that association on all routers. This is similar to SRv6 locators. If that is so, then I do not understand how a given prefix can be safely associated with more than one algorithm. I could imagine doing several calculations according to different algorithms. But how do you decide which one applies to the packet? As far as I know, flex-algo does not look at the QoS/CoS/ToS bits. absolutely not. Doing classification of the data traffic at each hop does not work. It has been attempted in the past, but without much success. thanks, Peter Yours, Joel PS: I will admit that it took until an operator described some "interesting" constraints before I understood why one would even do this. On 9/29/2020 11:50 PM, Huzhibo wrote: Hi. Associating multiple algorithms with a given prefix is an interesting topic, and I think this can simplify the complexity of FlexAlgo. I wonder if the author would consider using cases with multiple algorithms with a given prefix. Thanks ZHibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Tuesday, September 29, 2020 10:05 PM To: Ron Bonica Cc: lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Ron, This is nice. It makes it clear that constraint based path computation need not have MPLS overhead for those that don’t want it. One thing that you don’t talk about is how this gets used, tho that may be blindingly obvious: you’ll need all nodes placing their prefixes in the RIB/FIB, where it will need to be selected over other path computation for the same prefixes. This somewhat precludes the possibility of a given prefix being useful in multiple flex-algos. More text on application would be most welcome, just to ensure that we’re on the same page. Tony On Sep 29, 2020, at 6:37 AM, Ron Bonica wrote: Please review and comment Ron Juniper Business Use Only -Original Message- From: internet-dra...@ietf.org Sent: Tuesday, September 29, 2020 9:36 AM To: Parag Kaneriya ; Shraddha Hegde ; Ron Bonica ; Rajesh M ; William Britto A J Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt [External Email. Be cautious of content] A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt has been successfully submitted by Ron Bonica and posted to the IETF repository. Name: draft-bonica-lsr-ip-flexalgo Revision: 00 Title: IGP Flexible Algorithms (Flexalgo) In IP Networks Document date: 2020-09-29 Group: Individual Submission Pages: 14 URL: https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bo nica-lsr- ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra ft- bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft- bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ Abstract: An IGP Flexible Algorithm computes a constraint-based path and maps that path to an identifier. As currently defined, Flexalgo can only map the paths that it computes to Segment Routing (SR) identifiers. Therefore, Flexalgo cannot be deployed in the absence of SR. This document extends Flexalgo, so that it can map the paths that it computes to IP addresses. This allows Flexalgo to be deployed in any IP network, even in the absence of SR. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Hi, > It uses the HBH option Currently Ron's proposal seems to work well for both IPv4 and IPv6 addresses. I hope this discussion will not try to derail it to IPv6 only track. I see no issue with loopback to flexible algorithm mapping in 1:1 fashion. I do however see some issues in deploying such technology as it will only work well if *all* nodes in the network support this new functionality. In contrast in SR world or control plane based TE I proposed or any encapsulation based proposal only anchor nodes need to support the new functionality while rest of the network does not need to be even aware about it. Many thx, R. On Wed, Sep 30, 2020 at 6:10 AM Huzhibo wrote: > Hi Joel: > > For details about the method defined in RFC 6550. It uses the HBH > option to carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are > similar. > > Thanks > > Zhibo > > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, September 30, 2020 12:05 PM > Cc: lsr@ietf.org > Subject: Re: [Lsr] New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > > I am missing something in this discussion of multiple algorithms. > > My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is > that you need to associated a forwarding label (e.g. MPLS label or IPv6 > address) with a specific algorithm so that you can compute the next hope > for the forwarding label using the proper algorithm. Then when a packet > arrives, it is simply forwarded according to the forwarding table (e.g. > FIB, LIB, ..) > > If that is so, then I do not understand how a given prefix can be safely > associated with more than one algorithm. I could imagine doing several > calculations according to different algorithms. But how do you decide > which one applies to the packet? As far as I know, flex-algo does not look > at the QoS/CoS/ToS bits. > > Yours, > Joel > > PS: I will admit that it took until an operator described some > "interesting" constraints before I understood why one would even do this. > > On 9/29/2020 11:50 PM, Huzhibo wrote: > > Hi. > > > > Associating multiple algorithms with a given prefix is an interesting > topic, and I think this can simplify the complexity of FlexAlgo. I wonder > if the author would consider using cases with multiple algorithms with a > given prefix. > > > > Thanks > > > > ZHibo > > > > -----Original Message----- > > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li > > Sent: Tuesday, September 29, 2020 10:05 PM > > To: Ron Bonica > > Cc: lsr@ietf.org > > Subject: Re: [Lsr] New Version Notification for > > draft-bonica-lsr-ip-flexalgo-00.txt > > > > > > Ron, > > > > This is nice. It makes it clear that constraint based path computation > need not have MPLS overhead for those that don’t want it. > > > > One thing that you don’t talk about is how this gets used, tho that may > be blindingly obvious: you’ll need all nodes placing their prefixes in the > RIB/FIB, where it will need to be selected over other path computation for > the same prefixes. This somewhat precludes the possibility of a given > prefix being useful in multiple flex-algos. > > > > More text on application would be most welcome, just to ensure that > we’re on the same page. > > > > Tony > > > > > >> On Sep 29, 2020, at 6:37 AM, Ron Bonica 40juniper@dmarc.ietf.org> wrote: > >> > >> > >> Please review and comment > >> > >>Ron > >> > >> > >> > >> Juniper Business Use Only > >> > >>> -Original Message- > >>> From: internet-dra...@ietf.org > >>> Sent: Tuesday, September 29, 2020 9:36 AM > >>> To: Parag Kaneriya ; Shraddha Hegde > >>> ; Ron Bonica ; Rajesh M > >>> ; William Britto A J > >>> Subject: New Version Notification for > >>> draft-bonica-lsr-ip-flexalgo-00.txt > >>> > >>> [External Email. Be cautious of content] > >>> > >>> > >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > >>> has been successfully submitted by Ron Bonica and posted to the IETF > >>> repository. > >>> > >>> Name: draft-bonica-lsr-ip-flexalgo > >>> Revision: 00 > >>> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > >>> Document date: 2020-09-29 > >>> Group: Individual Submission
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Hi Joel: For details about the method defined in RFC 6550. It uses the HBH option to carry the RPLInstaceID. The RPLInstaceID and FlexAlgoID are similar. Thanks Zhibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, September 30, 2020 12:05 PM Cc: lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt I am missing something in this discussion of multiple algorithms. My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you need to associated a forwarding label (e.g. MPLS label or IPv6 address) with a specific algorithm so that you can compute the next hope for the forwarding label using the proper algorithm. Then when a packet arrives, it is simply forwarded according to the forwarding table (e.g. FIB, LIB, ..) If that is so, then I do not understand how a given prefix can be safely associated with more than one algorithm. I could imagine doing several calculations according to different algorithms. But how do you decide which one applies to the packet? As far as I know, flex-algo does not look at the QoS/CoS/ToS bits. Yours, Joel PS: I will admit that it took until an operator described some "interesting" constraints before I understood why one would even do this. On 9/29/2020 11:50 PM, Huzhibo wrote: > Hi. > > Associating multiple algorithms with a given prefix is an interesting topic, > and I think this can simplify the complexity of FlexAlgo. I wonder if the > author would consider using cases with multiple algorithms with a given > prefix. > > Thanks > > ZHibo > > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li > Sent: Tuesday, September 29, 2020 10:05 PM > To: Ron Bonica > Cc: lsr@ietf.org > Subject: Re: [Lsr] New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > > > Ron, > > This is nice. It makes it clear that constraint based path computation need > not have MPLS overhead for those that don’t want it. > > One thing that you don’t talk about is how this gets used, tho that may be > blindingly obvious: you’ll need all nodes placing their prefixes in the > RIB/FIB, where it will need to be selected over other path computation for > the same prefixes. This somewhat precludes the possibility of a given prefix > being useful in multiple flex-algos. > > More text on application would be most welcome, just to ensure that we’re on > the same page. > > Tony > > >> On Sep 29, 2020, at 6:37 AM, Ron Bonica >> wrote: >> >> >> Please review and comment >> >>Ron >> >> >> >> Juniper Business Use Only >> >>> -Original Message- >>> From: internet-dra...@ietf.org >>> Sent: Tuesday, September 29, 2020 9:36 AM >>> To: Parag Kaneriya ; Shraddha Hegde >>> ; Ron Bonica ; Rajesh M >>> ; William Britto A J >>> Subject: New Version Notification for >>> draft-bonica-lsr-ip-flexalgo-00.txt >>> >>> [External Email. Be cautious of content] >>> >>> >>> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt >>> has been successfully submitted by Ron Bonica and posted to the IETF >>> repository. >>> >>> Name: draft-bonica-lsr-ip-flexalgo >>> Revision: 00 >>> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks >>> Document date: 2020-09-29 >>> Group: Individual Submission >>> Pages: 14 >>> URL: >>> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- >>> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ >>> Status: >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b >>> o >>> nica-lsr- >>> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ >>> Htmlized: >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr >>> a >>> ft- >>> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ >>> Htmlized: >>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >>> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- >>> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ >>> >>> >>> Abstract: >>>An IGP Flexible Algorithm computes a
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
I am missing something in this discussion of multiple algorithms. My understanding of flex-algo whether for MPLS, SRv6, SRH, or IPv6, is that you need to associated a forwarding label (e.g. MPLS label or IPv6 address) with a specific algorithm so that you can compute the next hope for the forwarding label using the proper algorithm. Then when a packet arrives, it is simply forwarded according to the forwarding table (e.g. FIB, LIB, ..) If that is so, then I do not understand how a given prefix can be safely associated with more than one algorithm. I could imagine doing several calculations according to different algorithms. But how do you decide which one applies to the packet? As far as I know, flex-algo does not look at the QoS/CoS/ToS bits. Yours, Joel PS: I will admit that it took until an operator described some "interesting" constraints before I understood why one would even do this. On 9/29/2020 11:50 PM, Huzhibo wrote: Hi. Associating multiple algorithms with a given prefix is an interesting topic, and I think this can simplify the complexity of FlexAlgo. I wonder if the author would consider using cases with multiple algorithms with a given prefix. Thanks ZHibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Tuesday, September 29, 2020 10:05 PM To: Ron Bonica Cc: lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Ron, This is nice. It makes it clear that constraint based path computation need not have MPLS overhead for those that don’t want it. One thing that you don’t talk about is how this gets used, tho that may be blindingly obvious: you’ll need all nodes placing their prefixes in the RIB/FIB, where it will need to be selected over other path computation for the same prefixes. This somewhat precludes the possibility of a given prefix being useful in multiple flex-algos. More text on application would be most welcome, just to ensure that we’re on the same page. Tony On Sep 29, 2020, at 6:37 AM, Ron Bonica wrote: Please review and comment Ron Juniper Business Use Only -Original Message- From: internet-dra...@ietf.org Sent: Tuesday, September 29, 2020 9:36 AM To: Parag Kaneriya ; Shraddha Hegde ; Ron Bonica ; Rajesh M ; William Britto A J Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt [External Email. Be cautious of content] A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt has been successfully submitted by Ron Bonica and posted to the IETF repository. Name: draft-bonica-lsr-ip-flexalgo Revision: 00 Title: IGP Flexible Algorithms (Flexalgo) In IP Networks Document date: 2020-09-29 Group: Individual Submission Pages: 14 URL: https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bo nica-lsr- ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ Htmlized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra ft- bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ Htmlized: https://urldefense.com/v3/__https://tools.ietf.org/html/draft- bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ Abstract: An IGP Flexible Algorithm computes a constraint-based path and maps that path to an identifier. As currently defined, Flexalgo can only map the paths that it computes to Segment Routing (SR) identifiers. Therefore, Flexalgo cannot be deployed in the absence of SR. This document extends Flexalgo, so that it can map the paths that it computes to IP addresses. This allows Flexalgo to be deployed in any IP network, even in the absence of SR. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Hi. Associating multiple algorithms with a given prefix is an interesting topic, and I think this can simplify the complexity of FlexAlgo. I wonder if the author would consider using cases with multiple algorithms with a given prefix. Thanks ZHibo -Original Message- From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li Sent: Tuesday, September 29, 2020 10:05 PM To: Ron Bonica Cc: lsr@ietf.org Subject: Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt Ron, This is nice. It makes it clear that constraint based path computation need not have MPLS overhead for those that don’t want it. One thing that you don’t talk about is how this gets used, tho that may be blindingly obvious: you’ll need all nodes placing their prefixes in the RIB/FIB, where it will need to be selected over other path computation for the same prefixes. This somewhat precludes the possibility of a given prefix being useful in multiple flex-algos. More text on application would be most welcome, just to ensure that we’re on the same page. Tony > On Sep 29, 2020, at 6:37 AM, Ron Bonica > wrote: > > > Please review and comment > > Ron > > > > Juniper Business Use Only > >> -Original Message- >> From: internet-dra...@ietf.org >> Sent: Tuesday, September 29, 2020 9:36 AM >> To: Parag Kaneriya ; Shraddha Hegde >> ; Ron Bonica ; Rajesh M >> ; William Britto A J >> Subject: New Version Notification for >> draft-bonica-lsr-ip-flexalgo-00.txt >> >> [External Email. Be cautious of content] >> >> >> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >> >> Name: draft-bonica-lsr-ip-flexalgo >> Revision: 00 >> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks >> Document date: 2020-09-29 >> Group: Individual Submission >> Pages: 14 >> URL: >> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- >> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ >> Status: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bo >> nica-lsr- >> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ >> Htmlized: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dra >> ft- >> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ >> Htmlized: >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ >> >> >> Abstract: >> An IGP Flexible Algorithm computes a constraint-based path and maps >> that path to an identifier. As currently defined, Flexalgo can only >> map the paths that it computes to Segment Routing (SR) identifiers. >> Therefore, Flexalgo cannot be deployed in the absence of SR. >> >> This document extends Flexalgo, so that it can map the paths that it >> computes to IP addresses. This allows Flexalgo to be deployed in any >> IP network, even in the absence of SR. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Not sure whether the use case that the underlay network and the overlay network that belong to two different administrations is within this scope ? or has it already been covered by some other draft or RFCs? Assuming there are multiple underlay paths from A to B. Overlay would like to influence underlay path selections. How the best route can be selected, how the traffic can be forwarded (for example, overlay is IPSec traffic) ? Jay On Tue, Sep 29, 2020 at 7:05 AM wrote: > > Ron, > > This is nice. It makes it clear that constraint based path computation > need not have MPLS overhead > for those that don’t want it. > > One thing that you don’t talk about is how this gets used, tho that may be > blindingly obvious: you’ll need > all nodes placing their prefixes in the RIB/FIB, where it will need to be > selected over other path computation > for the same prefixes. This somewhat precludes the possibility of a given > prefix being useful in multiple > flex-algos. > > More text on application would be most welcome, just to ensure that we’re > on the same page. > > Tony > > > > On Sep 29, 2020, at 6:37 AM, Ron Bonica 40juniper@dmarc.ietf.org> wrote: > > > > > > Please review and comment > > > > Ron > > > > > > > > Juniper Business Use Only > > > >> -Original Message- > >> From: internet-dra...@ietf.org > >> Sent: Tuesday, September 29, 2020 9:36 AM > >> To: Parag Kaneriya ; Shraddha Hegde > >> ; Ron Bonica ; Rajesh M > >> ; William Britto A J > >> Subject: New Version Notification for > draft-bonica-lsr-ip-flexalgo-00.txt > >> > >> [External Email. Be cautious of content] > >> > >> > >> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt > >> has been successfully submitted by Ron Bonica and posted to the IETF > >> repository. > >> > >> Name: draft-bonica-lsr-ip-flexalgo > >> Revision: 00 > >> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks > >> Document date: 2020-09-29 > >> Group: Individual Submission > >> Pages: 14 > >> URL: > https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- > >> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- > >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ > >> Status: > >> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr- > >> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- > >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ > >> Htmlized: > >> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- > >> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- > >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ > >> Htmlized: > https://urldefense.com/v3/__https://tools.ietf.org/html/draft- > >> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- > >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ > >> > >> > >> Abstract: > >> An IGP Flexible Algorithm computes a constraint-based path and maps > >> that path to an identifier. As currently defined, Flexalgo can only > >> map the paths that it computes to Segment Routing (SR) identifiers. > >> Therefore, Flexalgo cannot be deployed in the absence of SR. > >> > >> This document extends Flexalgo, so that it can map the paths that it > >> computes to IP addresses. This allows Flexalgo to be deployed in any > >> IP network, even in the absence of SR. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > >> > > ___ > > Lsr mailing list > > Lsr@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwIGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=cCA4pT7B_XmVlm12wpR4lB8ideM42mfE4yk5tEwjlK4&s=lJXEm1gLCAl2E5l2C-XXRX4qbO_RC3OFJ4yfYj1xPKY&e= > > ___ > Lsr mailing list > Lsr@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_lsr&d=DwIGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=cCA4pT7B_XmVlm12wpR4lB8ideM42mfE4yk5tEwjlK4&s=lJXEm1gLCAl2E5l2C-XXRX4qbO_RC3OFJ4yfYj1xPKY&e= > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt
Ron, This is nice. It makes it clear that constraint based path computation need not have MPLS overhead for those that don’t want it. One thing that you don’t talk about is how this gets used, tho that may be blindingly obvious: you’ll need all nodes placing their prefixes in the RIB/FIB, where it will need to be selected over other path computation for the same prefixes. This somewhat precludes the possibility of a given prefix being useful in multiple flex-algos. More text on application would be most welcome, just to ensure that we’re on the same page. Tony > On Sep 29, 2020, at 6:37 AM, Ron Bonica > wrote: > > > Please review and comment > > Ron > > > > Juniper Business Use Only > >> -Original Message- >> From: internet-dra...@ietf.org >> Sent: Tuesday, September 29, 2020 9:36 AM >> To: Parag Kaneriya ; Shraddha Hegde >> ; Ron Bonica ; Rajesh M >> ; William Britto A J >> Subject: New Version Notification for draft-bonica-lsr-ip-flexalgo-00.txt >> >> [External Email. Be cautious of content] >> >> >> A new version of I-D, draft-bonica-lsr-ip-flexalgo-00.txt >> has been successfully submitted by Ron Bonica and posted to the IETF >> repository. >> >> Name: draft-bonica-lsr-ip-flexalgo >> Revision: 00 >> Title: IGP Flexible Algorithms (Flexalgo) In IP Networks >> Document date: 2020-09-29 >> Group: Individual Submission >> Pages: 14 >> URL: >> https://urldefense.com/v3/__https://www.ietf.org/id/draft-bonica- >> lsr-ip-flexalgo-00.txt__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck80Zbjoij$ >> Status: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-lsr- >> ip-flexalgo/__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck8x7e5ZqI$ >> Htmlized: >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft- >> bonica-lsr-ip-flexalgo__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck82w_6CyU$ >> Htmlized: >> https://urldefense.com/v3/__https://tools.ietf.org/html/draft- >> bonica-lsr-ip-flexalgo-00__;!!NEt6yMaO-gk!X7PVDP- >> FnUA0oCcZMw3Qde6in0C72hu_9hOZ53kPspIarR8fNDyU9Vck81_QrJ_p$ >> >> >> Abstract: >> An IGP Flexible Algorithm computes a constraint-based path and maps >> that path to an identifier. As currently defined, Flexalgo can only >> map the paths that it computes to Segment Routing (SR) identifiers. >> Therefore, Flexalgo cannot be deployed in the absence of SR. >> >> This document extends Flexalgo, so that it can map the paths that it >> computes to IP addresses. This allows Flexalgo to be deployed in any >> IP network, even in the absence of SR. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
