IETF Logo Mail Archive

Re: [spring] Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200

Stewart Bryant <stewart.bryant@gmail.com> Tue, 27 July 2021 14:32 UTC

Return-Path: <stewart.bryant@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 E3CB63A003D; Tue, 27 Jul 2021 07:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.738
X-Spam-Level: **
X-Spam-Status: No, score=2.738 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_SBL_CSS=3.335, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFS7uQ2UtT8q; Tue, 27 Jul 2021 07:32:36 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F273A003C; Tue, 27 Jul 2021 07:32:36 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id p5so10357112wro.7; Tue, 27 Jul 2021 07:32:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fty6WHKHuOV0tMQFqS02HUp+f9w5SAynVWPLVnL+R9k=; b=iz8K1nP+9ogDx6ad9VNKP9g6jWfJVTt2E8CqIOzdLWfbvH6mMY8FuYsfYUws4060sd Lx26izXRmlooeU7sigtPSS5ynAtOhTZXX+RNRlTftYDwnzMYtmSYV4UbF16u+ZGDMdDL ca2yh4vE1dWw0WH2rFxrUgG8OPbavfAypBLevVN9+rDNQDEvBOX54x7o2P3ID/qPbciy qCvWaycJPMh8Qh/nZ+HWBlRAWVKziZNuU0ixpYd7QSlwp8F1K1atgDlcyiy1aMe00kl6 MKahDfXMo9MLYPLWjc40Xpk/AsOelooI5uGA+3GF3qO7IBWLnHfBSnkl3vVog7ouXk8Y U7Cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fty6WHKHuOV0tMQFqS02HUp+f9w5SAynVWPLVnL+R9k=; b=iEm+M0JQHzvOu5SzgaUvVsMmPA52q6m/BEsSBKV/hFUNqxDCY8TlZOpDPHjqqRlTDn lqJQurf7xHm0Keq1MCsSxbua2Q9f045WnQOPKDUJ5Kw9LrW+3Wa+ZVhSYIfptHV8eOEY o6FSs1mSqVdelvyL7j5CbCYS3DqiLYzZrpMrL2szbJMuHYGVAv0/QGDu2IQ8UYlD4hvc rHDNjzUqppYHpOJXW6XsC1UaK+EBUOZ4rZnBjCWHfbHXbonqcZVpomUPyOEk8m3ePOo6 WWYAa3TjryM4QeBdO9r3hhePF3kj5WU75dLzIhVN6TU+mps3nGPcqI6tYM6O1Eq+O/a7 BPtA==
X-Gm-Message-State: AOAM532TMpTiUb3dkTB7ScI6y3bdkncm1wnjpD12cGTBY325JRU2q7ZS 9th2N0M5ExP6YyRjpmldhYg=
X-Google-Smtp-Source: ABdhPJzZMZRlBH/J4oHCVwLKb0ZbCq1k9O8fPJoR0o1H13/8qwYYKMrUv3YUBnauFa0zWinmvvtOfw==
X-Received: by 2002:a5d:61c8:: with SMTP id q8mr13620240wrv.151.1627396353166; Tue, 27 Jul 2021 07:32:33 -0700 (PDT)
Received: from [192.168.8.103] ([185.69.145.253]) by smtp.gmail.com with ESMTPSA id l2sm1756697wru.67.2021.07.27.07.32.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jul 2021 07:32:32 -0700 (PDT)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <08028B48-6CDB-44B7-9C36-023B6F782193@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AD29183-F64D-444C-B1A9-B8613CFF4FB5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Tue, 27 Jul 2021 15:32:30 +0100
In-Reply-To: <2144efbd2c2c4559bfbc1f6e670dbc45@huawei.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "6man@ietf.org" <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
References: <2144efbd2c2c4559bfbc1f6e670dbc45@huawei.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/k4ZdviJlfIhJsEf8iuUOmclJGIs>
Subject: Re: [spring] Discussion about SRv6 Midpoint Protection Mechanism Compliance with RFC8200
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 27 Jul 2021 14:32:41 -0000

Presumably the path is N1->N2->N3->N4 with N3 being node protected

3.  SRv6 Midpoint Protection Example

   The topology in Figure 1 illustrates an example of network topology
   with SRv6 enabled on each node.

Chen, et al.            Expires January 13, 2022                [Page 3]
Internet-Draft          SRv6 Midpoint Protection               July 2021

                         +-----+           +-----+
                         |  N5 |-----------|  N6 |--------------+
                         +-----+           +-----+              |
                            |                 |                 |
                            |                 |                 |
                            |                 |                 |
       +-----+           +-----+           +-----+           +-----+
       |  N1 |-----------|  N2 |-----------|  N3 |-----------|  N4 |
       +-----+           +-----+           +-----+           +-----+

          Figure 1: An example of network for midpoint protection

I do not understand why the problem is not simply solved by having N6 host the N3 SID but advertise it at very high cost.

The packet will never transit N6 pre-failure because N6 is not a SID in the SID list and it will be to expensive to go to N3 SID via N6.

When N2 detects that N3 has failed it will look for an alternate path and TI-LFA will send the packet to N6 which will see the N3 SID and process it sending the packet to N4.

I must be missing something here, because this looks like a simple fix with no protocol change.

What am I missing?

- Stewart


> On 27 Jul 2021, at 13:34, Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com> wrote:
> 
> Hi 6man,
>  
> We have proposed an SRv6 local repair mechanism to provide endpoint protection. The document could be found in:
> https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/ <https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/>
> The basic idea is quite straight forward: when the node finds that the neighbor, which the packet is supposed to be forwarded to, is an endpoint and it has failed, the node will do the proxy forwarding, including: SL--, replace the DA with the segment of the next endpoint, and forward the packet based on the DA.
> Considering that the repair node which does the proxy forwarding could be a transit node, it is discussed in SPRING WG whether it violates RFC 8200; if it does, whether this behavior is allowed to provide local protection for endpoint.
> We would like to hear the voice from 6man about this topic. Looking forward to your comments.
>  
> Best
> Xuesong
>  
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org <mailto:ipv6@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email