Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 11 March 2020 21:30 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 D09413A0D66; Wed, 11 Mar 2020 14:30:21 -0700 (PDT)
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=unavailable 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 KeYtnlNvn6ub; Wed, 11 Mar 2020 14:30:20 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 179953A0D6A; Wed, 11 Mar 2020 14:30:09 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id mj6so1450892pjb.5; Wed, 11 Mar 2020 14:30:09 -0700 (PDT)
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=aiuoDtQZI8N5djZih3I2E2WLXcXX/94EZ4MuqVL9qGA=; b=svzGQxLctUMPyOWGyU7wTjSPLv9/m1/yNa/8trbCIYQeTdnymi66wC6NpMWCAM5o9X 6UxQw1a14zxLd4xvdngoMaV8qtrPmb8402hiV01NQbZ7H27oDbjXWFkWDqpZIXG1stdi VBHnlpm0J8g7mGRB4vzcmsUQcEyDh9uwly9y1wzVDPi0buYEVe9KXKs+YEWFUayXKYQI KNNxRYbgKTdGtPjkEd459bx25pd3jk93ZzZNr6VpsqZ52usAMEt7RBiT2+Q7XaK8tDUN 67YxM9f5S6YOC2KZvFr+yLCzdl6cap2+K8Sj1dIvvLvNab+DRPUMNCDek3eTpoAUxoc/ U3sg==
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=aiuoDtQZI8N5djZih3I2E2WLXcXX/94EZ4MuqVL9qGA=; b=W24xyVa6K+3LpA5whH6EGvNGnrRBinyXKjlHlNbjdXQO2TTiJt6cCCa7RynBW/83Cf tyVOUa47FuMD69cfhz6JaCMMppGYXyuXSKjx0KGglqXY9VgEqhE5/qtc4crwwwEXNhEI KV5+1envhV414uN+0QDZLp7t6OWtKr33sXPSh6C6t2ljRDbgixou4O31Ly7v1my1RiFy f0oC4iloT0NinZSz9/DZ6KimvZFOSuK8p5qKSnnJWeCCSEiloN8QCS1KROs7B9H8seZ9 KOJEteDITIm/1dPkpy4nrVI76A/Meqhlm3djPuy5S+7Lru/wIJCzgh02hhoM33ks7hWj Eo+g==
X-Gm-Message-State: ANhLgQ0euraGQlqQXXOAZMlGxRnXXtI+ovwFwcRBKacnmqpqvsZ+eFUd FFGOdp7kMObAjq1/tXbCeOPffXVn
X-Google-Smtp-Source: ADFU+vujTor7SeYyMQCX5AAaxLTZxTdkrQrKbFtVGmGm+MWCcddKuVUrdPSUkVnKdoiyyf1+8BEthw==
X-Received: by 2002:a17:902:528:: with SMTP id 37mr5015210plf.322.1583962208608; Wed, 11 Mar 2020 14:30:08 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.25.143]) by smtp.gmail.com with ESMTPSA id w31sm25459002pgl.84.2020.03.11.14.30.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Mar 2020 14:30:08 -0700 (PDT)
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>, "Darren Dukes (ddukes)" <ddukes@cisco.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: "spring@ietf.org" <spring@ietf.org>, 6man WG <ipv6@ietf.org>
References: <4F4FF5EC-690F-4C09-9101-98AB2DDFDE0C@liquidtelecom.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <a38c3197-2513-4af6-cb4f-a0a96c082cb9@gmail.com>
Date: Thu, 12 Mar 2020 10:30: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: <4F4FF5EC-690F-4C09-9101-98AB2DDFDE0C@liquidtelecom.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/eg7nrNe4EOoy9GvbBTSgiooXCPQ>
Subject: Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
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: Wed, 11 Mar 2020 21:30:22 -0000

On 12-Mar-20 09:53, Andrew Alston wrote:
> Hi Spring WG
> 
>  
> 
> On the basis of the below – I must conclude that the issues relating the SID/IPv6 semantics have indeed not been dealt with by the spring working group in the context of the network programming draft – and I would now like to raise those issues in the context of that draft – and the fact that draft-ietf-spring-network-programming violates the address semantic specifications of RFC4291.

I really think that this is subsidiary to RFC 8402 (a Proposed Standard):

   SR can be applied to the IPv6 architecture with a new type of routing
   header called the SR Header (SRH) [IPv6-SRH].  An instruction is
   associated with a segment and encoded as an IPv6 address.  An SRv6
   segment is also called an SRv6 SID.  An SR Policy is instantiated as
   an ordered list of SRv6 SIDs in the routing header.

I don't see anything in the SRH draft or the network-programming draft
that is not within that definition. Whether RFC 8402 contravenes RFC 4291
is worth discussing, I guess. The latter says:

   IPv6 addresses of all types are assigned to interfaces, not nodes.
   An IPv6 unicast address refers to a single interface.  Since each
   interface belongs to a single node, any of that node's interfaces'
   unicast addresses may be used as an identifier for the node.

However, I can't find anything in RFC 4291 that forbids addresses
having semantic meanings rather than being pure locators. It goes
against one of my design prejudices, but I can't find anything
resembling "Encoding semantics in address bits considered harmful"
in the RFCs.

In reality, there are lots of operational practices that amount to
giving semantic meanings to address bits.

   Brian

> 
>  
> 
> Can we please have a proper discussion on this
> 
>  
> 
> Thanks
> 
>  
> 
> Andrew
> 
>  
> 
>  
> 
> *From: *"Darren Dukes (ddukes)" <ddukes@cisco.com>
> *Date: *Wednesday, 11 March 2020 at 22:03
> *To: *Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> *Cc: *Andrew Alston <Andrew.Alston@liquidtelecom.com>, 6man WG <ipv6@ietf.org>
> *Subject: *Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
> 
>  
> 
> Hi Ron, I made no comment in this thread on draft-ietf-spring-network-programming.
> 
>  
> 
> Darren
> 
> 
> 
>     On Mar 11, 2020, at 2:55 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org <mailto:rbonica=40juniper.net@dmarc.ietf.org>> wrote:
> 
>      
> 
>     Darren,
> 
>      
> 
>     Didn’t we agree to close issue 66 because draft-ietf-6man-segment-routing header contains no text regarding SID/IPv6 address semantics. If that’s the case, how can you say that closing issue 66 implies WG consensus around SID/IPv6 address semantic proposed in draft-ietf-6man-network-programming?
> 
>      
> 
>                                                                                            Ron
> 
>      
> 
>      
> 
>      
> 
>     Juniper Business Use Only
> 
>     *From:* ipv6 <ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>> *On Behalf Of *Darren Dukes (ddukes)
>     *Sent:* Tuesday, March 10, 2020 12:07 PM
>     *To:* EXT-Andrew.Alston@liquidtelecom.com <mailto:EXT-Andrew.Alston@liquidtelecom.com> <Andrew.Alston@liquidtelecom.com <mailto:Andrew.Alston@liquidtelecom.com>>
>     *Cc:* 6man WG <ipv6@ietf.org <mailto:ipv6@ietf.org>>
>     *Subject:* Re: draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?
> 
>      
> 
>     Hi Andrew please see issue #66 for the closure record. 
> 
>      
> 
>     https://trac.ietf.org/trac/6man/ticket/66 <https://urldefense.com/v3/__https:/trac.ietf.org/trac/6man/ticket/66__;!!NEt6yMaO-gk!RN-QFuaCraX6vU74Vusek5FlDyBGgfC2Teh1Vz40nw0PBhWdPtA-SA3t_rxaFg4_$>
> 
>      
> 
>     Darren
> 
>      
> 
>         On Mar 9, 2020, at 3:18 PM, Andrew Alston <Andrew.Alston@liquidtelecom.com <mailto:Andrew.Alston@liquidtelecom.com>> wrote:
> 
>          
> 
>         Hi Darren
> 
>          
> 
>         >  Hi Mark, the working group discussed the
> 
>          > association with RFC4291 and closed it with
> 
>          > the text in the document.
> 
>          
> 
>         Can we get a reference to these discussions please - would just be useful to back and refresh memories and wasn’t able to find them
> 
>          
> 
>         Thanks
> 
>          
> 
>         Andrew
> 
>  
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>