Re: [Lsr] [Need AD’s Judgement and Explanation] Re: Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
Peter Psenak <ppsenak@cisco.com> Mon, 16 May 2022 17:24 UTC
Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89934C1D5ADE; Mon, 16 May 2022 10:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.03
X-Spam-Level:
X-Spam-Status: No, score=-12.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.575, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIyhOEdoT3-Y; Mon, 16 May 2022 10:23:59 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044ACC20D640; Mon, 16 May 2022 10:23:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21827; q=dns/txt; s=iport; t=1652721839; x=1653931439; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=H/oxEDZp4Jeu6hCeqLMOBGm6+/yAdwTdUEvWAcBTUOE=; b=QYQP9OuKvePGR3l4+Hj+HsGwRXt1qPIcraE1XhKtg2ivrKlFiHisooTT UWMfbxfulrKANLjtEyQw0d1Wr05J/vSjUTyf3NEGey+lP6ON8kcK6rTPb u7lbLHnwraKNNl3tJ2E8sZo4/NBRl8t1kVEjbBitABrrUtlMKoRX6OBk9 k=;
X-IPAS-Result: A0ADAABsh4Ji/xbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgTsEAQEBAQELAYMhVCsSQ4ROiCFfiAsDgROKAYUzjB2BdwULAQEBDywPBwQBAYR4AQkChUAmNAkOAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEgQkThWgNhkIBAQEBAwEBGAMGDwEFNgQHEAkCEQMBAgECAh8EAwICIQYfCQgGAQkDBgIBAYJ5AYJjAzEPkEWbF3qBMYEBg2VBgn8NZ4FfBoEQLAGGFQNYgy2EQkOBSUSBFAEngkwHMD6CIEIBAQIBgTRPBoMqgmUEX44fhwcoBA8DHSYKGgMIAjwRCRc9DYEcEoEhcQEKBgMDBwoFMgYCDBkUBAIVEVMeAhMFBwoGFg4UHCkZDA8DEgMRAQcCCxIIFSwIAwIDCAMCAyMLAgMYCQcKAx0IChwSEBQCBBMeCwgDGh8tCQIEDgNDCAsKAxEEAxMYCxYIEAQGAwkvDSgLAwUPDwEGAwYCBQUBAyADFAMFJwcDIQcLJg0NBBwHHQMDBSYDAgIbBwICAwIGFwYDbwooDQgECAQcHyYTBQIHMQUELgIhBAUGEQkCFgIGBAUCBAQWAgISCAIIJxsHFhkdGQEFXgYLCSMcCiQNBgUGHgYiARsCUpJQg0+BDAEQDw4+agQUHgYTBgIEQgkHBSAFRRUEAQoBExYfAQgCDQQpA5FqBSyDBYsDnxBFa4NWhBeHA4cHh2yCY4MFBg8ELYN1jD6GLy+ONYIXepZmIIIqil2DWZBsBASBe4M4NYEsPIFZMxoIGxU7gmhRGQ+IAIZXiE+FTEIxAjkCBgEKAQEDCQGBVox7gkgBAQ
IronPort-Data: A9a23:6cRdgatlUCb/X9WFpqxWATKqSufnVHJfMUV32f8akzHdYApBsoF/q tZmKWyHPqyDNmSheI9/bty3904P75LXztAyTAI6rSowRikVgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0vraP65xZVF/fngbqLmD+LZMTxGSwZhSSMw4TpugOdRbrRA2bBVOCvQ/ 4KryyHjEAX9gWQsbztKs/vrRC5H5ZwehhtJ5jTSWtgT1LPuvyF9JI4SI6i3M0z5TuF8dgJtb 7+epF0R1jqxEyYFUrtJoJ6iGqE5auK60Ty1t5Zjc/PKbi6uCcAF+v1T2PI0MS+7gtgS9jx74 I0lWZeYEW/FMkBQ8QgQe0EwLs1wAUFJ0ObgeCGAq8mN9W39cyHt3ellHh4zB6RNr46bAUkWn RAZADkAdFWIgPi7he79Qeh3jcNlJ87uVG8dkig/lneCXbB8GcuFGf+iCdxwhF/cguhWBe3TY cMaQTFudx/HJRZIPz/7DbpnwLvw3CmjG9FegHG0u6Bw8TSO9yVs/qnmFcfyJ/uEZNoAyy50o UqDpQwVGCoyOMaWxybA83+wiKrLhjm+WZpXGrm15vduj1q7x2EPBlsRT1TTif2ikGa/Vs5Rb UsO9UIGrqUu/Uq3CNjwQxOQr3uNvxpaUN1Ve8U45xqlyLfS4h6UHC4CQyIpQNUtucJjGWQh1 0SCmJXiAjlHvLicU3nb97qIo3W1Iyd9BXALYyANTAkY5fH/u4A1gRLSR5BkCqHzhdudJN3r6 zmHtm0/n7IJkYsN3rn99lHciDXqrZ/MJuIo2jjqsquexlsRTOaYi0aAsDA3Md4owF6lc2S8
IronPort-HdrOrdr: A9a23:HGBVn6DJrizDztvlHemd55DYdb4zR+YMi2TDGXoBKiC9Afb4qy nIpoV86faUskd3ZJhOo7290cW7MBbhHNtOkO0s1NSZMDUO2lHDEGgK1+KLqAEIWReOlNK1vp 0PT0ERMr3N5BRB4voTJGKDYq4dKB7tytHQudvj
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208";a="1440284"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 May 2022 17:23:56 +0000
Received: from [10.60.140.57] (ams-ppsenak-nitro8.cisco.com [10.60.140.57]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 24GHNt2o020973; Mon, 16 May 2022 17:23:56 GMT
Message-ID: <8ddcc458-47ca-a7df-a9b1-c20a2c413b37@cisco.com>
Date: Mon, 16 May 2022 19:23:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, jgs@juniper.net
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, lsr@ietf.org, draft-ietf-lsr-ip-flexalgo@ietf.org
References: <8CD5F191-1DFE-46C7-86D1-ADAAB26385F5@cisco.com> <FE8AD071-E77D-4C77-8CE2-3A7FF1E5FFD7@tsinghua.org.cn>
From: Peter Psenak <ppsenak@cisco.com>
In-Reply-To: <FE8AD071-E77D-4C77-8CE2-3A7FF1E5FFD7@tsinghua.org.cn>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.57, ams-ppsenak-nitro8.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/DbFUxLIV4cgl63lhvkWmgvWvomU>
Subject: Re: [Lsr] [Need AD’s Judgement and Explanation] Re: Working Group Last Call for draft-ietf-lsr-ip-flexalgo-04 - "IGP Flexible Algorithms (Flex-Algorithm) In IP Networks"
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 May 2022 17:24:03 -0000
Aijun, please read the responses from Les and myself on this matter. We can not use legacy advertisement of prefix for IP algp prefixes, because legacy routers would treat this as valid advertisement of prefix in algo-0. If that happens routers with IP algpo support would calculate the path on a different topology than the routers that do not support IP algo. That at the end would result in permanent loops. I don't know what else to add. Seems obvious to me. thanks, Peter On 16/05/2022 17:35, Aijun Wang wrote: > 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 > <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 <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. > > > 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) >> <acee=40cisco.com@dmarc.ietf.org> 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 <wangaijun@tsinghua.org.cn> >> *Date: *Saturday, May 14, 2022 at 11:19 PM >> *To: *Acee Lindem <acee@cisco.com> >> *Cc: *"Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Ketan Talaulikar >> <ketant.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, >> "draft-ietf-lsr-ip-flexalgo@ietf.org" >> <draft-ietf-lsr-ip-flexalgo@ietf.org> >> *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) >> <acee=40cisco.com@dmarc.ietf.org> 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" >> <lsr-bounces@ietf.org on behalf of ppsenak=40cisco.com@dmarc.ietf.org> >> 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 <ppsenak@cisco.com >> >> <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> 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 >> <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 >> <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) >> >>> <acee=40cisco.com@dmarc.ietf.org >> >> <mailto:40cisco.com@dmarc.ietf.org >> <mailto:40cisco.com@dmarc.ietf.org>> >> >> <mailto:40cisco.com@dmarc.ietf.org >> >> <mailto:40cisco.com@dmarc.ietf.org >> <mailto:40cisco.com@dmarc.ietf.org>>>> 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 >> >>> Lsr@ietf.org <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>> >> <mailto:Lsr@ietf.org >> >> <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>>> >> >>> 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>> >> >>> <https://www.ietf.org/mailman/listinfo/lsr >> >> <https://www.ietf.org/mailman/listinfo/lsr >> <https://www.ietf.org/mailman/listinfo/lsr>>> >> >>> >> >> >> > >> > _______________________________________________ >> > Lsr mailing list >> > Lsr@ietf.org >> > https://www.ietf.org/mailman/listinfo/lsr >> <https://www.ietf.org/mailman/listinfo/lsr> >> > >> >> > _______________________________________________ >> > Lsr mailing list >> > Lsr@ietf.org >> > https://www.ietf.org/mailman/listinfo/lsr >> <https://www.ietf.org/mailman/listinfo/lsr> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr
- [Lsr] Working Group Last Call for draft-ietf-lsr-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Huzhibo
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… John E Drake
- Re: [Lsr] Working Group Last Call for draft-ietf-… Robert Raszuk
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ron Bonica
- Re: [Lsr] Working Group Last Call for draft-ietf-… Dongjie (Jimmy)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Dongjie (Jimmy)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Les Ginsberg (ginsberg)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Parag Kaneriya
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Gyan Mishra
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Aijun Wang
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Peter Psenak
- Re: [Lsr] Working Group Last Call for draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Working Group Last Call for draft-ietf-… Ketan Talaulikar
- [Lsr] [Need AD’s Judgement and Explanation] Re: W… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… John Scudder
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Peter Psenak
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Acee Lindem (acee)
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… John E Drake
- Re: [Lsr] [Need AD’s Judgement and Explanation] R… Aijun Wang