Re: [Lsr] Using L1 for Transit Traffic in IS-IS
Gyan Mishra <hayabusagsm@gmail.com> Sat, 11 December 2021 01:46 UTC
Return-Path: <hayabusagsm@gmail.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 2EC523A00E1 for <lsr@ietfa.amsl.com>; Fri, 10 Dec 2021 17:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRlqG35XRcH8 for <lsr@ietfa.amsl.com>; Fri, 10 Dec 2021 17:46:26 -0800 (PST)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4993A0062 for <lsr@ietf.org>; Fri, 10 Dec 2021 17:46:26 -0800 (PST)
Received: by mail-pj1-x102e.google.com with SMTP id gx15-20020a17090b124f00b001a695f3734aso9017825pjb.0 for <lsr@ietf.org>; Fri, 10 Dec 2021 17:46:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o0GTNAdiSCTzoe7VAVreZzf0QiBk7b8hCyV2dBXmUGc=; b=iaXQ8Gal3Ca5357nhC6gXEFEFELl/naNLEND4o2piwtKhOjoTInBVTYkAv+9OkmZCw CR/gyrFnv9krLwFzzKiAxisITuck8cOKl/iaC7vaT3CEPNLPpBQaaVshb/9WfOJe/qFs VP8v1HXR1bc4lZriTTxH2mu7XXJBB/LNRyq2h4CwkAFFSGf6CbvSWNQ6T0eVWyZMcCr+ z6FaXUIxyQgPDue/n6djHXq9m7tOJtV5i7Ez5F8I9TmBayAv7ZT6NqSXo40bI5cHd6xJ e6/Sy74UKnTBOcYz2ckd/VAs7Iazl/TTVz7gdzq+hhLSEx1DxL2FaEZWSLFWPaWQWjdm su+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o0GTNAdiSCTzoe7VAVreZzf0QiBk7b8hCyV2dBXmUGc=; b=yJqyL0Odu8h4P47IU3BU82KC9rVu3J0vOwXMGaVM/vPYYgS6LifMpIsqDnZyygQgGp bAw9+xyuQNHxkpK1Bjk8a+32DH7m/c56HzRu3LnT0A+nrJ0IYOLUwHkSwN9o4AWy2Zi3 LDhLb5g2ktOm1ipRpco5bIgXVf7Jw/N/rOwJ8Tg7XaCaJD93+CIG2LHW5AO7fjx3Cyhg U96v3yj4EP6TUHho/YRIvEOI8rntnFuSPq4hHhIkVmPfIDaP1VnGMyPVDDBjZ2nJOM8w TC0aUBuTvp8ComQhb+Crg6CeVvwCvDATesCUQWGsAzasj7MXaKNREe8C/wYx/J6V5Rg4 YWzQ==
X-Gm-Message-State: AOAM530cYyEofS1dv+hK10e0YZTJOB+vtcYZ6kUzE+/HntGzF9RUtDiU pg+MPEzBe9wWF/WEiMB/37pKhFL4r2UmX13qAkA=
X-Google-Smtp-Source: ABdhPJx3QPX0SDPx0w5d5Rh88+oX2dnihQxSFxtHENSvjS57rwZRhiYnSLM+LnoUQxO7ZICJTijEnYV8Y7EIhO+QezY=
X-Received: by 2002:a17:902:be12:b0:142:431f:3d1c with SMTP id r18-20020a170902be1200b00142431f3d1cmr80472803pls.32.1639187185071; Fri, 10 Dec 2021 17:46:25 -0800 (PST)
MIME-Version: 1.0
References: <BY5PR11MB4337DC871267C75516B8309BC16F9@BY5PR11MB4337.namprd11.prod.outlook.com> <CA+wi2hNnQudSwufsa6eRMNsMhLSvVMtYYoAG31kqgqbJXO2Juw@mail.gmail.com> <BY5PR11MB4337796192B8CDB8FE94D289C1709@BY5PR11MB4337.namprd11.prod.outlook.com> <84AD12B5-D1DA-4686-8F7F-F41A2E04F6F2@cisco.com> <BY5PR11MB4337292B2B05F33145EE8AC0C1719@BY5PR11MB4337.namprd11.prod.outlook.com> <CAKz0y8yhS2Z6y_CLs=ugaHGfKX_4GFXPXFdTg9hQ4w4djVHi=Q@mail.gmail.com>
In-Reply-To: <CAKz0y8yhS2Z6y_CLs=ugaHGfKX_4GFXPXFdTg9hQ4w4djVHi=Q@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 10 Dec 2021 20:46:14 -0500
Message-ID: <CABNhwV0oZ5PCMgsB6hgjwWL3D3WU_OS_Aw_YdAKR5mBbRvmC5Q@mail.gmail.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Tony Li <tony.li@tony.li>, Tony Przygienda <tonysietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2fa2905d2d501d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/SCRhGzJK_uN9zx2NeaKGce8DUTc>
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 11 Dec 2021 01:46:31 -0000
All As Acee mentioned per the subject of this thread “Using L1 for transit traffic in IS-IS” is supported today and is deployed by operators with large backbones as well today, and both solutions, area proxy and flood reflection now allows the L1 transit solution to scale. Speaking from an operators perspective we are in favor of multiple solutions as their maybe use cases where one applies better then the other and vice versa. Flexibility is a good thing. Kind Regards Gyan On Fri, Dec 10, 2021 at 1:54 AM Muthu Arul Mozhi Perumal < muthu.arul@gmail.com> wrote: > Hi, > > It is possible to designate experimental RFCs as historic if there is no > evidence of widespread use over a period of time, as is currently being > done for HTTP-related experimental RFCs: > > https://datatracker.ietf.org/doc/status-change-http-experiments-to-historic/ > > Hence, I think having multiple experimental publications for a problem is > ok.. > > Regards, > Muthu > > On Fri, Dec 10, 2021 at 6:08 AM Les Ginsberg (ginsberg) <ginsberg= > 40cisco.com@dmarc.ietf.org> wrote: > >> Acee – >> >> >> >> Thanx for responding while you are on vacation. >> >> >> >> While it is true I am not enthusiastic about any of the solutions, my >> point of emphasis is that it’s a failure of WG process to simply move >> forward with all solutions – which it seems to me is what is about to >> happen. >> >> >> >> Note that this is completely consistent with what I said back when WG >> adoption for the drafts was being discussed (thanx to Tony P for pointing >> me back to that time (June 21, 2020)): >> >> >> >> *<snip>* >> >> *I support the WG adoption of >> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ >> <https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/> .* >> >> >> >> *(I also support WG adoption of >> https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection >> <https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection> )* >> >> >> >> *I believe the problem space addressed by these two drafts warrants >> attention.* >> >> *…* >> >> *The easy road for the WG to take would be to simply allow both drafts to >> proceed to Experimental RFCs, but I hope we are able to do more than this. >> Multiple solutions place undesirable burdens on vendors and providers >> alike.* >> >> >> >> *To the extent they feel comfortable, I encourage folks who wish to >> deploy such solutions to share their requirements and discuss how each of >> the solutions* >> >> *address their requirements/fall short of addressing their requirements. >> I think this would help the WG discover better ways forward.* >> >> >> >> *<end snip>* >> >> >> >> Don’t think we have made progress in that regard… >> >> >> >> Les >> >> >> >> >> >> *From:* Acee Lindem (acee) <acee@cisco.com> >> *Sent:* Thursday, December 9, 2021 1:59 PM >> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Tony Przygienda < >> tonysietf@gmail.com> >> *Cc:* Tony Li <tony.li@tony.li>; lsr@ietf.org >> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS >> >> >> >> Hi Les, >> >> >> >> I know you don’t feel that the IGP should solve this problem but there >> was lots of interest in the three solutions to reduce the overhead when >> using IS-IS L1 as transit for IS- IS L2. Let’s not rehash that. >> >> >> >> What do feel needs to be done? Note that I’m on vacation and unlikely to >> engage again until next week… >> >> >> >> Thanks, >> Acee >> >> >> >> *From: *"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> >> *Date: *Thursday, December 9, 2021 at 2:05 PM >> *To: *Tony Przygienda <tonysietf@gmail.com> >> *Cc: *Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>, Acee >> Lindem <acee@cisco.com> >> *Subject: *RE: [Lsr] Using L1 for Transit Traffic in IS-IS >> >> >> >> Let me try to clarify my position… >> >> >> >> Two disjoint sets of authors looked at the same problem space and >> independently came up with two different (and incompatible) protocol >> extensions to provide a solution. >> >> >> >> (Aside: I believe fully that both sets of authors have done their best to >> define what they think is a good solution. If anything I have said suggests >> otherwise, that was not my intent and I apologize to both sets of authors >> for any misunderstanding.) >> >> >> >> Both solutions have been published as WG documents and assigned protocol >> codepoints. >> >> We are now being asked to publish both drafts as RFCs (I am assuming >> based on Tony Li’s response that the LC request for Area Proxy is soon to >> happen.) >> >> >> >> I don’t believe the WG has reached consensus that the IGPs should be >> extended to address the problem. >> >> I don’t believe the WG has reached consensus as to which solution is >> “better”. >> >> I don’t believe the WG has even discussed whether a single solution or >> multiple solutions are required. >> >> If multiple solutions are required, there has been no discussion as to >> when each of the solutions should be used. Are there some deployment >> scenarios where flood-reflection is a better fit and some where area proxy >> is a better fit? >> >> Is there a need for additional solutions i.e., deployments where neither >> of the current candidates are suitable? >> >> >> >> It seems to me that by entertaining a LC request at this point we are >> simply functioning as a pass through to allow multiple individual solutions >> to be published as RFCs. And while there are currently two solutions to the >> same problem space asking to progress, I think we can expect others and we >> have no basis on which to reject other proposals. >> >> >> >> This is very different from how any other work brought before the >> LSR/OSPF/IS-IS WGs has been done in the 20+ years during which I have been >> an active participant. >> >> In all other cases, the WG has strived to come up with a single >> interoperable solution. >> >> Sometimes only one solution is proposed and it is refined based on >> discussion and then progressed. >> >> Sometimes multiple solutions are proposed and there is discussion of both >> which results in choosing one over the other or some sort of merge of the >> solutions. >> >> But I do not recall a case where the WG simply allowed multiple >> non-interoperable solutions to the same problem to be published as RFCs >> largely w/o comment. >> >> >> >> I do not think this is an appropriate use of the Standards process and I >> do not think this serves the industry. >> >> This does not mean that either solution is w/o merit – but I do think the >> requests for Last Call are premature. >> >> But, this is just my opinion. >> >> If the WG (members, chairs, and ADs) think otherwise then the WG should >> act appropriately. >> >> >> >> Thanx for listening. >> >> >> >> Les >> >> >> >> >> >> *From:* Tony Przygienda <tonysietf@gmail.com> >> *Sent:* Wednesday, December 8, 2021 5:27 AM >> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com> >> *Cc:* Tony Li <tony.li@tony.li>; lsr@ietf.org; Acee Lindem (acee) < >> acee@cisco.com> >> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS >> >> >> >> Les, all sounds to me unfortunately like a gripe (and a late one @ that >> now that things were worked on in WG for years & are ready to RFC being >> customer deployed, @ least flood reflection is). >> >> >> >> Plus, unless you have a dramatically better idea than the drafts >> extended I fail to understand what your point is except as Tony1 says "we >> should not scale IGP higher?" (AFAIS hierarchy is not an answer here unless >> you ask customers for a flag day with lots new static configuration >> everywhere and possibly restructuring of their network to a hard-coded >> "hierarchy" and albeit such effort may work in some totalitarian countries >> on in pretty small networks, the majority of large ISIS customers will end >> such discussions in timeframe of single minutes clock count ;-) >> >> >> >> -- tony >> >> >> >> On Wed, Dec 8, 2021 at 4:23 AM Les Ginsberg (ginsberg) <ginsberg= >> 40cisco.com@dmarc.ietf.org> wrote: >> >> (Subject was: RE: [Lsr] WG Last Call for "IS-IS Flood Reflection" >> -draft-ietf-lsr-isis-flood-reflection-05) >> >> >> >> (Changing the subject as Acee has suggested that discussion of the >> problem space is inappropriate for the WG LC thread) >> >> >> >> Tony (and everyone) – >> >> >> >> This isn’t the first contentious issue the WG has considered. By way of >> comparison (hopefully a useful one), a number of folks (including you and >> I) are participating in another contentious issue – fast-flooding. >> >> But for fast-flooding there is broad WG consensus that fast-flooding is >> something that IS-IS should do. The contentious part is regarding what is >> the best way to do it. And we are proceeding in a manner where different >> algorithms are being tested while still in the WG document stage. And there >> is hope (still TBD) that multiple algorithms may be able to interoperate. >> >> >> >> Here, I am not convinced that there is broad WG consensus that this is a >> problem that the IGPs should solve. (If I am wrong on that I presume the WG >> members will let me know.) >> >> And, we have multiple proposals, none of which have any hope of >> interoperating with each other. >> >> And we have had very little discussion about the problem space. (not your >> fault – certainly you have been willing as have the authors of the >> competing draft) >> >> >> >> So, at best, I think WG LC is premature. I would like to see more >> discussion as to whether this is a problem that IGPs should solve as well >> as a general look at how this might be done with and/or without the IGPs. >> >> And since all of the proposed solutions have been allocated code points, >> they can continue to gain implementation/deployment experience in the >> meantime. Therefore, I do not see that we need to make this choice now. >> >> >> >> I realize that you are not the one asking for WG LC and I don’t know when >> you plan to do so and I am not trying to influence you in that regard. >> >> But for me, WG LC is at best premature. >> >> >> >> As regards you trying to solve a real world customer ask, I was aware of >> that. And I believe the authors of flood-reflection can make the same claim. >> >> >> >> Thanx for listening, >> >> >> >> Les >> >> >> >> >> >> >> >> >> >> *From:* Tony Li <tony1athome@gmail.com> *On Behalf Of *Tony Li >> *Sent:* Tuesday, December 7, 2021 2:53 PM >> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com> >> *Cc:* Acee Lindem (acee) <acee@cisco.com>; Acee Lindem (acee) < >> acee@cisco.com>; lsr@ietf.org >> *Subject:* Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" >> -draft-ietf-lsr-isis-flood-reflection-05 >> >> >> >> >> >> Les, >> >> >> >> And in response to Tony Li’s statement: “…the IETF is at its best when >> it is documenting de facto standards” >> >> >> >> 1) I fully believe that our customers understand their requirements(sic) >> better than we (vendors) do. But that does not mean that they understand >> what is the best solution better than we do. >> >> When a customer comes to me and says “Can you do this?” my first response >> is usually “Please fully describe your requirements independent of the >> solution.” >> >> >> >> >> >> If it matters at all, Area Proxy is the result of a customer explaining >> his issues and my attempt to address them. I’m sorry you don’t like my >> proposal. >> >> >> >> >> >> 2)Not clear to me that there is an existing “de facto standard” here – >> which is reinforced by the fact that we have so many different solutions >> proposed. >> >> >> >> >> >> There isn’t. Yet. Thus, it’s not time to pick one vs. the other. >> >> >> >> Tony >> >> >> >> >> >> _______________________________________________ >> 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 > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [Lsr] Using L1 for Transit Traffic in IS-IS Les Ginsberg (ginsberg)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Aijun Wang
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Li
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Les Ginsberg (ginsberg)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Przygienda
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Li
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Les Ginsberg (ginsberg)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Przygienda
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Acee Lindem (acee)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Acee Lindem (acee)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Les Ginsberg (ginsberg)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Muthu Arul Mozhi Perumal
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Gyan Mishra
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Les Ginsberg (ginsberg)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Gyan Mishra
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Robert Raszuk
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Przygienda
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Les Ginsberg (ginsberg)
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Robert Raszuk
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Gyan Mishra
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Przygienda
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Li
- Re: [Lsr] Using L1 for Transit Traffic in IS-IS Tony Przygienda