Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Alvaro Retana <aretana.ietf@gmail.com> Wed, 28 February 2024 12:55 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3279BC14F68C; Wed, 28 Feb 2024 04:55:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.862
X-Spam-Level:
X-Spam-Status: No, score=-4.862 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, 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_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 r9kXaHcn37NB; Wed, 28 Feb 2024 04:55:00 -0800 (PST)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 12E71C14F694; Wed, 28 Feb 2024 04:54:47 -0800 (PST)
Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-517ab9a4a13so4532424a12.1; Wed, 28 Feb 2024 04:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709124886; x=1709729686; darn=ietf.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=guBu9UZz46vpjkqk1MRPVK9amv8U5ORFLPTQCQqvRfE=; b=WcFy3YX0VMz/hT2M7tyI4dMc0F2Wpi/SXawNXMbCd0RGpr/eZ+O5xW5jmoH2X3QaN7 lX558+C94bg/4N19Z09BWaHGuEBiBzXWH7T82GdR487cnUXTttHO3IF3YxnnQ2nnXVh/ 48LPZO/dbLl7LEuDlswb6pYBQQepRek1unOWsiBNFT/l1AyKEzzcMKlcu5tjlCiiX29E zkULiUa7NLk2x5ivlKIrBehC98AsL3cBDuqypJdkRfwePzrCBxqJegl8VF1mOmkWRWbw jjIcEHmLSw7gJS3MsZOeSPEUuDaxV7iiRVzeMD8RTuaPBHLu1ZCZXMCWlP3mXLnNuBps tPkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709124886; x=1709729686; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=guBu9UZz46vpjkqk1MRPVK9amv8U5ORFLPTQCQqvRfE=; b=w6PS1eI+A6pjskGfYKA1ZsC2nQN0rUMvrXaCGo9VcgPGcc/81ynEiqPJNPWRECpWSc q9CxsIOLPBJ2cj/M7oMHtpyIyLbKU72eootVEJw+QDbT/zu6/CVfIXJFmCZC8hZkDedm Zes0gEYiw79S7+5dysI9BmN5Y6ur7CRC6X0QHzbIDf3p2wr67YZFy0QvNm8W667w0AsH KjNC0ZPAchjXJc99hE2RvmhDeK5PJ0MqYwDrQs7wuf8xz0VP7zexATjKIhI8xzU361Y0 JYpD4GplxmQWqvD8nVe0Xe3vReHhfrEruJpUxUdxtUHUQhFZ60NgGjIOcCpf7cV7YP/l kDyA==
X-Forwarded-Encrypted: i=1; AJvYcCX4mIBn6d+4rtwyiknagSAku1UWAW4x6PeZ+wa0eHMT0qgSxFC1Ioa2rO8HzInTrWAHMjsSdT5U5tCG2b19sHHxWWQoSCUB6rROJvR8FfDpTDkSVGOCBM7yLGuzqY4f9NVZA/8KSpOm8HU8W0TjAVoc3ESFwdA3UlXIQQt2bEXRmXiFr058ZqsQ4Ga7qXBjm1+Gg06qJ7cIMeHbn6WRRUC+us0gKAGteSlMhOg=
X-Gm-Message-State: AOJu0YwA2ifB0YASr3XiCMfSelNvz7V4pt0jXi/lGhbBIO9oIWK2PK4q 0rzC+EQKGIrVJ7QOtXmiSRLMXmzxUuM4qulOcNF+7z93+OrxzckeNwHQT82Qwtb8KtCtCgup978 wJ6tBYAlRYaWaPCWqPCz74Rp5bSS5hCVc
X-Google-Smtp-Source: AGHT+IGgLqYzOjqSOvOSUZPfPmNRdDWp/gtQsNvr9dE1wQmH+wLCju5cotGsVG5eq0DVxxdzuo55/TasqTQiKT8x424=
X-Received: by 2002:a05:6a21:3a83:b0:19e:67b0:9ac6 with SMTP id zv3-20020a056a213a8300b0019e67b09ac6mr6411122pzb.1.1709124886003; Wed, 28 Feb 2024 04:54:46 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Feb 2024 13:54:44 +0100
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CABY-gOPDLs6j+YPSYhbwnvvkfTi1VyPN8Vr6XWs9oy28cxr6Mw@mail.gmail.com>
References: <CABY-gOMQ=LaECWJsJHsdKX7i+BUsiX=LF5b5ZPMVp=3qQjZ8Mg@mail.gmail.com> <CAH6gdPyuWV=xvDerDCtXnD1T5CGymsm+b1i-idRGEs1w9aui=A@mail.gmail.com> <CABY-gOPDLs6j+YPSYhbwnvvkfTi1VyPN8Vr6XWs9oy28cxr6Mw@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 28 Feb 2024 13:54:44 +0100
Message-ID: <CAMMESswGR=7Lm_3tGOtVfb2YBvihAGARSwthRe6CP2=8Y3BEhQ@mail.gmail.com>
To: Yingzhen Qu <yingzhen.ietf@gmail.com>, spring-chairs@ietf.org, Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: RTGWG <rtgwg@ietf.org>, rtgwg-chairs <rtgwg-chairs@ietf.org>, draft-cheng-rtgwg-srv6-multihome-egress-protection <draft-cheng-rtgwg-srv6-multihome-egress-protection@ietf.org>, spring@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b5081d061270a5a2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/zJGE7xGFzBtWuTcvxVLYPzOXtrg>
Subject: Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Feb 2024 12:55:05 -0000
Hi! Now that the terminology is a little more precise, I also looked at the document and found a couple of cases where SIDs are skipped by SRv6 segment endpoints, which is what Ketan is really concerned about (?). These cases (see below) do not align with rfc8754 or rfc8986. IMO, any proposed deviation from the existing specifications should be discussed in spring (for rfc8986) or 6man (for rfc8754), and formal Updates to those RFCs may be needed. Thanks! Alvaro. (1) From §3.3 (Procedure on the Penultimate Endpoint): IF the primary outbound interface used to forward the packet failed or there is no FIB entry for forwarding the packet, the detailed processing to be performed by the penultimate node is as follows: IF SL = 1 THEN SL decreases by 1 and becomes 0; Update the IPv6 DA with Segment List[0]; FIB lookup on the updated DA; Forward the packet according to the matched entry; There seem to be two cases here: "the primary outbound interface used to forward the packet failed" and "there is no FIB entry for forwarding the packet". I assume (?) they are grouped because the result is that there is no FIB entry for the destination -- IOW, the link going down results in no alternate path available. rfc8754 covers this case: 4.3.4. FIB Entry Is a No Match Processing is not changed by this document. The result of a non-existent FIB entry is to drop the packet, not to forward it, as mentioned above. Changing that action requires an Update to rfc8754 (and others). As Bruno pointed out, questions related to "how does the node know" come up. (2) The operation described in this draft depends on P2 (Figure 3) taking on the role of the "Penultimate Endpoint". But the SRH used to illustrate is "< A1:1::1, A2:1::A100, A3:1::B100, A4:1::B100>", which results in P2 being in the Segment List[2] position. Also, PE3 also has penultimate endpoint functions in the draft. rfc8754 and rfc8986 have explicit definitions of what the penultimate segment endpoint is, and the use of P2 doesn't match any of them: rfc8754: Segment List[0..n]: 128-bit IPv6 addresses representing the nth segment in the Segment List. The Segment List is encoded starting from the last segment of the SR Policy. That is, the first element of the Segment List (Segment List[0]) contains the last segment of the SR Policy, the second element contains the penultimate segment of the SR Policy, and so on. rfc8986: A PSP-flavored SID is used by the SR source node when it needs to instruct the penultimate SR Segment Endpoint Node listed in the SRH to remove the SRH from the IPv6 header. ... A penultimate SR Segment Endpoint Node is one that, as part of the SID processing, copies the last SID from the SRH into the IPv6 Destination Address and decrements the Segments Left value from one to zero. The PSP operation only takes place at a penultimate SR Segment Endpoint Node and does not happen at any transit node. When a SID of PSP flavor is processed at a non-penultimate SR Segment Endpoint Node, the PSP behavior is not performed as described in the pseudocode below since Segments Left would not be zero. There are both terminology (using "penultimate" to describe any node other than the one at Segment List[1]) and operation changes that would be required in rfc8754 and rfc8986. (3) From §4: In normal operations...The specific operations of PE3 are as follows: 1) Remove the outer packet header and all its extension headers. 2) Look up the FIB table according to the destination address of the original packet. 3) Send the packet to CE2 according to the FIB entry. First, much more is needed to explain the operation (codifying with pseudocode as all the other SRH-related operations). The PSP flavor is specified in §4.16.1.2/rfc8986; it includes "S14. Update IPv6 DA with Segment List[Segments Left]" (not the "destination address of the original packet", as indicated above). Changing how the PSP flavor works in "normal operations" would require an Update of rfc8986. Note that this draft doesn't indicate how P2 would know the proposed process would have to be used (vs existing cases). On February 25, 2024 at 12:44:18 AM, Yingzhen Qu (yingzhen.ietf@gmail.com) wrote: Dear SPRING WG and chairs, I'd like to bring your attention to this adoption call happening in the RTGWG WG. The draft describes a SRv6 egress node protection mechanism in multi-home scenarios. As Ketan has commented in his email below the proposal requires a P router to process SRH with new endpoint behavior. We'd like to get your comments about the proposed extensions. Please send your reply to both the SPRING and RTGWG mailing lists. Thanks, Yingzhen On Wed, Feb 21, 2024 at 8:06 AM Ketan Talaulikar <ketant.ietf@gmail.com> wrote: > Hi Yingzhen/All, > > I have some concerns regarding the adoption of this document. > > > - Do we need these different solutions? > > KT> No. There is one common author for both these drafts who is also from > a vendor. I hope that person is also able to evaluate implementation > aspects and pick one solution. > KT> Does the adoption of this solution make the other draft "dead"? > > - Technical merits and drawbacks of each solution > > KT> The existing WG draft needs IGP protocol extensions and its > implementation is very complex (as stated in the document under adoption)=
- [spring] WG Adoption Call - draft-cheng-rtgwg-srv… Yingzhen Qu
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Mengxiao.Chen
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Lihao
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Feng Yang
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Yingzhen Qu
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Huzhibo
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… linchangwang
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… 王亚蓉
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… 王亚蓉
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Feng Yang
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Qiuyuanxiang
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… chen.ran
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… 高芳
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… allan michael
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Chongfeng Xie
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… 戴锦友
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Peng Liu
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… 梁艳荣
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Huaimo Chen
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Ketan Talaulikar
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Huzhibo
- [spring] Support : WG Adoption Call - draft-cheng… wangjj@centec.com
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Libin Liu
- [spring] Support: WG Adoption Call - draft-cheng-… wangjj@centecnetworks.com
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Gyan Mishra
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Wenying Jiang
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Yingzhen Qu
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… wangjj@centecnetworks.com
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Weiqiang Cheng
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… bruno.decraene
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Yingzhen Qu
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… bruno.decraene
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Weiqiang Cheng
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Alvaro Retana
- Re: [spring] [EXTERNAL] Re: WG Adoption Call - dr… Alexander Vainshtein
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Ketan Talaulikar
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Huzhibo
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Yingzhen Qu
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Lancheng Qin
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Weiqiang Cheng
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… bruno.decraene
- [spring] Support : WG Adoption Call - draft-cheng… wangjj@centec.com
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Alexander Vainshtein
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Weiqiang Cheng
- Re: [spring] WG Adoption Call - draft-cheng-rtgwg… Alvaro Retana