Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-sr-policy-safi-00

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 04 March 2024 14:46 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313AEC14F6B2; Mon, 4 Mar 2024 06:46:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=juniper.net header.b="BD0pH1Uc"; dkim=pass (1024-bit key) header.d=juniper.net header.b="fCAK0QGQ"
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 4EI92SUl54C9; Mon, 4 Mar 2024 06:46:43 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76ECC14F5E8; Mon, 4 Mar 2024 06:46:42 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 424CUYQ8011385; Mon, 4 Mar 2024 06:46:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; s=PPS1017; bh=CqO8hyblba/gIyl9kbva60 X9gegWEKhKQZvTuK2f2rM=; b=BD0pH1Uc/d8SOBVknLlFaWSYKWTesFMHC0xoUy GZ82jiAn90AYktOoTbkT8I8V7zPQg8NG8E0+5TNm0tHiWIWMLhGPQdwKGtrAbT9+ Bva1LlkIQb01mlHA5uKoy+57wQWcVJhEpZLzhOAXwEG/Vku/k56c3PPcmodIFV8a IF7xHpk7L745MYDoCzUApsLor2Inoq/oFyeZ2LwgRRD3FOaDy22RVZZrmxBoXt1B nKB4uJMuueKNnvAkyqRgNjB1TvXhYk6WhiWVxzO2L8Ta4r3+EGUoddkXzQR4X9Kc 9Sj4wgh19YsldSCzgA0KzrL7bOCbdYqYxH5W90MxWnbSaTVA==
Received: from dm5pr21cu001.outbound.protection.outlook.com (mail-centralusazlp17014045.outbound.protection.outlook.com [40.93.13.45]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3wm07reqbu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Mar 2024 06:46:40 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mlj1ce7AR9mfHFH9qb+HU7hgdCbMrKUux6f2+igqJj8hQna2wU8a2zssM+j555j0+P7nzrV1MEOQ0hm/SUkv4InlzqMDD11jbIqiFXKoaz6EWyp6HUN0IUvlydluKkBsZfzmFfxuHSz7i5N+anbyfOGCc3v5S5TKjOzjFyDtYNDM7EabgE5x9biCI1syjiHhbb5x8dX6ReR/M63a2hwbcnQuvNGdTbTVjFFirxDQ9mH7y1n6zOGdwjBRsCpToAIVMs4V9bOcrRa1p1SeGQeYDWMeKDG6wdfcIkV+X0sMRHEklbVV47VKjCoNzPJ5/WSJ1RYJHpmCllygIufm4hsDvQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CqO8hyblba/gIyl9kbva60X9gegWEKhKQZvTuK2f2rM=; b=oOlaV2udJrpkBTKNWKKMYHoKTHYiIXhqSLbX8aDVlj/zUK7m96eEPYCk3/2fbc9Ov//cdjHCj74gGiUWcciFTaj/H2xBs4oLO9qhiYAR28nnyTALmRZCZ2j8El7H6b+FkqlMllyokB5s8FcVHMYGX2kki566kDz5m6q72pjpPqyoo5U+9ldMvIYfFxDbAhVXa02uyWZfIpvPsA/vUqkFvlhUCtJBM2tryhk8mpyk9IShaBOXIhc+y5NnkjlDTWIEUYEdod/os41St4/FtvyLFwCfTXnmvbNjp6D5h7zn8GzRPF7C5NdH/XMvPxARniFuznWHtj7W6lHZxNU/ZLr6Hg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CqO8hyblba/gIyl9kbva60X9gegWEKhKQZvTuK2f2rM=; b=fCAK0QGQOpwKp8NWMTyuklJCsal2/s2daCbAbqwsRFauXmn4YiVzSx5pjPzG1eUUy/9rPG88JdzPiRsWZGqHmXFMrD8hfs7+kDHVyHTA8dHv9dBaLvxMfiGfridi2zJf9LNVsly96UNmIHWiiDk4w4pV+ilvJfVjniAsGsXk5ck=
Received: from IA1PR05MB9550.namprd05.prod.outlook.com (2603:10b6:208:426::16) by SA1PR05MB9365.namprd05.prod.outlook.com (2603:10b6:806:255::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Mon, 4 Mar 2024 14:46:38 +0000
Received: from IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::4c5d:def9:3e54:e076]) by IA1PR05MB9550.namprd05.prod.outlook.com ([fe80::4c5d:def9:3e54:e076%4]) with mapi id 15.20.7339.035; Mon, 4 Mar 2024 14:46:37 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-idr-sr-policy-safi.all@ietf.org" <draft-ietf-idr-sr-policy-safi.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Rtgdir early review of draft-ietf-idr-sr-policy-safi-00
Thread-Index: AQHaa+K6OpEx98Tp70Cy9ei3edECH7EjA1eA
Date: Mon, 04 Mar 2024 14:46:37 +0000
Message-ID: <IA1PR05MB9550EE86ABE42D271774A620D4232@IA1PR05MB9550.namprd05.prod.outlook.com>
References: <170926285323.21559.2544259526462856240@ietfa.amsl.com> <CAH6gdPztdv-pXF1KyfJyYuWHX4ivpXG5UDDr1+H+oC3vBgmB+Q@mail.gmail.com>
In-Reply-To: <CAH6gdPztdv-pXF1KyfJyYuWHX4ivpXG5UDDr1+H+oC3vBgmB+Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=3e94a2c6-8f97-4cb5-8871-bc79f130c152; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2024-03-01T15:31:40Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: IA1PR05MB9550:EE_|SA1PR05MB9365:EE_
x-ms-office365-filtering-correlation-id: 09521d65-3fb4-4f57-191a-08dc3c59e533
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: IsiDigBOarwZ4wsobu0RrE+vMd46zQjY7df5DoGJPMyDm5VbF7AqyNOxyL0CN+fth8W0r9E7qB1nhcA+cePmYRM+no6oA3bbSF9sxUbp0qLi3iLuCZR2+xU44LF9vGk0xz59w3eP8PCKG4j8elaDTifCUp3bm2eRoc0IOmZFSoIlhyUz2KaTPIlw+mXZVysZhMHUTPbBpg9QjAIfmrA4+4eFr/tN7iFjd51oLMEjMO1voyw/OwSxi/P0k6BB8ORnBGfLvvvTIW+sNx0Pm2k7L/PpD2TssPkmvI1nrz+EHgX3BCqQjBUTKIcLn3fmjNQCh4odq3PxL/MNd7+RAiMNsnNJoGjhEtht3YafaGYKFwJxUfZ8Wiq3RixOqzVI8rzlH/c8Z5PBLhq6clfbYHJIqhAPbdykK0yxWEThT+QYbb5n2Otal3NIBSvrNm8AetqfU0rPri7TrgMaSZVEhJYcbW4jFhkE62eUmSoe/Llhe5S+HmrgyXxd5zPkd4l7hz5U4g7Qe0ayxhd4Bs6Q2NP3ddFS6G2QTgo75NrIZJAEIkrB4vSO4qO2YCfodciBofasgxp/QEmE6TCxg/V2xMyq4iw7Xd8EIz8c+85cLUxzmKO9DtFFtCBW6TpCD3xWco2EBz+Dx5IA72Vkp3u+8nw3W3yiRe+XIglvnoKK151mZ8Vfy70D/40ooZ924hBTpJ+BClWeLrH5kZIVIbkwyhtMsXJNqc97ZkXWpd3DyALyhDg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:IA1PR05MB9550.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376005)(38070700009); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: zrZGYcalv59D8ZYPh1PR/iiNhRX2QF60ROKxK7YiV2R7V3WZ7GxLhQFOGE2OXToJDLTTCTXXWXzylWaC6/rQ9rMNqQCBkFCV+5Yle9mOY9kI0zejUL83/F6XMYSE8rxE6NMj731T9GxKN2Cxj8fR8X//4rQJj4zWZcP5GaVyT3i0nSFx93NO8LFPMGDPVbrVTJbwY4f8LuSrSOmEyDHRmASohr78aOXE0JlkMn78aZvs8vl7d5z3Xb88gpZg50EcCgxKRPPL+edIhQgxCvvfnvP4vvus6Cws3yr11AWvL1cS8cVccYRFyMi2OqlkO1BZkChnJX5uADfYXbf87rrPm5+mmykcOefYB60frV7IwSM6/Zaa5b3MFKYGFrGLPRZB8UtNAA02p+WhbI6085Q/pAKtVmC9BFxmAiUnpQpfGO5igQY3DrK9SE6PnkiBQxxVpKT1rn4OLgCQiEhyghKzoSQvR7PJLJaZ+n/dTiuSmxmJd65AeAaBjzSjF5tFq9FPQHVlW/ArYVbpogVnq3Yn2DzMIR4y2UEGUXU1z4odYH8/5D4jOIrNM7z7izEAtXhFrIO53na2XlmVXMZvWi3dBKugH/fRgpE5Unl06CHepVzK0ba/sRioszU/E2OQU+NmlSgBafqFYkqiIwDyZdbbdP1msWrWJ3iQCQELMcgzPdyevC9fBzaMBWvKrelXHkpXIhNtKKx4EaD9cSxb8Gq8lGY1Zvw9qGDSUNVYzw+1YWWHMC/2i3hGGcj+T/boHlAQGUiS08ltBQWAi77oqmxWtfRQL3w8NgOplwALCoO3KiSIzDyCzFjy2rslZcU7ZQWXzQhQecqTVLaKls+8UjOEvBBGg6byixqpycibAdUWZa4Hewy6uAAeORza/YYIUFRYmMTr5axBre1/AYqWFbICuSZYvs7uEQtvG4fNNDfxD1K2/2S/kb9aaw9Fm7duO2fPiTB/RfPB2k3DUXFNvs0K4iHZcVuXcawCl/KvfO6QdELavQAB1c8bogVNu0s08g3qlTIqt3XLo/IzEfJw+SrPnbE/FrbElua8NKDj7bTaH2Q9ddHWUEeZyJA6IrEMdjZuP35GNmZ/Ac0iL5zPkYiJ6iRsD5ewRKYfpiyO4KfgpPbMjtmIFa/U1LbT1lalmhNAvVrn5SPIEZTagjACiMhYay25nfzRjW65iApE6PurbqzjmZORMPCGQPa0zvwy4uCVh6Tm0k0J48S60nOtvhmVl3uFE5/+7ulV7u3EhxQn4ZBmxqCN68TQpRb9qX9EN15F0yyOnSGNafTUwlimz5ebJGXE+YRDRlDh8oEaXFlymKTNF+7m1Xi934cNCYFdDHeaTUgT/mfKa+GqnzUp9+o0q69skfnmpL7WU+BB/84cAm5TWjOiSkD0khZ2FscwZs7FK4E6XlT5fbPV0WWNomuhK8+LvswMuOKnl89XwhKKuWEAdKxh2NqGyaoeofPJjD0P2BYPN2mbZvVubZQtrpFy2AMIT9tseQDBU4DzF4I/gyr6bDkmRgvL9qsiRKA6X6f9vV4pZKGbPg+zpIyOYjOp/R5PjRJs2bqrXSLWRh0ZfSrIUmfBabvkaxWBFPwbpQnp
Content-Type: multipart/alternative; boundary="_000_IA1PR05MB9550EE86ABE42D271774A620D4232IA1PR05MB9550namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: IA1PR05MB9550.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 09521d65-3fb4-4f57-191a-08dc3c59e533
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2024 14:46:37.4728 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aLVpV9KFAiXkieqfPqnpq1p8U2h4bv/vM5kuPxewxJa/SlqjkIOvzrga3JiaL4pD8rwRQRn9H5IeqL1Jr7zPtw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR05MB9365
X-Proofpoint-ORIG-GUID: fUfg466njclhc923pSz1wV8GNOZRCg1d
X-Proofpoint-GUID: fUfg466njclhc923pSz1wV8GNOZRCg1d
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-04_10,2024-03-04_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 clxscore=1011 priorityscore=1501 impostorscore=0 phishscore=0 spamscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 lowpriorityscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2402120000 definitions=main-2403040112
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/pzT0P9XId3qV3iCd-mgpZUvul7A>
Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-idr-sr-policy-safi-00
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2024 14:46:47 -0000

Hi Ketan,

I was finishing up this email before seeing your email about the posted version. I have not had a chance to go through the changes, but to get my questions to you quicker, let me send this (even though some may have been answered by the updated version).

Please see a few points below. I trimmed the text to focus on those.



   An SR Policy intended only for the receiver will, in most cases, not
   traverse any Route Reflector (RR, [RFC4456]).

Is the above paragraph correct/needed. I suppose in most cases
they will traverse RR after all - whether it is from a controller or
an egress PE.

KT> It is needed. RR is not required and not used in many deployments that I know of. It is a direct peering from controller to router.

Zzh> OK if you say the most BGP deployment is not through RR 😊

How is further propagation prevented after the headend is reached?

KT> This is covered in section 4.2.3

Zzh> I think a little more text is needed (more below).

   *  One or more IPv4 address format route target extended community
      ([RFC4360]) attached to the SR Policy advertisement and that
      indicates the intended headend of such an SR Policy advertisement.

and IPv6? s/format/specific/?

KT> Fixed. Use of IPv6 specific RT is not specified in this document.
Zzh> I see that it’s based on BGP Identifier which is 4-octet only so that’s reasonable.

   It is important to note that any BGP speaker receiving a BGP message
   with an SR Policy NLRI, will process it only if the NLRI is among the

There are a lot of "processing" before it is deemed "among the bet paths",
right? Do you mean the "SRPM" will process it only if the NLRI is among
the best paths?

KT> Yes and Yes.
Zzh> I see that the document intentionally distinguishes between BGP and SRPM. So the above distinction is necessary.


2.3.  Applicability of Tunnel Encapsulation Attribute Sub-TLVs

   The Tunnel Egress Endpoint and Color sub-TLVs, as defined in
   [RFC9012], may also be present in the SR Policy encodings.

Why do we say the above given the following paragraph? They seem to
be contractive.

KT> There is no contradiction. We don't want the attribute to be considered malformed due to the presence of those sub-TLVs.
Zzh> It seems that the above paragraph can be removed – the following paragraph alone is enough.

   The Tunnel Egress Endpoint and Color Sub-TLVs of the Tunnel
   Encapsulation Attribute are not used for SR Policy encodings and
   therefore their value is irrelevant in the context of the SR Policy
   SAFI NLRI.  If present, the Tunnel Egress Endpoint sub-TLV and the
   Color sub-TLV MUST be ignored by the BGP speaker and MAY be removed
   from the Tunnel Encapsulation Attribute during propagation.



   When the Binding SID sub-TLV is used to signal an SRv6 SID, the
   choice of its SRv6 Endpoint Behavior [RFC8986] to be instantiated is
   left to the headend node.  It is RECOMMENDED that the SRv6 Binding
   SID sub-TLV defined in Section 2.4.3, that enables the specification
   of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
   Binding SID for an SR Policy candidate path.

Is there a choice here? Shouldn't the behavior be that traffic with that
Binding SID is steered into this policy?

KT> What is meant by SRv6 Endpoint behavior is specified in RFC8986 - e.g., End.B6.Encaps, End.B6.Encaps.Red, and others could be defined in the future.

Zzh> Now I see that the first “Binding SID sub-TLV” in the above paragraph is not the “SRv6 Binding SID sub-TLV” but the one that can be used for both MPLS and SRv6 (I missed that). Then the paragraph makes sense.
Zzh> It helps if the paragraph moves down to after “If the length is 18 then the Binding SID contains a 16-octet SRv6 SID” and changes to the following:

… in this case, the
   choice of its SRv6 Endpoint Behavior to be instantiated, e.g., between
End.B6.Encaps, End.B6.Encaps.Red [RFC8986], is
   left to the headend node.  It is RECOMMENDED that the SRv6 Binding
   SID sub-TLV defined in Section 2.4.3, that enables the specification
   of the SRv6 Endpoint Behavior, be used for signaling of an SRv6
   Binding SID for an SR Policy candidate path.



   *  Binding SID: If the length is 2, then no Binding SID is present.
      If the length is 6 then the Binding SID is encoded in 4 octets
      using the format below.  Traffic Class (TC), S, and TTL (Total of
      12 bits) are RESERVED and MUST be set to zero and MUST be ignored.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Label                        | TC  |S|       TTL     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 6: Binding SID Label Encoding

      If the length is 18 then the Binding SID contains a 16-octet SRv6
      SID.




2.4.4.2.2.  Segment Type B

   The Type B Segment Sub-TLV encodes a single SRv6 SID.  The format is
   as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                       SRv6 SID (16 octets)                  //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //     SRv6 Endpoint Behavior and SID Structure (optional)     //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Flags: 1 octet of flags as defined in Section 2.4.4.2.3.

   *  SRv6 SID: 16 octets of IPv6 address.

   *  SRv6 Endpoint Behavior and SID Structure: Optional, as defined in
      Section 2.4.4.2.4.

When this is part of a segment list, what is the significance of the Flags and
SRv6 Endpoint Behavior and SID Structure?

KT> Please refer to sections 2.4.4.2.3 and 2.4.4.2.4 - will elaborate on your further comments on those sections.


   The TLV 2 defined for the advertisement of Segment Type B in the
   earlier versions of this document has been deprecated to avoid
   backward compatibility issues.

Why would deprecating them avoid backward compatibility issues?
If there are implementations/deployments based on earlier versions,
deprecating them won't help.
If there are no implementations/deployments based on earlier versions,
there is no backward compatibility issue.

Perhaps just remove "to avoid ..."?

KT> The WG was polled in this matter. While there were no implementations from "known" vendors represented at the IETF, we cannot rule out something being out there.

Zzh> I mean that “deprecating them” would not address the backward compatibility issue after all if there is implementation out there already based on the old version?


2.4.4.2.3.  Segment Flags

   The Segment Types sub-TLVs described above may contain the following
   flags in the "Flags" field defined in Section 6.8:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |V|   |B|       |
   +-+-+-+-+-+-+-+-+

   Figure 22: Segment Flags

   where:

      V-Flag: This flag, when set, is used by SRPM for "SID
      verification" as described in Section 5.1 of [RFC9256].

I have trouble understanding the V-Flag. How is the headend supposed to verify
the BSID or any segment in the segment list?

KT> Please refer to section 5.1 of the RFC9256.


2.4.5.  Explicit NULL Label Policy Sub-TLV

   To steer an unlabeled IP packet into an SR policy, it is necessary to
   create a label stack for that packet, and push one or more labels
   onto that stack.

Do you mean SR-mpls policy?
Perhaps remove ", and push one or more labels onto that stack"?
Perhaps changes "Explicit NULL Label Policy" to
"Explicit NULL Label Behavior"? The word "policy" here gets tangled
with "SR Policy".

KT> This is related to SR Policy with the SR-MPLS data plane.



When should the BGP update stops being propagated if RT is used?
Never? or should a matching RT be removed by each matching receiver
and then the propagation stops when there is no RT left?

KT> Yes, it can do that using local configuration. See the next paragraph.


   By default, a BGP node receiving an SR Policy NLRI SHOULD NOT remove
   route target extended community before propagation.  An
   implementation MAY provide support for configuration to filter and/or
   remove route target extended community before propagation.

Isn't the above applicable to any AFI/SAFI? Why do we need to specify that?

KT> It goes with the previous paragraph - hence required to clarify.

Zzh> I think it SHOULD remove the RT that matches its BGP identifier and stop propagating if there are no more RTs left, w/o relying on configuration.


5.  Error Handling and Fault Management

   A BGP Speaker MUST perform the following syntactic validation of the
   SR Policy NLRI to determine if it is malformed.  This includes the
   validation of the length of each NLRI and the total length of the
   MP_REACH_NLRI and MP_UNREACH_NLRI attributes.  It also includes the
   validation of the consistency of the NLRI length with the AFI and the
   endpoint address as specified in Section 2.1.

   When the error determined allows for the router to skip the malformed
   NLRI(s) and continue the processing of the rest of the update
   message, then it MUST handle such malformed NLRIs as 'Treat-as-
   withdraw'.  In other cases, where the error in the NLRI encoding
   results in the inability to process the BGP update message (e.g.
   length related encoding errors), then the router SHOULD handle such
   malformed NLRIs as 'AFI/SAFI disable' when other AFI/SAFI besides SR
   Policy are being advertised over the same session.  Alternately, the
   router MUST perform 'session reset' when the session is only being
   used for SR Policy or when it 'AFI/SAFI disable' action is not
   possible.

Is the above generic BGP handling?

KT> Yes, per RFC7606 this needs to be defined for new SAFIs.


   The validation of the TLVs/sub-TLVs introduced in this document and
   defined in their respective sub-sections of Section 2.4 MUST be
   performed to determine if they are malformed or invalid.  The
   validation of the Tunnel Encapsulation Attribute itself and the other
   TLVs/sub-TLVs specified in Section 13 of [RFC9012] MUST be done as
   described in that document.  In case of any error detected, either at
   the attribute or its TLV/sub-TLV level, the "treat-as-withdraw"
   strategy MUST be applied.  This is because an SR Policy update
   without a valid Tunnel Encapsulation Attribute (comprising of all
   valid TLVs/sub-TLVs) is not usable.

The above says the validation of those in Section 2.4 may lead to
"treat-as-withdraw" - I assume this is BGP handling. Does that not
conflict with the following paragraph?

KT> No, it does not. There is a line between what validation is done by BGP and what is done by SRPM.
Zzh> My understanding is that “treat-as-withdraw” is BGP handling (BGP tells SRPM the route is withdrawn) – that’s why I thought that there was a conflict.
Zzh> Are you saying that it is ok for BGP not to treat it as withdrawal but for SRPM to treat it as withdrawal (due to the validation in Section 2.4)?
Zzh> Thanks.
Zzh> Jeffrey


   The validation of the individual fields of the TLVs/sub-TLVs defined
   in Section 2.4 are beyond the scope of BGP as they are handled by the
   SRPM as described in the individual TLV/sub-TLV sub-sections.  A BGP
   implementation MUST NOT perform semantic verification of such fields
   nor consider the SR Policy update to be invalid or not usable based
   on such validation.




Juniper Business Use Only