Hi, Acee: Would you like to give one example to support your “loop” assertions?
Aijun Wang China Telecom > On May 16, 2022, at 23:41, Acee Lindem (acee) > <[email protected]> wrote: > > > > > From: Aijun Wang <[email protected]> > Date: Monday, May 16, 2022 at 11:35 AM > To: Acee Lindem <[email protected]>, John Scudder <[email protected]> > Cc: "Peter Psenak (ppsenak)" <[email protected]>, Ketan Talaulikar > <[email protected]>, "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: [Need AD’s Judgement and Explanation] Re: [Lsr] Working Group Last > Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms > (Flex-Algorithm) In IP Networks" > > Hi, Acee: > I am curious that you are so hurry to forward this document. > The updated document just describes the followings: > (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-06#section-6) > > “To be able to associate the prefix with the Flex-Algorithm, the > existing prefix reachability advertisements can not be used, because > they advertise the prefix reachability in default algorithm 0. > Instead, a new IP Flex-Algorithm reachability advertisements are > defined in IS-IS and OSPF.” > > If the above statement is valid, then why the FAPM defined in the base > document can be the sub-TLV of existing prefix advertisements? > Please also refer to the IANA allocation table > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-prefix-reachability > > And, I see no any clue of different flex-Algo will influence each other: > > If the router doesn’t support FAPM sub-TLV(doesn’t not support flex-Algo) or > the FAPM sub-TLV doesn’t present in the prefix advertisements , the prefixes > will be calculated in algorithm 0. If the router support FAPM sub-TLV(support > flex-Algo) and FAPM is present, the associated prefixes will be calculated in > the appointed Flex-Algorithm. > > And this is undesired and can result in loops. > > Acee > > > > > > What’s the difficulty? > > I have also noticed your statement in the document write up, but you and the > authors’ responses to the concerns are unreasonable. > > Should the AD make the final judgment and give one reasonable explanation? > > I respect the works of the authors and all the reviewers’ and shepherd’s > efforts, but think this is not the right direction to accomplish the aim. > > > Aijun Wang > China Telecom > > > On May 16, 2022, at 19:50, Acee Lindem (acee) > <[email protected]> wrote: > > Hi Aijun, > > We need to support mixed deployments of routers that do and do not support > flex algorithm and in these deployments the default algorithm, i.e., > algorithm 0, computation must not be impacted. This is clearly stated in the > draft. Your suggestion is noted but what you are suggesting doesn’t satisfy > these requirements. > > Thanks, > Acee > > From: Aijun Wang <[email protected]> > Date: Saturday, May 14, 2022 at 11:19 PM > To: Acee Lindem <[email protected]> > Cc: "Peter Psenak (ppsenak)" <[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, Acee and Peter: > I don’t still think this document is necessary, unless you can answer the > following questions clearly: > 1) Section 5 about the “Advertising IP Flex-Algorithm Reachability” are not > necessary, since every FAD has need advertised in the FAD advertisements. > There is no such participations advertisements for SR and SRv6 dataplane. > Only the node participations should be advertised, as that described in the > base document. > 2) Section 6 about the “Advertisements IP Flex-Algorithm Reachability” is > also redundant. The FAPM defined in the base document can transfer the same > information, what’s the reason to define the new one? > 3) Section 7 can be added to the section 14 “Flex-Algorithm and Forwarding > Plane” of the base document. This section just describes how to apply the > Flex-Algorithm to different data plane, why not use the FAPM directly to > achieve such goal? No new TLV/sub-TLVs are needed. > 4) There is no more additional information for section 8-10, compared to the > base document. > 5) For the IANA part of IS—IS, redundant information will be exist in two > code points. The inconsistency will be emerged later when the additional > sub-TLV is added under this code point. > > In conclusion, reusing the FAPM is the right direction to solve the mentioned > use case in the updated draft. > > Aijun Wang > China Telecom > > > On May 14, 2022, at 04:29, Acee Lindem (acee) > > <[email protected]> wrote: > > > > Hi Peter, > > > > Thanks for addressing the WG last comments relating to terminology and IGP > > flex-algorithm data-plane granularity. I also have some editorial comments > > attached. These include: > > > > 1. Remove "new" from the text since these specifications will not be new > > when they are published. > > 2. Fix the reference to the OSPFv3 Router Information Opaque LSA. As you > > know, there are no opaque LSAs in OSPFv3 since OSPFv3 natively supports LSA > > compatibility. > > 3. Replace "ISIS" with "IS-IS". > > 4. Use American English spellings consistent with RFC style. > > > > One comments, for situations where we don't install any route in the > > data-plane, should we recommend logging an error? For example, in RFC 7684, > > we say: > > > > This situation SHOULD be logged as an error. > > > > I was tempted to hyphenate "Flex-algorithm specific" and "algorithm > > specific" but didn't since they aren't in the base Flex-Algo specification. > > > > > > Thanks, > > Acee > > > > > > > > > > > > On 5/13/22, 9:59 AM, "Lsr on behalf of Peter Psenak" <[email protected] > > on behalf of [email protected]> wrote: > > > > Hi Ketan, > > > > sure, thanks for catching those, I'll fix them in next revision. > > > > thanks, > > Peter > > > > > >> On 13/05/2022 15:32, Ketan Talaulikar wrote: > >> Hi Peter, > >> > >> Thanks for your updates to the draft and your responses below. > >> > >> I would like to point out a few remaining points to be fixed/addressed. > >> > >> a) There is a discrepancy regarding the size of the Metric field for the > >> OSPFv2 IP Algo Reachability sub-TLV between the figure and the text > >> description. The text needs to be fixed to reflect 4 octets size. > >> > >> b) For the OSPFv3 IP Algo Prefix Reachability sub-TLV the Type should be > >> 2 octets and the discrepancy in the sub-TLV name in the Figure needs to > >> be corrected. Length should now become 8. > >> > >> c) The references to the sections of draft-lsr-flex-algo in this > >> document need corrections in Sec 7 ? In general, I think the references > >> to the base draft sections 11, 12, and 13 (except that M-flag is always > >> used) would be helpful. > >> > >> Thanks, > >> Ketan > >> > >> On Wed, May 11, 2022 at 3:20 PM Peter Psenak <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi Ketan, > >> > >> > >> please see 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 > >> Done > >> > >>> > >>> 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 > >> this has been discussed previously in this thread. > >> > >> > >>> > >>> 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 > >> Done > >> > >>> > >>> 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. > >> > >> > >> ##PP > >> Done > >> > >>> > >>> 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. > >> > >> > >> ##PP > >> Done > >> > >> > >>> > >>> 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. > >> > >> > >> ##PP > >> Done. For section 6, I would prefer to keep it in the protocol specific > >> sections. > >> > >>> > >>> 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. > >> > >> ##PP > >> I prefer to keep the MUSTs there > >> > >>> > >>> 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. > >> > >> ##PP > >> Done. > >> > >>> > >>> > >>> 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. > >> > >> ##PP > >> Done > >> > >>> > >>> > >>> 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. > >> > >> ##PP > >> Done > >> > >>> > >>> > >>> 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 > >> > >> <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 > >> <https://datatracker.ietf.org/doc/html/rfc7684>>] is > >>> defined to advertise prefix reachability associated with a Flex- > >>> Algorithm in OSPFv2. > >> > >> ##PP > >> Done > >> > >>> > >>> 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. > >> > >> ##PP > >> > >> Why? We have a text that says: > >> > >> "This new TLV shares the sub-TLV space defined for TLVs 135, 235, 236 > >> and 237." > >> > >> Why do we need to describe the usage of the specific sub-TLV? > >> > >>> > >>> > >>> 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. > >> > >> ##PP > >> Done > >> > >>> > >>> > >>> 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. > >> > >> ##PP > >> Done > >> > >>> > >>> > >>> 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. > >> > >> ##PP > >> Done > >> > >>> > >>> > >>> 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? > >> > >> ##PP > >> Done > >> > >> > >>> > >>> > >>> 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" ? > >> > >> ##PP > >> Done > >> > >>> > >>> > >>> 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? > >>> > >>> This (in some way) goes back to my comment (2) above. > >> > >> ##PP > >> I don't see the relationship to BIER IPA here. > >> > >>> > >>> > >>> 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. > >> > >> ##PP > >> nothing prevents someone to advertise LDP label for the IP algo-prefix > >> and use it with the labeled forwarding. I don't see a problem. But this > >> specification does not specify any of it. > >> > >>> > >>> > >>> 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 > >> Done. > >> > >> thanks, > >> Peter > >>> > >>> > >>> Thanks, > >>> > >>> Ketan > >>> > >>> > >>> > >>> On Fri, Apr 8, 2022 at 12:38 AM Acee Lindem (acee) > >>> <[email protected] > >> <mailto:[email protected]> > >> <mailto:[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]> <mailto:[email protected] > >> <mailto:[email protected]>> > >>> https://www.ietf.org/mailman/listinfo/lsr > >> <https://www.ietf.org/mailman/listinfo/lsr> > >>> <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 > > > > _______________________________________________ > > Lsr mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
