Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 28 February 2020 22:46 UTC

Return-Path: <brian.e.carpenter@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 F3EC43A1B84; Fri, 28 Feb 2020 14:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTAAvB5TdLsT; Fri, 28 Feb 2020 14:46:09 -0800 (PST)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 060343A1F25; Fri, 28 Feb 2020 14:46:09 -0800 (PST)
Received: by mail-pj1-x1033.google.com with SMTP id e9so1867994pjr.4; Fri, 28 Feb 2020 14:46:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MFGy5A5f14dVh8VcouH/ag+MJX4wL0bSA+QpQQSe5XI=; b=eq42FzZp7Kdreqja14mqiguSeIbGVCPrxrGi+sbbsw5lvMwqfNYzkY12+w3QuZ34GC emqAV/b0z9CtUyTwp+NBRku1S1+XtmlEnDZa9f0UKdpncp/DL1wHkckdxTd69z0Jibpb LBdNY+yhsjipeKQ83F8Nl0HEEajOaPVTmNSxbTa2zCPIxTcKdNuPqvEkZ+yQxz9t3YeN tpj4zSGXhbgfBpRUfdP4Q6oT2gGd2I8X569tFKK1zd0y9nwsTtn2wovHlrkk9fApqi3v eQ98VIU7uZuV+Cn+RWi92LKHtfnyDSO7MDtCbdFgE04t1LFMvVWxBkJ4JSIF/KoOUpDN TI1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MFGy5A5f14dVh8VcouH/ag+MJX4wL0bSA+QpQQSe5XI=; b=YkAY2XFwjsxugPo78xsBp3ecwR+4xFAiUkIjP0otVwKsXTOzr7CrjjmpXuxxXu0Lyd 37J4Hi1md3wxRgkXjBzsaUeLznXTIXdryozdxKZjvoQwP05u1m0yMWVCPIXduqM6FlHQ QCH4/CkO9SXDrAydwo+dEa8GxJQvWtlRztFEn+zHgSW+y5W8cWZoC66lURvajDFad7t+ /rB+4+OS/5533RNxZCScqz2l9lJPbNFFct0Q4f+RtnCzimvMynFVTnRk3lWZsCZ0Rgzr Ne2uSXIkV0JD+U5Xa6+1jCzYsvoFxitt3q0u1/jNYZzxL1hftg81HnwYaC1PNg0V7EE1 W1Gw==
X-Gm-Message-State: APjAAAWfM9l03iIks6hB9RyzZe+2UZ5PDSU39jyxi8twbgdumPxWAU6F 2LsT2rD2VHCsD7qhLsA51gdYTJwN
X-Google-Smtp-Source: APXvYqyI0I30SlGzl9fXxfgKq6PSTea4hMyChXsCFK9mQsTqscI3kQi3R/T4bJJhNjqAFWBF6BuAfw==
X-Received: by 2002:a17:90a:7307:: with SMTP id m7mr7079611pjk.75.1582929968159; Fri, 28 Feb 2020 14:46:08 -0800 (PST)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id q8sm11914708pfs.161.2020.02.28.14.46.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 14:46:07 -0800 (PST)
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>, Ted Lemon <mellon@fugue.com>, "Pablo Camarillo (pcamaril)" <pcamaril@cisco.com>, Bob Hinden <bob.hinden@gmail.com>, 神明達哉 <jinmei@wide.ad.jp>, "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
References: <965ff6bbf1cb4c2f8d48b7b535a0cf5b@huawei.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <2991422b-2de4-f89e-fd79-ada91dc9b3f4@gmail.com>
Date: Sat, 29 Feb 2020 11:46:03 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <965ff6bbf1cb4c2f8d48b7b535a0cf5b@huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9TiX3Jzry2tSSDcj3vBd7T19VLE>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
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: Fri, 28 Feb 2020 22:46:18 -0000

Hi Jingrong,

Thanks for your suggestion.

> so that the tunnel endpoint
> router (C) doesn't have to deal with SRH.  

Actually, why does this matter? RFC8200 already handles this case:

   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

If a non-SRV6 capable router receives SRV6 with segments-left == 0, it
must ignore it. (So why is PSP needed at all?)

Regards
   Brian

On 28-Feb-20 20:54, Xiejingrong (Jingrong) wrote:
> Hi
> 
>  
> 
> Thanks Ted for the constructive suggestions, which remind me to try to understand the questions. Here are the questions I think give the clear suggestions for LC.
> 
>  
> 
> Brian: So could the draft make this explicit, because I guarantee you it is not in the least obvious to the non-expert reader?
> 
>  
> 
> Jinmei: it should say it updates this part of RFC8200 and explain why it's justified.
> 
>  
> 
> Joel: it would seem that there ought to be a good reason for including PSP, rather than claiming that objectors need to motivate removing it.
> 
>  
> 
> Bob: There seems to be questions about its relationship with RFC8200.  I am not seeing this as being resolved.
> 
>  
> 
> As far as I understand the concern and the draft, I may have the following proposed text, though I don’t know if that will help to close or narrow the gap:
> 
>  
> 
> ****Proposed text to explicitly explain the PSP at the end of 4.16.1 of rev-10****
> 
>  
> 
> Note that, the SRH is used in an X-in-IP6 tunnel end point case, that is, router (A)
> 
> imposes an SRH, and a Penultimate Segment router (B) removes the SRH before
> 
> this packet goes to the tunnel end point router (C), so that the tunnel endpoint
> 
> router (C) doesn't have to deal with SRH. 
> 
>  
> 
> This has some very important benefits for deployment in some networks when the
> 
> final tunnel end point is a lower-end node which is not capable of processing
> 
> the SRH for reasons like the hardware is overloaded or unable to upgraded to
> 
> process well with SRH.
> 
>  
> 
> The use of SRH with AH by an SR source node, and processing at a SR Penultimate
> 
> segment endpoint node is not defined in <draft-ietf-6man-segment-routing-header>
> 
> or in this document.
> 
>  
> 
> The use of PSP does not impact the MTU Considerations defined in section 5.3 of
> 
> <draft-ietf-6man-segment-routing-header>.
> 
>  
> 
> The design of PSP for the benefits of deployment is based on the understanding
> 
> that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
> 
> modified in the future, the PSP may also need to change accordingly.
> 
>  
> 
> In case the final tunnel endpoint router is fully capable of the functionality
> 
> of SRH and the SRv6-NP defined in this document, it is recommended not to use
> 
> the PSP.
> 
>  
> 
> ***End****
> 
>  
> 
> Thanks
> 
> Jingrong
> 
>  
> 
>  
> 
> *From:*spring [mailto:spring-bounces@ietf.org] *On Behalf Of *Ted Lemon
> *Sent:* Friday, February 28, 2020 4:55 AM
> *To:* Pablo Camarillo (pcamaril) <pcamaril@cisco.com>
> *Cc:* spring@ietf.org; 6man@ietf.org
> *Subject:* Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
> 
>  
> 
> On Feb 27, 2020, at 3:38 PM, Pablo Camarillo (pcamaril) <pcamaril@cisco.com <mailto:pcamaril@cisco.com>> wrote:
> 
>     The discussion that we are having is about PSP which has nothing to do with that.
> 
>  
> 
> So, there is text in the document that addresses Brian’s question?
> 
>  
>