Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

Acee Lindem <acee.ietf@gmail.com> Thu, 31 August 2023 16:50 UTC

Return-Path: <acee.ietf@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 9866FC14CF15 for <lsr@ietfa.amsl.com>; Thu, 31 Aug 2023 09:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y2vRBkx3-7w for <lsr@ietfa.amsl.com>; Thu, 31 Aug 2023 09:50:05 -0700 (PDT)
Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA63BC14F74A for <lsr@ietf.org>; Thu, 31 Aug 2023 09:50:05 -0700 (PDT)
Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-1bba7717d3bso619563fac.1 for <lsr@ietf.org>; Thu, 31 Aug 2023 09:50:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693500605; x=1694105405; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=n736VZRGwct5IbX0wY+h3ZxWUvoXOz9tWMk9tdhUCk0=; b=Y8fgRN3l3rj76rQ3ldzWia92dEGpkuwp24NnqxbJuavNGBkuu7S1SfwSt9i3Fx9x07 b/yScnCAFEbb0bq0kkqjPaJ9B5YWEdL2O8tz0c3+2Yi/0KWGitb09CyjqFLAUrylfm4s 4embWz5AURrv1AviVq0gjDSdutI/dqROUe7Q0JnywOan/GYGeszXQZx5CAn+1A5zATpU 7xFk5x0hFNgO5PvBtQCXfPmQvaLGpSSVxirgNx/DtLtWZm3RoQ4w6MUZrVuQd6k7TA0E lBHJEau8o+XHsu7dgvz6zUIO/bUfkMBfnz4msj6cx3UQuGSWQp7wULgUYyZWM54xflaK y94w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693500605; x=1694105405; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n736VZRGwct5IbX0wY+h3ZxWUvoXOz9tWMk9tdhUCk0=; b=M6nKBAxcMA8KQE6FGVyrMO28z9uJUmpgmM4oA7i76EJf5T6+WETXdblEZhwT8KQCVk O7bo7Ws1MCjfWbN44t+sV+9OFXWS73r9NAoe7v2ACdbzaKtuYfUaZ1SU9ixE4R5neldH D1j5X5aE/3hSbtgJMyEI+Kg0GwNtwCCvqPSV/Srr+lLMemqzEv3s73ZeXNh16RKkFYoE uxQOVLfgSkDN5PAnH9R9YXlBEM3ryoND5CRlh1TMhFxUxDnMpeRWZ9bEoVV93t+hbfyX /NcXLNpsgibNWlfF+bbd8nvVUdn4CaIB+wfaM8PAj4NFGQK4vZcMRrsCOQc2fZbfpfJB Xf5w==
X-Gm-Message-State: AOJu0YzuGiq3ckASB8aizn/i1BmjkzaGh8NMLFe76RuxIxsUtZPtdOZe 21Bkhy1152I7hLcGlCnRhyM=
X-Google-Smtp-Source: AGHT+IFhR/27xAr1oumr68vVJpyv/ywtriWOemHHyEpmObvP7Hcpcq7YjswI9Qi5LNT3Im2VYktbxw==
X-Received: by 2002:a05:6870:231a:b0:1c8:c37d:5e69 with SMTP id w26-20020a056870231a00b001c8c37d5e69mr6676299oao.52.1693500604947; Thu, 31 Aug 2023 09:50:04 -0700 (PDT)
Received: from smtpclient.apple ([2605:a601:9199:bf00:4d17:45a6:d10e:6498]) by smtp.gmail.com with ESMTPSA id y2-20020a37e302000000b0076effd9809fsm728406qki.110.2023.08.31.09.50.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2023 09:50:04 -0700 (PDT)
From: Acee Lindem <acee.ietf@gmail.com>
Message-Id: <8B8E6CFA-6305-4845-8769-2E66E0352454@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_06EC3E99-0D0D-49A8-B11D-DE3AAF641FE7"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Thu, 31 Aug 2023 12:49:53 -0400
In-Reply-To: <CAOj+MMGtOg1LGJWPYq0ayEqL1F8KDafJMsiv3NtyvRkPb2MCig@mail.gmail.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, Huzhibo <huzhibo=40huawei.com@dmarc.ietf.org>, Peter Psenak <ppsenak@cisco.com>, linchangwang <linchangwang.04414@h3c.com>, lsr <lsr@ietf.org>
To: Robert Raszuk <robert@raszuk.net>
References: <887CE87A-D8AD-4C0F-B5B7-1942B43EB570@gmail.com> <b2a90475819f42218b573e306267cc32@h3c.com> <71ae7642-b0ff-b0e5-6ce7-bf758a1b8df7@cisco.com> <BY5PR11MB43371F45B95A471C8073A97BC1E6A@BY5PR11MB4337.namprd11.prod.outlook.com> <d0416daf3ccc4e6d8add3ce0ccf13269@huawei.com> <BY5PR11MB433793810A402EDA7A42AFA0C1E5A@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMGG8P4LRfwyLf+DyZfVsbOCMBtefFebJzd8VBMW_p4bzg@mail.gmail.com> <8E86D3C5-B6C2-47E9-A046-1A731E0223C3@gmail.com> <CAOj+MMGtOg1LGJWPYq0ayEqL1F8KDafJMsiv3NtyvRkPb2MCig@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LKRoNosJ8wuj_HW3wapEbYiTEO4>
Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 31 Aug 2023 16:50:07 -0000


> On Aug 31, 2023, at 12:32, Robert Raszuk <robert@raszuk.net> wrote:
> 
> Hi Acee,
> 
>> In any case, one will need to update the signaling routers and the routers acting on the signal.
> 
> I guess this is clear to all. 
> 
>> Additionally, your request for the adoption was that the draft have a stronger statement about the mechanism being used for solely for signaling for applications (e.g., BGP PIC).
> 
> As to the applicability my comment was that either draft should state in strong normative language that this is applicable only to applications which data plane uses encapsulation to the next hop. 
> 
> Said this draft-wang introduces the additional signalling, sort of trying to assure that all nodes in an area understand the new messages - but I am not sure if even advertising PUAM capability means that it will be actually used for all destinations ? 

No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral signal which the WG agreed was a valid use case, in the other draft, the LSAs are long-lived and are also may be used for other purposed than signaling (e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting with a whole different use case but selectively added mechanisms from ppsenak-lsr… 

I seem to recall you were a strong proponent of limiting the scope. 


> 
>> By responding to this Email inline, some may believe you support the assertion that we should start the adoption of both drafts. Please be clarify this.
> 
> Well the way I see this is that adoption call is a bit more formal opportunity for WG members to express their opinion on any document. But maybe LSR (for good reasons) have different internal rules to decide which document should be subject to WG adoption and does sort of pre-filtering. 
> 
> If adoption call proves document has negative comments or lacks cross vendor support it simply does not get adopted. 
> 
> Maybe I am just spoiled looking at how IDR WG process works :-) 

You replied to an Email inline suggesting adoption of both drafts. That is what I think could have been misconstrued - especially by those who didn’t follow the discussion until now who think you are agreeing with this recommendation.  


>  
>> As for your other comment that this could be accomplished with BGP or an out-of-bound mechanism, that is true but that could be true of many problem. However, the solution under adoption has running code and wide vendor support.
> 
>  Right ... As I wrote to Peter - perhaps this is just a pragmatic approach and flooding is what link state uses so be it. 
> 
> As you know I did try in the past to propose BGP Aggregate withdraw but then feedback of the community was that PEs do not go down that often to justify the extension. 

Hmm… We seem to have broad support for the LSR application signaling use case. 

Thanks,
Acee


> 
> Best,
> Robert
>