IETF Logo Mail Archive

RE: WG adoption for draft-hu-rtgwg-srv6-egress-protection

Huzhibo <huzhibo@huawei.com> Fri, 21 February 2020 10:02 UTC

Return-Path: <huzhibo@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3821200C5; Fri, 21 Feb 2020 02:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1hauvQWLj59C; Fri, 21 Feb 2020 02:01:59 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0D3891200B6; Fri, 21 Feb 2020 02:01:59 -0800 (PST)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8C9F2EA38C4F59CCCC46; Fri, 21 Feb 2020 10:01:55 +0000 (GMT)
Received: from lhreml739-chm.china.huawei.com (10.201.108.189) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Feb 2020 10:01:55 +0000
Received: from lhreml739-chm.china.huawei.com (10.201.108.189) by lhreml739-chm.china.huawei.com (10.201.108.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 21 Feb 2020 10:01:55 +0000
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml739-chm.china.huawei.com (10.201.108.189) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Fri, 21 Feb 2020 10:01:54 +0000
Received: from DGGEMM509-MBX.china.huawei.com ([169.254.9.233]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0439.000; Fri, 21 Feb 2020 18:01:46 +0800
From: Huzhibo <huzhibo@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Jeff Tantsura <jefftant.ietf@gmail.com>
CC: Routing WG <rtgwg-chairs@ietf.org>, RTGWG <rtgwg@ietf.org>
Subject: RE: WG adoption for draft-hu-rtgwg-srv6-egress-protection
Thread-Topic: WG adoption for draft-hu-rtgwg-srv6-egress-protection
Thread-Index: AQHV6CBmonKX0k2jykemoF1LOKCuXagj9ysAgAFx4LA=
Date: Fri, 21 Feb 2020 10:01:46 +0000
Message-ID: <06CF729DA0D6854E8C1E5121AC3330DFAF550852@dggemm509-mbx.china.huawei.com>
References: <57a150fb-e91b-4581-9fc0-781e77c43e59@Spark> <c986b387-e6e8-46a7-8f4a-a3417de3776b@Spark> <CA+RyBmV4s=10NwQMMxW3ahNGh=SZcvKU17GmKHncAGqtuuy=RQ@mail.gmail.com>
In-Reply-To: <CA+RyBmV4s=10NwQMMxW3ahNGh=SZcvKU17GmKHncAGqtuuy=RQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.219.232]
Content-Type: multipart/alternative; boundary="_000_06CF729DA0D6854E8C1E5121AC3330DFAF550852dggemm509mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/J2fJ3PF-bIYIeRzeWG83QpqpAR4>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 10:02:02 -0000

Hi Greg:

    The behavior of PLR encapsulating Mirror Sid is the same as that of SRv6 Ti-LFA。draft-ietf-spring-srv6-network-programming section 5.1 has been mentioned that H.Encap is used to encapsulate the TiLFA Repair List, so this behavior will not modify the original SRH header.


Thanks

Zhibo Hu
From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, February 21, 2020 3:49 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Routing WG <rtgwg-chairs@ietf.org>; RTGWG <rtgwg@ietf.org>
Subject: Re: WG adoption for draft-hu-rtgwg-srv6-egress-protection

Dear Authors,
I have got a question about the switchover procedure in the scenario described in Section 3. As I understand, P1 monitors the path to PE3 using, for example, BFD. Once it detects the failure, P1 starts using the pre-computed and pre-signaled path towards PE4. In order to do that, P1 does, as described in the text:
P1 modifies the packet before sending it to PE4.
I've looked for what are these modifications and, as I understand it, think that it is an update to SRH, P1 appends the Mirror SID A4:1::3 to the segment list. Is that correct understanding? If it is, I'm not sure that it is a valid operation for P1? Have we heard from 6man experts about this?
I'd greatly appreciate your clarification on this as this mechanism, in my understanding of the document, is the foundation of the proposed solution and without it it may not be feasible.

Regards,
Greg

On Thu, Feb 20, 2020 at 11:02 AM Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>> wrote:
Dear RTGWG,

The authors have requested RTGWG to adopt draft-hu-rtgwg-srv6-egress-protection as the working group document.
The draft has received support during IETF106 meeting, authors have addressed all the comments received, I expect new version that addresses latest comments from Yimin to be uploaded within few days.

Please indicate support or no-support by April 5, 2020.

If you are listed as a document author or contributor please respond to this
email stating of whether or not you are aware of any relevant IPR.
The response needs to be sent to the RTGWG mailing list. The document will not
advance to the next stage until a response has been received from each
author and each individual that has contributed to the document.

Cheers,
Jeff & Chris
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg

v2.23.0 | Report a Bug | By Email