[Idr] Re: Last Call: <draft-ietf-idr-sr-policy-safi-09.txt> (Advertising Segment Routing Policies in BGP) to Proposed Standard

Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 07 November 2024 14:24 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 97452C14F6F3; Thu, 7 Nov 2024 06:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, 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_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 Azenso1SQwIC; Thu, 7 Nov 2024 06:24:30 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 D3AACC1840F7; Thu, 7 Nov 2024 06:24:30 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-20caccadbeeso11037385ad.2; Thu, 07 Nov 2024 06:24:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730989470; x=1731594270; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=59gVN71CoNd5enaLUn0aQepI5/Eu8tPMN7ooqV6+60g=; b=ngr2Us+uzEMVvwNULiJlCVJCnmZUwdWxg7qiM7n7xKes3CE7J3zoTZjUqvGxIlbIX0 NLhxeySj1iZTkzZZyiUkTg3XYVACUyhSqPvr9vbdz7zdZ1O85hdWOY3sSw7fTynngdhB ihPB8Teu5G72JST1lgghcLmcYPUVLabJrXmnUsJu17I6QdEupwSDDapWIwzAVbK7Mbr0 QumGUZZc4JKyc3M00J2KYbowy5WMe3nNkYzPs1i3M+yhqo8RaL66EgO0pCYEJNYcL1PK M6+I40NH5X7p+B0Qx025OAxO9ukymV22cLbvspYiZ2MhbZ+wTRiZg6qL9B19W/R81wNf 1eEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730989470; x=1731594270; h=content-transfer-encoding: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=59gVN71CoNd5enaLUn0aQepI5/Eu8tPMN7ooqV6+60g=; b=NLDwdIQ+Rb9zUvCi51S3uGwHeqARVgEiNRjTEJL1sgUOqCWoudxNr1GuNaUO6z1Xrs HduEb6zdNHBTuTMnBGLlInl7wt9YXASITKKK130Rq4GqODxr/Lgy/3A1GgNqkAc+6E3V 3CCx6svfeDMJMLAMQq0gSZL/pSBkjt2/+u2uqJCBQ/INd3UJBkFYXQBXe6KsBokOlcNB XaWlKMpMjZ0+L3KcIjHdZX4dFGQteAw1ciIx/7y58ZMLxuIgU6CQiJhJhaQiysiIOD5N L7NNPQqIbXC5Zq2WcnuWErqbmfd5wTxlKauceqRn8X9+Vh6ZOGWwZlsski1U0vrjNE4J tp2w==
X-Forwarded-Encrypted: i=1; AJvYcCWerxmOb1Ka4wKjUBaadBsI6CSMWUb8Zoio9i+dakMRVKF91uJ0e0l6PC1Eh56KY4XFQbayLDsD3nPZJyjs629odt7ZmnHrKSj/ECAQEA==@ietf.org, AJvYcCXddrPMbeNHf4UPB8GfOMM+T42PndG3qOe04bqYGBY1dpP1MUYg6NwBd6xpkId9w9lMP1Z/@ietf.org
X-Gm-Message-State: AOJu0YxhgXYG2BozcL4iA7Wh4EBmARpB1K6iKSVyUciOfqCLiGxAHjAo J2BXURdtFfJeSJzxiYJDdCjIjFY5w0gbGFwTHZhl7ShH6uUm7wzCCNxaXq2GGR+pyXDRxqJg2iN PwohfKcRvR1juYALKQfLKAVwmx8vOqZcPZruz/w==
X-Google-Smtp-Source: AGHT+IECgqxKRK525vsoL5eeqfY5H3SHIDfcaohO8pjmgDO2MdQlKoF7HNxIGEK8n8y8qxN4xcGgQOuhrJ43cwVGeDA=
X-Received: by 2002:a17:903:244f:b0:20c:aed1:813a with SMTP id d9443c01a7336-211811449b1mr1513125ad.14.1730989470151; Thu, 07 Nov 2024 06:24:30 -0800 (PST)
MIME-Version: 1.0
References: <CAGoOuead-JfLOJWzWfsmeszeybzuDmDCpW325KRS3zDsdFDKcw@mail.gmail.com> <CAH6gdPyUjJN2-6iBZ8jPp8AVD3uxFgCNnQ-OUZJF0S2yyaC-vQ@mail.gmail.com> <CAH6gdPwDNccMvQgQrR6u7hSdf+SE3BZrGex9DHh_fk6=7W21Eg@mail.gmail.com>
In-Reply-To: <CAH6gdPwDNccMvQgQrR6u7hSdf+SE3BZrGex9DHh_fk6=7W21Eg@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 07 Nov 2024 14:24:18 +0000
Message-ID: <CAH6gdPwqmLh_dtocjhM90HwRAb3hWn8Q=Vk-f3uevoXkzypqEQ@mail.gmail.com>
To: Rajesh MV <rajmv001@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: JVUEPO5LTRRL73AQDQYUZMWBPVQ33QSS
X-Message-ID-Hash: JVUEPO5LTRRL73AQDQYUZMWBPVQ33QSS
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: last-call@ietf.org, idr@ietf.org, draft-ietf-idr-sr-policy-safi@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: Last Call: <draft-ietf-idr-sr-policy-safi-09.txt> (Advertising Segment Routing Policies in BGP) to Proposed Standard
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mxM9dsglgo2MbcA2_pWNGrD5c9Q>
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 Rajesh/All,

We have posted an update with the changes as discussed:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-10

Thanks,
Ketan

On Sun, Nov 3, 2024 at 11:10 AM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
>
> Hi Rajesh/All,
>
> Please find attached the proposed diffs to clarify the point you have
> raised. It also includes the part that Russ had raised in his review
> of the draft-ietf-idr-bgp-sr-segtypes-ext document that covers some of
> the segment types.
>
> Do let us know if there are any follow-up questions or updates needed.
>
> Thanks,
> Ketan
>
> On Sat, Nov 2, 2024 at 6:32 AM Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
> >
> > Hi Rajesh,
> >
> > Thanks for your review and comments.
> >
> > It is necessary to encode the SRv6 SID value first for encoding the
> > optional SRv6 Endpoint Behavior and Structure. This is something that
> > was not clear in the text in the two drafts and was brought up by Russ
> > in his GenART review - please refer to [1]. Your query is related to
> > the same and we'll clarify the text about the use of value 0 in such
> > scenarios.
> >
> > I'll share the proposed text later today.
> >
> > Thanks,
> > Ketan
> >
> > [1] https://mailarchive.ietf.org/arch/msg/idr/eEh7C902VY4FqujW7ul7mRnumt4/
> >
> > On Sat, Nov 2, 2024 at 12:36 AM Rajesh MV <rajmv001@gmail.com> wrote:
> > >
> > > Hello authors,
> > >
> > >
> > > The encoding for the SRv6 BSID TLV requires the BSID to be present for signaling the Endpoint and Structure information. When a controller prefers not to specify the BSID (i.e., dynamic BSID allocation in the router) but still wants to indicate the desired behavior and structure, it can set the SRv6 BSID field to 0 with the S flag set to 0 and the B flag set to 1. Similarly, if the controller wants to specify flags (Eg: I-Flag) without providing a BSID, it can set the SRv6 BSID field to 0 and the S flag  to 0. Is this correct ? The draft does not seem to clarify this. This is also the case for the segment types in draft-ietf-idr-bgp-sr-segtypes-ext where the SRv6 SID is optional.
> > >
> > >
> > > Regards
> > >
> > > Rajesh
> > >
> > >
> > > ========================================================================================================
> > >
> > > The IESG has received a request from the Inter-Domain Routing WG (idr) to
> > > consider the following document: - 'Advertising Segment Routing Policies in
> > > BGP'
> > >   <draft-ietf-idr-sr-policy-safi-09.txt> as Proposed Standard
> > >
> > > The IESG plans to make a decision in the next few weeks, and solicits final
> > > comments on this action. Please send substantive comments to the
> > > last-call@ietf.org mailing lists by 2024-11-11. Exceptionally, comments may
> > > be sent to iesg@ietf.org instead. In either case, please retain the beginning
> > > of the Subject line to allow automated sorting.
> > >
> > > Abstract
> > >
> > >
> > >    A Segment Routing (SR) Policy is an ordered list of segments (i.e.,
> > >    instructions) that represent a source-routed policy.  An SR Policy
> > >    consists of one or more candidate paths, each consisting of one or
> > >    more segment lists.  A headend may be provisioned with candidate
> > >    paths for an SR Policy via several different mechanisms, e.g., CLI,
> > >    NETCONF, PCEP, or BGP.
> > >
> > >    This document specifies how BGP may be used to distribute SR Policy
> > >    candidate paths.  It introduces a BGP SAFI to advertise a candidate
> > >    path of a Segment Routing (SR) Policy and defines sub-TLVs for the
> > >    Tunnel Encapsulation Attribute for signaling information about these
> > >    candidate paths.
> > >
> > >    This documents updates RFC9012 with extensions to the Color Extended
> > >    Community to support additional steering modes over SR Policy.
> > >
> > >
> > >
> > >
> > > The file can be obtained via
> > > https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-safi/
> > >
> > >
> > > The following IPR Declarations may be related to this I-D:
> > >
> > >    https://datatracker.ietf.org/ipr/2984/
> > >    https://datatracker.ietf.org/ipr/5890/
> > >    https://datatracker.ietf.org/ipr/5891/
> > >
> > >
> > >
> > > The document contains these normative downward references.
> > > See RFC 3967 for additional information:
> > >     rfc4272: BGP Security Vulnerabilities Analysis (Informational - Internet Engineering Task Force (IETF) stream)
> > >     draft-ietf-idr-bgp-ls-sr-policy: Advertisement of Segment Routing Policies using BGP Link-State (None - Internet Engineering Task Force (IETF) stream)
> > >     draft-ietf-idr-bgp-sr-segtypes-ext: Segment Routing Segment Types Extensions for BGP SR Policy (None - Internet Engineering Task Force (IETF) stream)
> > >     rfc6952: Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide (Informational - Internet Engineering Task Force (IETF) stream)
> > >
> > >