[Idr] Re: AD Review of draft-ietf-idr-bgp-sr-segtypes-ext-04

Ketan Talaulikar <ketant.ietf@gmail.com> Tue, 01 October 2024 16:17 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 A794FC1840FC for <idr@ietfa.amsl.com>; Tue, 1 Oct 2024 09:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_BLOCKED=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, 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 yQrNGK-2_m5U for <idr@ietfa.amsl.com>; Tue, 1 Oct 2024 09:17:07 -0700 (PDT)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CC0C1840E0 for <idr@ietf.org>; Tue, 1 Oct 2024 09:17:07 -0700 (PDT)
Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-20b95359440so19177675ad.0 for <idr@ietf.org>; Tue, 01 Oct 2024 09:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727799426; x=1728404226; 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=ojY/QzTAPgjglvjcvvQk8LLnyAv/TsgYmAaDhnVt2LQ=; b=dR+Fuz+ucUYOv0Dg+XrIF/EhXgj2NkIoB4ggzR7jv46sP9GOk6XLEykcUvx3FiVZDI LtpWrJFS8P5cVqrAUSE3EWJ6vvfb2thz9SBQ0WC9At3ePlpMHzY9ceSytGz4p/+/m0fy xIStYQhhUgWdPx7vm4cWEbBvZEvHz5aWAgorcHRb8Wv0j32LIk0kiIOKmoI17zFcBav9 OGCMoQcWyuLvAMVxVOCUf2xV76rggOKeQgGHlXEfmW/nyqYqC2At4Mq0TFyY1XTn3HGS bLAhpSHcaYmQuLHQnIb29f/khezolTci4ObWQ0MfvSF7FQ7CHSVVzNIKb2Mr+6e+umiS TDaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727799426; x=1728404226; 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=ojY/QzTAPgjglvjcvvQk8LLnyAv/TsgYmAaDhnVt2LQ=; b=NFCjt6yiZuYoRmqjGdVQ4IuY5uiB4rZMj6aJPwGPj7TadRGurcejqRHO2m6g4qP5fA w8jdYpxB7+oZ8bae2kUfzR4q0fRlINRUkf1S7cWQzbrR+UOlA1RjCihMCCEW4IQRbEIj Py+Ev5YG3RrmUw+QtMrBWH2cEupq+jKqzpqULBKftp09S5gNRUrsXT8mSudJ5e8HL2aA 7A9+38fdW4PJDgZnrJWaXoLolIOVLCNWq1xfMDW8aPAaV6A+wkbTNOPlM65t4Ody4sv3 yw6RxpMfKz/DlQ1zHyaNy5jMVXm8YZJobJRiPJtGzVxC70qUhqR3lO3yyPrKrCArwSbv yAYg==
X-Forwarded-Encrypted: i=1; AJvYcCVzpYBX7g2SS8VfstrZ35hgoWFg/zRXYaBARk1jX0LuANzp/iHwRiSl9gQ1/hN8xo4prd8=@ietf.org
X-Gm-Message-State: AOJu0YzhUoFutMZdAMHYYHX5QJ7RTw6YqlQaAW/DraLzvBBj+2tZNtZv RJwOCK/GVHJUwQxvwdVDYWcItpP2/aW4uSjRPf/22VOpdXefN7grPli1hgXHt/ntzga+AG6EDRz d0iUN3/jWoy8GThp7q4SlV2t+V/0=
X-Google-Smtp-Source: AGHT+IH+ZlN2kbMgpWPiwvmTARAJOe6iXbz76DPk5T6/Lv5QLUTSdRze3bU7MscoUrn1/1nF5WazrekwZGCTlzXH0g8=
X-Received: by 2002:a17:902:e74c:b0:20b:8ef2:c84a with SMTP id d9443c01a7336-20bc5aa3709mr1902295ad.53.1727799426178; Tue, 01 Oct 2024 09:17:06 -0700 (PDT)
MIME-Version: 1.0
References: <BN2P110MB110713D5C9E4A4084BCB4770DC76A@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CAH6gdPyLzUzXkymzNd8di7NbYNV6Yg6ZHoB_kgdFW1V48b3Agg@mail.gmail.com> <CO1PR08MB661151F7C1299970E31C6748B3772@CO1PR08MB6611.namprd08.prod.outlook.com>
In-Reply-To: <CO1PR08MB661151F7C1299970E31C6748B3772@CO1PR08MB6611.namprd08.prod.outlook.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Tue, 01 Oct 2024 21:46:55 +0530
Message-ID: <CAH6gdPwkeMNaOcpXDq5Ut4-R2iME24YOotNT6BxF5qtPXqGPEg@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="0000000000000a663d06236ca79c"
Message-ID-Hash: FYCUNBZMINZCMHULBSTQP3VZEKO5TXAN
X-Message-ID-Hash: FYCUNBZMINZCMHULBSTQP3VZEKO5TXAN
X-MailFrom: ketant.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Roman Danyliw <rdd@cert.org>, "idr@ietf. org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: AD Review of draft-ietf-idr-bgp-sr-segtypes-ext-04
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/nAifwEjhxrTGAcm6L-H5uFglXkU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi Sue/Roman,

I've posted an update with change from "Standards Action" to "IETF Review"
- https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-08

There is one more open item (AFAIK) on this document which is adding text
about what the "experiment" is all about. From my view, there is really no
experiment and we are actually waiting for implementations. So, would the
following text to be added in the introduction section suffice?

This document is being published as experimental so as to gather
implementation experience for the extensions specified herein. The
expectation is that the document can progress as proposed standard once two
implementations have been completed.

If not, could you please suggest some alternatives?

Thanks,
Ketan


On Tue, Oct 1, 2024 at 7:10 PM Susan Hares <shares@ndzh.com> wrote:

> Roman and Ketan:
>
>
>
> I think that “IETF Consensus” is a good solution.
>
>
>
> Ketan – will you release new draft-ietf-idr-sr-policy-safi with the IETF
> Consensus?
>
>
>
> Thank you,
>
>
>
> Sue
>
>
>
> *From:* Ketan Talaulikar <ketant.ietf@gmail.com>
> *Sent:* Monday, September 30, 2024 9:46 PM
> *To:* Roman Danyliw <rdd@cert.org>
> *Cc:* Susan Hares <shares@ndzh.com>; John Scudder <jgs@juniper.net>;
> idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-sr-segtypes-ext-04
>
>
>
>
>
> Hi Roman,
>
>
>
> I think changing the registration policy to IETF Consensus for the new
> Segment List sub-tlv registry in BGP sounds like a good way forward. I
> missed that this was a new registry.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-07#section-6.5
>
>
>
> Sue, does that work?
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Tue, 1 Oct, 2024, 3:06 am Roman Danyliw, <rdd@cert.org> wrote:
>
> Hi!
>
>
>
> *From:* Susan Hares <shares@ndzh.com>
> *Sent:* Friday, September 27, 2024 10:53 AM
> *To:* Ketan Talaulikar <ketant.ietf@gmail.com>; Roman Danyliw <
> rdd@cert.org>; John Scudder <jgs@juniper.net>
> *Cc:* idr@ietf.org
> *Subject:* RE: [Idr] AD Review of draft-ietf-idr-bgp-sr-segtypes-ext-04
>
>
>
> *Warning:* External Sender - do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
>
> Roman:
>
>
>
> To resolve your comments, we need a firm decision on the issues raised in
> 3.1 and 3.2.
>
>
>
> Ketan as listed 3 options:
>
>
>
> (1) change this draft to standards track and let it get by without
> awaiting implementations - this is a special bypass of IDR WG policy given
> the history (I hope we don't need to merge the documents again!)
>
> (2) let it go forward as experimental but not sure if that works for the
> IESG and IANA from a process perspective
>
> (3) just let it sit and stew in the WG until we have implementations of
> *all* the segment types (or create smaller drafts as people implement bits
> and pieces)
>
>
>
> I really reject items (1) and (3).  I strongly prefer option (2).
>
>
>
> [Roman] (2) is not viable.  This would explicitly violate the registration
> policy.
>
>
>
> [Roman] Given the WG’s working practice on implementations, (1) doesn’t
> appear to be great choice.  I don’t have a sense of the motivations which
> preclude (3).
>
>
>
> [Roman]
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-06
> currently defines the registration policy to be “Standards Action” and this
> draft is still mutable.  Would the WG consider an “option (4)”, to change
> the registration policy to be either “IETF Consensus” (i.e., any IETF
> stream RFC be it PS, informational, BCP, experimental would be acceptable)
> or “RFC Required” (i.e., any RFC in any stream be it IETF, IRTF, ISE, etc
> would be acceptable)?
>
>
>
> Thinking outside the box…..
>
>
>
> If you feel the policy rule that we break in (2) is “unbreakable”, then
> can we change:
>
>
>
>    1. section 6.5 to include draft-ietf-idr-bgp-sr-segtypes-ext-04
>    section 3.1 with a pointer to draft-ietf-idr-bgp-sr-segtypes-ext.
>    2. section 6.6 to include draft-ietf-idr-bgp-sr-segtypes-ext-04
>    section 3.2 with a pointer to draft-ietf-idr-bgp-sr-segtypes-ext.
>
>
>
> [Roman] Could you restate this idea.  I don’t understand.  It seems
> self-referential to draft-ietf-idr-bgp-sr-segtypes-ext.
>
>
>
> Regards,
>
> Roman
>
>
>
> *From:* Ketan Talaulikar <ketant.ietf@gmail.com>
> *Sent:* Friday, September 27, 2024 10:01 AM
> *To:* Roman Danyliw <rdd@cert.org>
> *Cc:* idr@ietf.org; Susan Hares <shares@ndzh.com>
> *Subject:* Re: [Idr] AD Review of draft-ietf-idr-bgp-sr-segtypes-ext-04
>
>
>
>
>
> Hi Roman,
>
>
>
> Thanks for taking up the AD review for this document. I am responding on
> top of Sue's email so I can further clarify.
>
>
>
> We've also posted an updated version based on the discussions below:
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-sr-segtypes-ext-05
>
>
>
> Please check inline below for responses.
>
>
>
>
>
> On Mon, Sep 23, 2024 at 11:15 PM Susan Hares <shares@ndzh.com> wrote:
>
> Roman:
>
>
>
> Thank you for your prompt attention to this document.
>
> I’ve noted places where the author need to adjust their work.
>
>
>
> Please see my comments and questions below as the shepherd.
>
>
>
> May I talk about with John Scudder and you about the allocation issue.
>
>
>
> Cheerily, Sue
>
>
>
>
>
> -----------------------
>
>
>
> >Hi!
>
> >
>
> >I performed an AD review of draft-ietf-idr-bgp-sr-segtypes-ext-04.  To
> help load balance AD document queues, I am assuming the role of responsible
> AD.
>
>
>
> >Thanks for this document.  My feedback is below:
>
>
>
> ** Thank you to Sue Hares for the shepherd report which explained the
> history that led to this document --
> https://mailarchive.ietf.org/arch/msg/idr/VOjsIMFfle5jKy3ZGhf2iPYaqFE/.
> Given that this document
>
> is intended to be published with experimental status, could the text
> document the nature of the experiment?
>
>
>
> [Sue (Shepherd): Thank you for mentioning this point.
>
>
>
>       The nature of the experiment is that IDR awaits 2 implementations of
>
>       features prior to forwarding an IDR draft as Proposed standard.
>
>       The experiment ends when two implementations of the draft occur,
>
>       and the WG approves as PS.
>
>
>
>       Authors, this is a new request from our Reviewing AD.  Please
>
>       Add a paragraph in the introduction.
>
>
>
> KT > Sure, we can add some text of this nature once we've got a go-ahead
> on how to proceed further - see my response to your last comment.
>
>
>
>
>
>
>
> >** Section 2.8 and 2.9.  Figure 9 and 10.  Could the octet count for
> “SRv6 Endpoint Behavior and SID Structure (optional)” please be added.
>
>
>
> KT> Added
>
>
>
>
>
> Sue(Shepherd): good catch.  I can see some ambiguity in the text.
>
>
>
> Suggested text change:/
>
>
>
> Old Text:/*  SRv6 Endpoint Behavior and SID Structure: Optional, as
> defined in
>
>       [I-D.ietf-idr-sr-policy-safi] for Segment Type B./
>
>
>
> New Text:/*  SRv6 Endpoint Behavior and SID Structure: Optional, as
> defined in
>
>       [I-D.ietf-idr-sr-policy-safi] under Segment Type B in section
> 2.4.4.2.4?
>
>
>
> KT> Updated.
>
>
>
>
>
>
>
> The SRv6 Endpoint Behavior and SID Structure is a variable field defined
> in
>
> Section 2.4.4.2.4 in draft-ietf-idr-sr-policy-safi-06.  It is defined
> under the
>
> segment-list type B, but it is also used in segment types
>
> I, J, and K.  (sections 2.7 – 2.9, and figures 8, 9, and 10.)
>
>
>
> Do you also wish the authors to specify it as a “variable field” in the
> text?
>
>
>
> KT> It is a fixed size 8 octets field.
>
>
>
>
>
>
>
> >** Section 2.8
>
> >   The TLV 11 defined for the advertisement of Segment Type J in the
>
> >   early draft versions of [I-D.ietf-idr-sr-policy-safi] has been
>
> >   deprecated to avoid backward compatibility issues.
>
> >
>
> > As mentioned in my AD review of draft-ietf-idr-sr-policy-safi, consider
>
> > if this commentary on an older version of the draft is really necessary.
>
>
>
> Sue (Shepherd): I flagged this my reviews.  The authors felt it was
> necessary due to early deployments.
>
>     Perhaps they will have additional comments for you.
>
>
>
> KT> Same reasons as clarified in my response for
> draft-ietf-idr-sr-policy-safi. That said, we didn't receive any response to
> the poll for implementation of these TLVs - that doesn't guarantee that
> there are no implementations. Perhaps we could just leave it there but I am
> open to removing this text as well - please let me know.
>
>
>
>
>
> >** Section 3.1.
>
> >   This document requests the allocation of the following code points
>
> >   from the "SR Policy Segment List Sub-TLVs" registry under the "BGP
>
> >   Tunnel Encapsulation" registry group.
>
> >
>
> >The above registration request is not permitted.
>
> >Section 6.5 of [I-D.ietf-idr-sr-policy-safi] defines this registry as
> “Standards Action”.
>
> >Experimental status documents are not permitted to make registrations
> (only PS or BCP).
>
>
>
> >**Section 3.2 Same as above.  Per Section 6.8 of
> [I-D.ietf-idr-sr-policy-safi], the SR Policy Segment Flags" registration
> policy is Standards Action.
>
>
>
> KT> You have a valid point but please see further below.
>
>
>
>
>
>
>
> Sue (Shepherd): We talked to both Area Directors (John Scudder and Andrew
> Alston
>
> about this problem prior to forwarding this draft and
> draft-ietf-idr-sr-policy-safi for publicvatoin.
>
>
>
> We have two conflicting issues:
>
>    1. IDR requires 2 implementations for PS (unlike the rest of the IETF),
>    2. Andrew Alston (correctly) indicated the procedures were not
>
> as well document for the segments which had not be implemented.
>
>
>
> The Area Directors and IDR policy backed the authors into a “catch-22”.
> We are working on “early allocation”
>
> Registries or values with PS, but agreed not to penalize this set of
> authors.
>
>
>
> Now, as part of the “speed-up”, you have toss in a 3rd viewpoint.
>
>
>
> Can I talk with you and John Scudder about this point?
>
>
>
> KT> As editor of this document, I tried to argue against this split and it
> is something that I've had to do since I found myself in the rough. There
> weren't any vocal voices in the WG either for or against the split as well.
> So, as editor, I just went ahead with the split as directed.
>
>
>
> My argument against the split had been that the need for 2 implementations
> for standards track documents by IDR WG is about the feature/extension
> itself - the "big pieces". I do not remember it ever getting degenerated
> for implementation support for each and every TLV/sub-TLV specified. I also
> remember giving some examples of the same - [1] and its implementation
> report [2] - there were a few others that I don't have at the top of my
> mind right now. The base architecture spec from SPRING WG for this is in
> RFC9256. That document introduced these various segment types and we've
> tried to cover them all in both BGP (this document) as well as PCEP and
> other related documents like the YANG models. Note that these segment types
> have implementations - just not in signaling them via BGP SR Policy SAFI.
> That these segment types were not implemented *as yet* is more likely a
> case of prioritization by vendors (I can at least speak for one of them)
> depending on operators' requirements. For reference the implementation
> report is available here [3].
>
>
>
> Given this context, I see the following options:
>
> (1) change this draft to standards track and let it get by without
> awaiting implementations - this is a special bypass of IDR WG policy given
> the history (I hope we don't need to merge the documents again!)
>
> (2) let it go forward as experimental but not sure if that works for the
> IESG and IANA from a process perspective
>
> (3) just let it sit and stew in the WG until we have implementations of
> *all* the segment types (or create smaller drafts as people implement bits
> and pieces)
>
>
>
> I will leave the call to the IDR WG chairs and the responsible ADs. I am
> happy to take this document through the rest of the publication process as
> editor in either option (1) or (2). If not, then I am going to step down as
> the editor and have someone else from the WG take this specific document
> further.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> [1] https://datatracker.ietf.org/doc/rfc9012/
>
> [2]
> https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-tunnel-encaps
>
> [3]
> https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-segment-routing-te-policy-implement
> and
> https://wiki.ietf.org/group/idr/BGP-Implementation-report/draft-ietf-idr-bgp-sr-segtypes-ext-implement
>
>
>
>
>
>
>
> Cheerily, Sue Hares
>
>
>
>