Hi Acee, Regarding the draft-ietf-lsr-flex-algo, there are two aspects that I had brought up as part of the discussion on the IP FlexAlgo draft:
1) A purely editorial thing: the suggestion to use a term other than "application" for the data plane or forwarding mechanism related to FlexAlgo. Peter has suggested "data plane" and I am ok with that or a similar term (something other than "application" so it doesn't get mixed up with "application" as in ASLA). 2) The clarification on a per algo per "forwarding plane" computation requirement. This is not something specified clearly in draft-ietf-lsr-flex-algo and it is important that we do so using normative language since that document forms the flex algo base. Apart from the above, I do not have any other concerns or comments on that draft. Thanks, Ketan On Sun, Apr 17, 2022 at 3:15 AM Acee Lindem (acee) <[email protected]> wrote: > Speaking as WG member and document shepherd: > > > > Hi Gyan, > > > > Thanks for the explanation. My position is that the initial draft, > draft-ietf-lsr-flex-algo, and the encodings with their attendant > constraints on those encodings were targeted towards MPLS and SRv6. Given > that the draft has been in progress for a couple years and that there are > implementations, we don’t really gain anything by generalizing this draft. > This can come with draft-ietf-lsr-ip-flexalgo. Am I missing anything here? > This question is for Ketan as well… > > Thanks, > > Acee > > > > > > *From: *Lsr <[email protected]> on behalf of Gyan Mishra < > [email protected]> > *Date: *Friday, April 15, 2022 at 10:38 PM > *To: *Acee Lindem <[email protected]> > *Cc: *"[email protected]" <[email protected]>, Ketan Talaulikar < > [email protected]>, "[email protected]" < > [email protected]>, "Peter Psenak (ppsenak)" < > [email protected]> > *Subject: *Re: [Lsr] Working Group Last Call for > draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) > In IP Networks" > > > > > > Hi Acee > > > > Fixing a typo > > > > On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra <[email protected]> > wrote: > > > > Hi Acee > > > > My question cane up from the list of questions posed by Ketan and Peter’s > response to question #3. > > > > See excerpt below. > > > > I am confused by what Ketan stated in his question below and also Peter’s > response which is why I am asking the question again. > > > > I believe the goal of the draft is for Flex Ago to be deployed > independently of SR filling the gap of IGP Flex Algo providing that > solution. So based on what Ketan stated in his question that IGP Flex Algo > is data plane agnostic and can be used with IP data plane then there is no > gap to be filled by this draft. > > > > Maybe I am misreading Ketan’s question. > > > > So this is a very important point made by Ketan that if IGP Flex Algo is > open to usage “outside of SR”, then it is very important to restate the > goal of this draft, removing assertions in the draft that this draft is for > non SR IP data planes, as that can be accomplished today by IGP Flex Algo, > and the gap or new solution being filled by this draft is for IP prefix > based Flex Algo with Native IP Forwarding. > > > > This as well is quite confusing to me as if IGP Flex Algo can be used > outside of SR then can do everything that this draft is supposed to > accomplish. > > > > So what then is the purpose of this draft? > > > > In Peter’s response is stated that each Flex Algo data plane / app can be > deployed independently meaning this draft and IGP flex Algo can act as 2 > ships in the night. Also confusing. > > > > 3) This draft makes assertions that IGP FlexAlgo cannot be deployed > > without SR. This is not true since the base IGP FlexAlgo spec explicitly > > opens it up for usage outside of the SR forwarding plane. We already > > have BIER and MLDP forwarding planes as users of the IGP FlexAlgo. My > > suggestion is to remove such assertions from the document. It is > > sufficient to just say that the document enables the use of IGP FlexAlgo > > for IP prefixes with native IP forwarding. > > ##PP > where do you see such assertion? Each flex-algo data-plane/app can be > deployed independently. > > > > > > > > On Fri, Apr 15, 2022 at 7:51 PM Acee Lindem (acee) <[email protected]> wrote: > > Gyan, > > > > What is your point here? Is this a trick question? > > > > Thanks, > > Acee > > > > *From: *Gyan Mishra <[email protected]> > *Date: *Friday, April 15, 2022 at 5:31 PM > *To: *"Peter Psenak (ppsenak)" <[email protected]> > *Cc: *Acee Lindem <[email protected]>, Ketan Talaulikar < > [email protected]>, "[email protected]" < > [email protected]>, "[email protected]" <[email protected]> > *Subject: *Re: [Lsr] Working Group Last Call for > draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) > In IP Networks" > > > > > > Hi Peter > > > > My understanding is that the main goal of this draft is to be able to use > flex algo over IPv4 or IPv6 data plane as that is not possible with > existing Flex Algo which can only be used on SR data plane. > > > > Is that correct or am I missing something? > > > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo > > > > > > Abstract > > > > An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute > > constraint-based paths. As currently defined, IGP Flex-Algorithm is > > used with Segment Routing (SR) data planes - SR MPLS and SRv6. > > Therefore, Flex-Algorithm cannot be deployed in the absence of SR. > > > > This document extends IGP Flex-Algorithm, so that it can be used for > > regular IPv4 and IPv6 prefixes. This allows Flex-Algorithm to be > > deployed in any IP network, even in the absence of SR. > > > > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-19 > > > > Abstract > > > > IGP protocols traditionally compute best paths over the network based > > on the IGP metric assigned to the links. Many network deployments > > use RSVP-TE based or Segment Routing based Traffic Engineering to > > steer traffic over a path that is computed using different metrics or > > constraints than the shortest IGP path. This document proposes a > > solution that allows IGPs themselves to compute constraint-based > > paths over the network. This document also specifies a way of using > > Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets > > along the constraint-based paths. > > > > Kind Regards > > > > Gyan > > > > > > On Mon, Apr 11, 2022 at 3:37 AM Peter Psenak <ppsenak= > [email protected]> wrote: > > Hi Ketan, > > please responses to some of your comments inline (##PP): > > On 11/04/2022 08:25, Ketan Talaulikar wrote: > > Hello All, > > > > Following are some comments on this draft: > > > > 1) Is this draft about opening the use of all IGP Algorithms for IP > > (Algo) Routing or intended to be specific to Flexible Algorithms (i.e. > > algo 128-255) alone. I think it is important to specify the scope > > unambiguously. Perhaps it makes sense to restrict the usage in this > > particular document to FlexAlgorithms alone. If not, the draft probably > > needs an update and we need to also cover algo 1 (Strict SPF) > > applicability and update the text to refer more generically to > > algo-specific IP routing. > > ##PP > the intent is to use FlexAlgorithms only. > > > > > 2) The relationship between the algo usage for IP FlexAlgo and other > > data planes (e.g. FlexAlgo with SR) is not very clear. There arise > > complications when the algo usage for IP FlexAlgo overlap with other > > (say SR) data planes since the FAD is shared but the node participation > > is not shared. While Sec 9 suggests that we can work through these > > complications, I question the need for such complexity. The FlexAlgo > > space is large enough to allow it to be shared between various data > > planes without overlap. My suggestion would be to neither carve out > > parallel algo spaces within IGPs for various types of FlexAlgo data > > planes nor allow the same algo to be used by both IP and SR data planes. > > So that we have a single topology computation in the IGP for a given > > algo based on its FAD and data plane participation and then when it > > comes to prefix calculation, the results could involve programming of > > entries in respective forwarding planes based on the signaling of the > > respective prefix reachabilities. The coverage of these aspects in a > > dedicated section upfront will help. > > ##PP > I strongly disagree. > > FAD is data-pane/app independent. Participation is data-plane/app > dependent. Base flex-algo specification is very clear about that. That > has advantages and we do not want to modify that part. > > Topology calculation for algo/data-plane needs to take both FAD and > participation into account. You need independent calculation for each > data-plane/app in the same algo. > > The fact that the same FAD is shareable between all apps has it > advantages and use cases - e.g. if the participation for algo X is the > same in SR and IP data-planes, one can use SR to protect IP in that algo. > > > > > > 3) This draft makes assertions that IGP FlexAlgo cannot be deployed > > without SR. This is not true since the base IGP FlexAlgo spec explicitly > > opens it up for usage outside of the SR forwarding plane. We already > > have BIER and MLDP forwarding planes as users of the IGP FlexAlgo. My > > suggestion is to remove such assertions from the document. It is > > sufficient to just say that the document enables the use of IGP FlexAlgo > > for IP prefixes with native IP forwarding. > > ##PP > where do you see such assertion? Each flex-algo data-plane/app can be > deployed independently. > > > > > 4) The draft is mixing up "address" and "prefix" in some places. IGP > > path computation is for prefixes and not addresses. There are a few > > instances where "address" should be replaced by "prefix". References to > > RFC791 and RFC8200 seem unnecessary. > > > > 5) The draft does not cover the actual deployment use-case or > > applicability of IP FlexAlgo. The text in Sec 3 is not clear and > > insufficient. What is the point/use of sending traffic to a loopback of > > the egress router? Perhaps it makes sense in a deployment where IP-in-IP > > encapsulation is used for delivering an overlay service? If so, would be > > better to clarify this. The other deployment scenario is where > > "external" or "host/leaf prefixes" are associated with a FlexAlgo to > > provide them a different/appropriate routing path through the network. > > Yet another is the use of IP FlexAlgo along with LDP. Sec 9 does not > > address the topic well enough. I would suggest expanding and clarifying > > this and perhaps other such deployment use cases (or applicability) in > > the document in one of the earlier sections to provide a better context > > to the reader. > > > > 6) It would be better to move the common (i.e. not protocol specific) > > text from 5.1 and 5.2 under 5. This might also apply to some extent to > > the contents of sec 6. > > > > 7) Most of the text with MUSTs in sec 5 doesn't really make sense in > > repeating - this is covered in the base FlexAlgo spec already. The only > > key/important MUST is the one related to using separate algo for IP > > FlexAlgo over SR data planes. See my previous comment (2) above. > > > > 8) Sec 5.1, the SHOULD needs to be MUST in the text below. > > > > A router receiving multiple IP Algorithm > > sub-TLVs from the same originator SHOULD select the first > > advertisement in the lowest-numbered LSP and subsequent instances of > > the IP Algorithm Sub-TLV MUST be ignored. > > > > > > 9) Sec 5.1, I would suggest changing the following text as indicated. > > Also, perhaps add that the algo 0 MUST NOT be advertised and a receiver > > MUST ignore if it receives algo 0. > > OLD > > > > The IP Algorithm Sub-TLV could be used to advertise > > support for non-zero standard algorithms, but that is outside the > > scope of this document. > > > > NEW > > > > The use of IP Algorithm Sub-TLV to advertise support for algorithms > > > > outside the flex-algorithm range is outside the > > scope of this document. > > > > > > 10) Sec 5.1, the SHOULD needs to be MUST in the text below > > > > The IP Algorithm TLV is optional. It SHOULD only be advertised once > > in the Router Information Opaque LSA. > > > > > > 11) Sec 6. The following text is better moved into the respective > > protocol sub-sections. OSPFv3 is not covered anyway by it. > > > > Two new top-level TLVs are defined in ISIS [ISO10589 < > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#ref-ISO10589>] > to advertise > > prefix reachability associated with a Flex-Algorithm. > > > > * The IPv4 Algorithm Prefix Reachability TLV > > > > * The IPv6 Algorithm Prefix Reachability TLV > > > > New top-level TLV of OSPFv2 Extended Prefix Opaque LSA [RFC7684 < > https://datatracker.ietf.org/doc/html/rfc7684>] is > > defined to advertise prefix reachability associated with a Flex- > > Algorithm in OSPFv2. > > > > 12) Sec 6.1 & 6.2. There is no discussion regd the use of the Prefix > > Attribute Flags sub-TLV with the new top-level TLVs. > > > > I think their usage MUST (or at least SHOULD) be included as it helps > > determine the route type and prefix attributes that > > > > have proven to be quite useful for various use cases and deployments. > > > > > > 13) Sec 6.2 what happens when the same prefix is advertised as SRv6 > > Locator as well as IPv6 Algo Prefix (same or conflicting algos). Perhaps > > both must be ignored? > > > > The same applies for OSPFv3 as well. > > > > > > 14) Sec 6.3, OSPFv2 MT-ID reference should be RFC4915. Perhaps the range > > of MT should be mentioned since it is a 8 bit field here. > > > > > > 15) Sec 6.4, the metric field in the sub-TLV has to be 32-bit. While > > 24-bit is ok when the FAD uses IGP metric, it will not suffice for other > > IGP metric types. > > > > > > 16) Sec 6.3 & 6.4, the conflict checking with base algo 0 prefix > > reachability cannot be limited only to the OSPFv2/3 Extended LSAs but > > should also cover the base fixed form > > > > OSPFv2/v3 LSAs. We could use a more generic term like "normal prefix > > reachability" advertisements perhaps to cover the different LSAs? > > > > > > 17) Sec 7 and 8, suggest to not use the term "application" to avoid > > confusion with ASLA. My understanding is that there is a single FlexAlgo > > application when it comes to ASLA. > > > > Perhaps the intention here is "data plane" ? > > > > > > 18) The relationship between the BIER IPA and this draft needs some > > clarifications - should the BIER WG be notified if they want to update > > draft-ietf-bier-bar-ipa? > > ##PP > what is the relationship? I see none. > > > > > > This (in some way) goes back to my comment (2) above. > > > > > > 19) Sec 8, what prevents the use of IP FlexAlgo paths programmed by LDP > > as well. Or if the intention is to use them strictly for IP forwarding > only > > > > then this needs to be clarified. > > > > > > 20) The following text in Sec 9 is about using the same FlexAlgo (with a > > common definition) for multiple data-planes at the same time. The key is > > that we only are able to use > > > > prefix in one algo/data-plane? I am wondering if we can improve this > > text to bring this out in a better way. Or altogether remove this if we > > agree to not allow sharing of algo > > > > between different data planes to keep things simple. > > > > Multiple application can use the same Flex-Algorithm value at the > > > > same time and and as such share the FAD for it. For example SR-MPLS > > and IP can both use such common Flex-Algorithm. Traffic for SR-MPLS > > will be forwarded based on Flex-algorithm specific SR SIDs. Traffic > > for IP Flex-Algorithm will be forwarded based on Flex-Algorithm > > specific prefix reachability announcements. > > > ##PP > above text does not talk about the same prefix. It talks in general how > forwarding works in presence of multiple data-planes/apps using the same > algo. > > thanks, > Peter > > > > > > > Thanks, > > > > Ketan > > > > > > > > On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee) > > <[email protected] <mailto:[email protected]>> > wrote: > > > > This begins a WG last call for draft-ietf-lsr-ip-flexalgo-04. The > > draft had a lot of support and discussion initially and has been > > stable for some time. Please review and send your comments, support, > > or objection to this list before 12 AM UTC on April 22^nd , 2022.____ > > > > __ __ > > > > Thanks, > > Acee____ > > > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > -- > > *Error! Filename not specified.* <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
