Re: [Idr] Contents of Idr digest draft-ietf-idr-sr-policy-safi-00
Ketan Talaulikar <ketant.ietf@gmail.com> Fri, 16 February 2024 06:49 UTC
Return-Path: <ketant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A82EC14F5E6 for <idr@ietfa.amsl.com>; Thu, 15 Feb 2024 22:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWU_IPbIZ6Hw for <idr@ietfa.amsl.com>; Thu, 15 Feb 2024 22:48:56 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 992E3C14F60F for <idr@ietf.org>; Thu, 15 Feb 2024 22:48:55 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-5118d65cf9cso2132713e87.0 for <idr@ietf.org>; Thu, 15 Feb 2024 22:48:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708066134; x=1708670934; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=11+NtTkK4+bmZgiip19azLajqthY7V995QsfBqvDtWE=; b=jCDoQD1XQ2ThvXQwtxt5OlWQXI9RjGlV2F3LXyynOGeBovifkp0+FO3mEMpST659nS Cgn2jqEQcQkzQPdhtEqSiotRmz2fkwsLJF+WK2Gq8voleSGkAR1JLeotCziXhEblyVb9 DW0TTiu1cpaB+v/IBJ/BdiNztswEmPrA1QjL99SbpmR8zMcMocJsTHVPzRyfBvSAtRD9 x+9lo8eljEVPgWo1YT66pnFHYpNckf7+YGAp5G6fA9mFB2XZPe7Id0As8lrwudlsmMVp PLqd0K7EIJRDBk9mknZGFf8Mfk9xonmWRARPlgDYbQBKv9cPOP5ksvZ1wsgvY8oSkqic vsWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708066134; x=1708670934; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=11+NtTkK4+bmZgiip19azLajqthY7V995QsfBqvDtWE=; b=bfq+gRhaPV+4i/+rqqBp64873zoKiBi74m0rSqc7+U0yrrC17zEroZsPPdZ1ORpiLl WrvHJf6wSZ1UY5AFiGCIhxtDHiTjzmVowE+v7Mj/XPlh4WqnhgZKuNwXsr/r9AMgiN4X LPUV+JRFgSlStBGL273t4LcrdeuA/61PhOFNQIKMnANKx9o0nIchgAdhiyPlcw9NJznY Q7405qtFJbAZhL22F/5sHteg7Um+TuDYYWWSqqoSnXBrmTsVT2qbqIf7neAKuuMaZgng 4W80KZuWpYgIXuIPp1jpJOY8dVWCxZkH7z/zuaKJHOLRUV7I1KciTdO8/6fenxG5/OIp 0pGQ==
X-Gm-Message-State: AOJu0YwA24JHzp2xSR12pweQ4I9k38AIrNzl1ZEA0uR9dYQFQ3mWQDzz ob/kFuIJ1/1kp9dmhMj2Ho4Z8Mxcg3+VsVJrwBj8hlE8TrXvtH+p6FM3ovKAAxW0CLNEeG+yo7g TN0tUUy0YJdQ9ZE9whiQRHyFBCSk=
X-Google-Smtp-Source: AGHT+IFJUHcQTjclcfiojpcFm9yOuSMn0md73TuTXZnb+9gAH82KCIRG4mygXJ1dhwpGrK5UEtknlk1IZG9NfFGEusI=
X-Received: by 2002:ac2:4890:0:b0:511:55fb:2405 with SMTP id x16-20020ac24890000000b0051155fb2405mr2743124lfc.50.1708066133347; Thu, 15 Feb 2024 22:48:53 -0800 (PST)
MIME-Version: 1.0
References: <mailman.38950.1708035190.4452.idr@ietf.org> <PH0PR05MB87355CD8035F14ADD414A5CCB54D2@PH0PR05MB8735.namprd05.prod.outlook.com> <CAH6gdPw6qURMA2h+Z35EeYwG=9=JcSBS1jjjf2gkE-he_d90Zg@mail.gmail.com> <PH0PR05MB873556ADBF8B1D154B538325B54C2@PH0PR05MB8735.namprd05.prod.outlook.com> <CAH6gdPzi__TB3K1AhNimeovMTmh8=hB42-KzWTv2AH2JfSAZRw@mail.gmail.com> <PH0PR05MB8735A8B664893D70C2585098B54C2@PH0PR05MB8735.namprd05.prod.outlook.com> <PH0PR05MB87353D9D7A4C677F012F99EAB54C2@PH0PR05MB8735.namprd05.prod.outlook.com>
In-Reply-To: <PH0PR05MB87353D9D7A4C677F012F99EAB54C2@PH0PR05MB8735.namprd05.prod.outlook.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Fri, 16 Feb 2024 12:18:40 +0530
Message-ID: <CAH6gdPyMLhJ3KrW5UaDoFpiDfQnLMfPmJDD1S9u3zM+VPfu6eA@mail.gmail.com>
To: Abhishek Chakraborty <cabhi@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.org>, "stefano@previdi.net" <stefano@previdi.net>, "cfilsfil@cisco.com" <cfilsfil@cisco.com>, "pamattes@microsoft.com" <pamattes@microsoft.com>, "dhanendra.ietf@gmail.com" <dhanendra.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000021936106117a2307"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/JuwAtfgViaktFtnUO96PBu7fNPI>
Subject: Re: [Idr] Contents of Idr digest draft-ietf-idr-sr-policy-safi-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2024 06:49:00 -0000
Hi Abhishek, Please check inline for responses. On Fri, Feb 16, 2024 at 12:09 PM Abhishek Chakraborty <cabhi@juniper.net> wrote: > Hi Ketan, > > The below statement: > > "The Binding SID sub-TLV is optional and it MUST NOT appear more than once > in the SR Policy encoding." > > There can be a scenario of an SR-MPLS policy have a MPLS Label Binding SID > and also an END.BM Binding SID. In that case there can be 2 BSID TLVs > right? > KT> Doesn't the same section 2.4.2 recommend use of the SRv6 Binding SID sub-TLV for such cases? And doesn't section 2.4.3 allow multiple SRv6 Binding SID sub-TLVs? Thanks, Ketan > > Best Regards, > Abhishek > > > Juniper Business Use Only > ------------------------------ > *From:* Abhishek Chakraborty <cabhi@juniper.net> > *Sent:* Thursday, February 15, 2024 21:00 > *To:* Ketan Talaulikar <ketant.ietf@gmail.com> > *Cc:* idr@ietf.org <idr@ietf.org>; stefano@previdi.net < > stefano@previdi.net>; cfilsfil@cisco.com <cfilsfil@cisco.com>; > pamattes@microsoft.com <pamattes@microsoft.com>; dhanendra.ietf@gmail.com > <dhanendra.ietf@gmail.com> > *Subject:* Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00 > > Hi Ketan, > > Yes, this is one more approach to skip a BSID TLV and expect the SRPM on > the router to allocate one BSID. The method is outside the scope of this > document. > But in this case there can be 2 behaviors from the controller: > > 1. The controller doesn't want a BSID and how does it indicate the > router to remove it in the next update. Since the control of this Candidate > Path is with the controller, do you think in this approach there should be > a way to remove the BSID? > 2. The controller wants to override the router allocated BSID with a > value it wants. Then the controller can send a BSID TLV with a value > different than the allocated value. Then the SRPM on the router can > override the value with controller's value. Now, here if we need to > fallback to the router allocated value again, does the controller send the > Next Update without BSID TLV? > > May be specifying these behaviors make it clear on BSID allocation. > > Best Regards, > Abhishek > ------------------------------ > *From:* Ketan Talaulikar <ketant.ietf@gmail.com> > *Sent:* Thursday, February 15, 2024 20:48 > *To:* Abhishek Chakraborty <cabhi@juniper.net> > *Cc:* idr@ietf.org <idr@ietf.org>; stefano@previdi.net < > stefano@previdi.net>; cfilsfil@cisco.com <cfilsfil@cisco.com>; > pamattes@microsoft.com <pamattes@microsoft.com>; dhanendra.ietf@gmail.com > <dhanendra.ietf@gmail.com> > *Subject:* Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00 > > *[External Email. Be cautious of content]* > > Hi Abhishek, > > The Binding SID sub-TLV is optional and can be skipped. This indicates > that the controller is not specifying a BSID and nor is it indicating a > behavior like "drop-upon-invalid". In this case, per RFC9256, the SRPM on > the router will do the BSID allocation. > > Do we really need any flag? If this was not evident, then perhaps we can > add text to section 2.4.2 to clarify this. > > Thanks, > Ketan > > > On Fri, Feb 16, 2024 at 9:40 AM Abhishek Chakraborty <cabhi@juniper.net> > wrote: > > Hi Ketan, > > The binding sid section can we modify with additional flag to request a > node to allocate a bsid? It can be a small section added. > > I see 2 approaches: > 1st approach: > Flag: > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |S|I| D | > +-+-+-+-+-+-+-+-+ > > Figure 5: Binding SID Flags > > The D flag with a BSID TLV with an empty BSID value indicates the router > to dynamically allocate a BSID. > > For flag approach update section 6.6. > > 2nd approach: > No need of new flag. An BSID TLV without any flag set and empty BSID value > indicates that the router allocates the BSID. > > The next update MUST come with the router allocated BSID learnt by > controller through various method outside the scope of this document. > If the controller sent the next update: > > 1. At any given point of time the controller wants to remove the > router allocated BSID, MUST send an update with no BSID TLV. > 2. At any given point of time the controller wants to change the > router allocated BSID, MUST send an update with a specified BSID. > > > > Best Regards, > Abhishek > > Get Outlook for Android > <https://urldefense.com/v3/__https://aka.ms/AAb9ysg__;!!NEt6yMaO-gk!GgJnf55kHDAOoUFb8ZLFk1Dm0ZUliZK7vt7uuSFL9VZ7RlMKCCXfoYp8l2WiMKsLXNhAMwqT5sxACW1jud0$> > > > Juniper Business Use Only > ------------------------------ > *From:* Ketan Talaulikar <ketant.ietf@gmail.com> > *Sent:* Thursday, February 15, 2024 7:47:30 PM > *To:* Abhishek Chakraborty <cabhi@juniper.net> > *Cc:* idr@ietf.org <idr@ietf.org>; stefano@previdi.net < > stefano@previdi.net>; cfilsfil@cisco.com <cfilsfil@cisco.com>; > pamattes@microsoft.com <pamattes@microsoft.com>; dhanendra.ietf@gmail.com > <dhanendra.ietf@gmail.com> > *Subject:* Re: Contents of Idr digest draft-ietf-idr-sr-policy-safi-00 > > *[External Email. Be cautious of content]* > > Hi Abhishek, > > Thanks for your review and your suggestions. > > Most of your comments seem of the nature of additions/augmentation to this > document to me. Would you agree? If so, I would rather that these > extensions be done via other/new documents (there are already many of them > out there with extensions for this SAFI). > > To give some context, this document started as an individual draft in Oct > 2015, became WG draft in Jul 2017 and underwent 26+1 versions during its WG > life of almost 6 years. I hope that the WG wants to "ship it" at this point > after fixing issues (if any) with the current content. > > That said, please check inline below for some pointers. > > > On Fri, Feb 16, 2024 at 4:36 AM Abhishek Chakraborty <cabhi@juniper.net> > wrote: > > > Hello Authors, > > Please find my comments on the draft draft-ietf-idr-sr-policy-safi-00: > > 1. > https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-00#section-2.4.4 > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-00*section-2.4.4__;Iw!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axe_pN-j0$> > > 1. A segment-list sub-tlv can carry its path-id or a segment-list id > that can be used in various use cases. One example is telemetry. I believe > the Yang Data Model of a segment-list also has a segment-list ID > associated. This ID can be reported via BGP-LS to the controller. > > KT> Please check > https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-seglist-id/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-seglist-id/__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axROHJu2M$> > > > > 1. To be in sync with PCEP multipath draft > https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-10 > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-10__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axNtd4IMQ$> can > we include the TLVs to advertise: > > 1. The backup Path for a segment-list sub tlv. This would help in > many use cases to steer the traffic to a backup path when the primary > segment-list is unreachable/down. The path ID or segment list ID > introduction will help distinguish and map a backup path to its primary > path. > 2. The reverse path or opposite direction PATH sub tlv which can > be used by SRPM. > 1. A new metric Sub TLV addition: > 1. A metric sub tlv to indicate on what metric the Candidate Path is > optimized or computed against. > 1. Use case: > 1. This metric can be advertised in BGP MED or can be used for > BGP best path selection. > > KT> Please check > https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-metric/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-metric/__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_axnsurlKI$> > > > Thanks, > Ketan > > > 1. Introduction of a new flag in > https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-26#name-binding-sid-sub-tlv > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-26*name-binding-sid-sub-tlv__;Iw!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_ax1D89LDw$> > : > 1. to indicate the node or router to allocate a Binding SID. In some > cases, the controller may want the node to allocate the Binding SID for the > Candidate Path depending on: > > 1. Already available Active Binding SID for that SR policy. > 1. Example: > 1. PCEP Candidate Path CP1 for Policy P1 requests Binding SID > as per draft > https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-16 > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pce-binding-label-sid-16__;!!NEt6yMaO-gk!F8b91Rwalo0GPEm6nQi7voD8yzDQxR9549mPA-ypUHqOuQB8p0cVkhakk3RqnRPQYulYWnlUn_ax17bWE5I$>. > A dynamic BSID is allocated say B1. > > 2. BGP-SRTE path requests the router to allocate a dynamic > Binding SID for CP2 of policy P1. Router allocates the same Binding SID B1. > This helps is fallback cases. > 2. The availability of Binding SID from a range that the > node or router knows. > > > Thanks, and Regards, > Abhishek > > > > 1. > > > > Juniper Business Use Only > ------------------------------ > *From:* Idr <idr-bounces@ietf.org> on behalf of idr-request@ietf.org < > idr-request@ietf.org> > *Sent:* Thursday, February 15, 2024 14:13 > *To:* idr@ietf.org <idr@ietf.org> > *Subject:* Idr Digest, Vol 238, Issue 9 > > [External Email. Be cautious of content] > > > Send Idr mailing list submissions to > idr@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK8fo4EyA$ > or, via email, send a message with subject or body 'help' to > idr-request@ietf.org > > You can reach the person managing the list at > idr-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Idr digest..." > > > Today's Topics: > > 1. WG LC on draft-ietf-idr-sr-policy-safi-00 and > draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024) > (Susan Hares) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 15 Feb 2024 22:12:55 +0000 > From: Susan Hares <shares@ndzh.com> > To: "idr@ietf.org" <idr@ietf.org> > Subject: [Idr] WG LC on draft-ietf-idr-sr-policy-safi-00 and > draft-ietf-idr-bgp-sr-segtypes-ext-02 (2/15/2024 to 2/29/2024) > Message-ID: > < > DM6PR08MB48572F86EA48D3FDB532EA21B34D2@DM6PR08MB4857.namprd08.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Greetings IDR: > > This begins a 2-week WG LC on the following two drafts created from the > text in > draft-ietf-idr-segment-routing-te-policy-18 - that the IDR WG approved for > publication: > > > * draft-ietf-idr-sr-policy-safi-00 (proposed standard) > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-safi/__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK0K-D6Q8$ > > * draft-ietf-idr-bgp-sr-segtypes-ext-02 (experimental) > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-sr-segtypes-ext/__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZKMrsVAu8$ > > The Authors (per IETF policy) are asked to respond to this message with a > message indicating whether they know of any undisclosed IPR as the > documents stand now. > Please note there are 3 IPR declarations on these drafts. > > History: > ====== > After reviewing draft-ietf-idr-segment-routing-te-policy-18, Andrew Alston > (IDR RTG AD) > asked that draft-ietf-idr-segment-routing-te-policy be split into two > parts because > some segment types (C-L) did not have two implementations. > Therefore, draft-ietf-idr-bgp-srsegtypes-ext-02 contains the text for > Segment types C-L. This split has been discussed at IETF meetings. > > Since Andrew Alston had personally implemented this draft, > he also asked for additional reviews on procedures. > > During this review, the procedures regarding the link to RFC9012 were > improved. > > Issues in call: > ============ > During the WG should note that the procedures specified in > draft-ietf-idr-sr-policy-safi-00 do the following: > > > 1. Only apply to the SR Policy Tunnel (15) + SR Policy SAFI > 2. Do not require any of the TLVs defined in RFC9012 for other tunnel > types > 3. May ignore TLVs defined in RFC9012 for other tunnel types > 4. Do not use the validation process in RFC9012, and depend on the SRPM > to validate content. > 5. Makes changes to Color Extended Community [RFC9012] to add to 2-bits > [C, O] > > To support "color-only" (CO) functions of section 8.8 of [RFC9256] > > > C0 - type 0 (00) - Specific end-point match (Match endpoint that is BGP NH) > type 1 (01) - Specific or null end-point match (BGP NH or null > (default gw)) > type 2 (10) - Specific, null, or any end-point match (BGP NH, > Null, or any endpoint) > type 3 (11) - Reserved > > The SR Policy Tunnel functions in this draft use BGP as a transport > mechanism for the > Information contained in the SR Policy. > > Please note that these procedures split the context validation away from > the > BGP module into the SRPM module. This split is similar to the BGP-LS > split > syntax validation from context validation. > > There are multiple implementations of this technology as detailed at: > > https://urldefense.com/v3/__https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZKoZPXAok$ > > The WG members are asked to confirm their agreement to the changes made in > this document. > > If there are questions, please ask them on this mail thread. Please note > any errors in the call are mine (and not the authors). > > Cheerily, Sue > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/idr/attachments/20240215/9c1e0641/attachment.htm__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK0bmhsvo$ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Idr mailing list > Idr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!A8KeEuSXmXw9FFOwEIQ5GoLbmfkZXHoQOPINOBhAJU3-QvyE17S9oiRA2no6iRHVxMAuB_jn_tZK8fo4EyA$ > > > ------------------------------ > > End of Idr Digest, Vol 238, Issue 9 > *********************************** > > >
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Abhishek Chakraborty
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Ketan Talaulikar
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Abhishek Chakraborty
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Abhishek Chakraborty
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Ketan Talaulikar
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Abhishek Chakraborty
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Abhishek Chakraborty
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Ketan Talaulikar
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Abhishek Chakraborty
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Ketan Talaulikar
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Abhishek Chakraborty
- Re: [Idr] Contents of Idr digest draft-ietf-idr-s… Ketan Talaulikar