Re: Applicability, Use-cases, and Architecture for the CRH

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 16 May 2020 23:42 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05083A0C10 for <ipv6@ietfa.amsl.com>; Sat, 16 May 2020 16:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 K3BhVM2BSeey for <ipv6@ietfa.amsl.com>; Sat, 16 May 2020 16:42:32 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 380FB3A0C11 for <6man@ietf.org>; Sat, 16 May 2020 16:42:32 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id g11so2567245plp.1 for <6man@ietf.org>; Sat, 16 May 2020 16:42:32 -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=9tuV4iCbxWNAaM3dUjBB0RYG45rvdnsRVtHkZNk4jpo=; b=T8sPcdjLbfCmkjARffg/WcO9H62Q7Tub1onDC1g9yQF7pOcT0BQ0lB1dIBDnc8VkDb f2DdCX58chykxOgWa1vLejuUMHjE8Ja5O4ddkrGf9i/S8SA4HgJe62N+crMo43BLv0ld HvkqKHMgISXpeEjGb35l/PCZyNDzai2QuwVYA3JGlP2Hvp1QN2JXiIkqbe2hoIYC0OTs A+xjC3RnGjjO0Cg0N08DauEahdhclvx9WzzUDXR3avpr1aPQlXXWiCbJo2TZXeMwjKHh J9Oo7cJ65cAuKME2t7TKeOC0ifeKduSjZYA7q+IGGuVX8+PX4CuFr7xhUJusLigt8Wxv QnVQ==
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=9tuV4iCbxWNAaM3dUjBB0RYG45rvdnsRVtHkZNk4jpo=; b=I5jPCzjyPiXUugL4hwzzUD3rG132NrovcCzmUzRkNWJ9dH6IlLUZTg9KyINFVkYaIG KBiu1pn9JKkvJSf741aK1I3u0sNFpKSjH7V5eVyijl6hJYsaswbcTI7m3uOTbS41WoeW 4ErfVTR7/2cBUsTm8/X595Uy+JBTFu4N3TDOKgDiC8BNXqKOVvN1ZP6YnnXsl3m37vHo 3QzHZHZJkqttd07BKj//Kn0IcX3EI3U96RUoQpcgoIdWL9CQSkMf3F/9gN/veDHl7to+ nyC/7O5KLtRqeJlz6o5bEuJhCQDQ4y1UOKwSJ9E3baOgK2Wd5Bz/YXPWZSmORrZeZqjH 75pg==
X-Gm-Message-State: AOAM530Z/YECwxkBGBuk/NK4PXgp8oAt/06sWLhUxywFCqzkcr9qVdvH xf9i0/vvzTX0tOYDeIUe8G7BLW61
X-Google-Smtp-Source: ABdhPJyIfiBcNdmnoWXxBYJlAfSh/EAZe0YWa6xcolNRF19M2QGXBmWayxdY9xsiNgOJMA28AIAl1w==
X-Received: by 2002:a17:90b:1098:: with SMTP id gj24mr11214742pjb.83.1589672551286; Sat, 16 May 2020 16:42:31 -0700 (PDT)
Received: from [192.168.178.30] ([165.84.12.178]) by smtp.gmail.com with ESMTPSA id x2sm930579pfi.64.2020.05.16.16.42.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 May 2020 16:42:30 -0700 (PDT)
Subject: Re: Applicability, Use-cases, and Architecture for the CRH
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, "6man@ietf.org" <6man@ietf.org>
References: <DM6PR05MB634898C57C186C0133B2F852AEBA0@DM6PR05MB6348.namprd05.prod.outlook.com> <fec4e31b-0c98-7b3b-bbf0-d3225a21bc30@gmail.com> <CA+RyBmViLx-OZkuDFV-eNOf6DW=T_OepE61wzomAR7dyiYY5Og@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <733fbbe2-b2c3-9e70-4fae-e6b6a3ab9e0f@gmail.com>
Date: Sun, 17 May 2020 11:42:27 +1200
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: <CA+RyBmViLx-OZkuDFV-eNOf6DW=T_OepE61wzomAR7dyiYY5Og@mail.gmail.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/ipv6/06Mu1UqQ4QeBWOdoqConGDorxRg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 May 2020 23:42:34 -0000

Hi Greg,
On 17-May-20 09:01, Greg Mirsky wrote:
> Hi Brian,
> comparing how CRH and G-SID proposals approach the task of the compact segment routing in IPv6 network I find the solutions quite different. 

Yes, because the G-SID authors took the decision to be compatible with SRH. But the idea of a short identifier that acts as a lookup index for the SID seems to be essentially the same.

> At the same time, the solution described in the Unified Identifier in IPv6 Segment Routing Networks <https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> may be compared with the benefits of using CRH.  What do you think?

I think that a reasoned comparison of alternative proposals is very desirable during an adoption discussion, so I'd welcome it, but I'm not competent to write it.

Rgds,
   Brian

> 
> Regards,
> Greg
> 
> On Fri, May 15, 2020 at 6:41 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> 
>     Hi Ron,
> 
>     Looking at your draft plus this extra material, I still think that the concept of a SID is helicoptered in to some extent. It isn't obvious to me that a SID in CRH is semantically the same thing as a SID in the Spring WG. Either it is, in which case you should cite the relevant SID RFC, or it isn't, in which case there is some more writing to do.
> 
>     I think you could also give an ack to the C-SIDs in https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00
> 
>     Regards
>        Brian Carpenter
> 
>     On 16-May-20 12:41, Ron Bonica wrote:
>     > Darren,
>     >
>     > In previous emails, you suggest that the CRH draft needs information regarding Applicability, Use-cases and Architecture. After the call for adoption, we could add the proposed text, below.
>     >
>     > Would this text address your concerns. If not, please provide specific recommendations.
>     >
>     >                                                                          Ron
>     >
>     >  
>     >
>     > PROPOSED TEXT
>     >
>     > ----------------------
>     >
>     >  
>     >
>     > 9.0 Applicability
>     >
>     >  
>     >
>     > The CRH can be used within any network where:
>     >
>     >   * All nodes implement IPv6.
>     >   * Edge node can filter inbound packets that contain the CRH.
>     >   * Selected nodes can process the CRH. If a node is identified in a CRH, and it is not the packet’s ultimate destination, it must be able to process the CRH.
>     >   * All nodes can maintain a basic FIB that maps IPv6 prefixes to next-hops.
>     >   * Selected nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and forwarding methods. If a node is identified in a CRH, and it is not the packet’s ultimate destination, it must be able to
>     >   * CRH overhead is acceptable
>     >
>     > CRH-16  overhead is as follows:
>     >
>     >   * 2 SIDs can be stored in a 8-byte CRH
>     >   * 6 SIDs can be stored in a 16-byte CRH
>     >   * 10 SIDs can be stored in a 24-byte CRH
>     >   * 14 SIDs can be stored in a 32-byte CRH
>     >   * Etc.
>     >
>     > CRH-32  overhead is as follows:
>     >
>     >   * 1 SIDs can be stored in a 8-byte CRH
>     >   * 3 SIDs can be stored in a 16-byte CRH
>     >   * 5 SIDs can be stored in a 24-byte CRH
>     >   * 7 SIDs can be stored in a 32-byte CRH
>     >   * Etc.
>     >
>     >  
>     >
>     > 10.0 Use-cases
>     >
>     >  
>     >
>     > The CRH can be used to provide traffic steering in:
>     >
>     >  
>     >
>     >   * Data centers
>     >   * Service provider networks
>     >   * Enterprise networks
>     >
>     > Each of these networks may have a preferred method for populating the basic FIB and the CRH-FIB. For example, a data center may use a controller to populate both FIBs while a service provider may use an IGP to populate both FIBs.
>     >
>     > The CRH can implemented on:
>     >
>     >   * ASIC-based routers
>     >   * Software-based routers
>     >       o Stand-alone
>     >       o In a container on a server in a data center
>     >
>     >  
>     >
>     >  
>     >
>     > 11.0 Architecture
>     >
>     >  
>     >
>     > CRH architecture determined entirely by RFC 8200. Specifically:
>     >
>     >  
>     >
>     >   * IPv6 source nodes use the CRH to determine nodes that a packet visits on route to is ultimate destination.
>     >   * The CRH does not subsume the function of any other IPv6 extension header. For example, the CRH cannot be used for authentication, or to deliver optional internet-layer information to the packet’s ultimate destination node.
>     >   * A packet that contains the CRH can also contain any valid combination of IPv6 extension headers. All extension header should function as per their specifications.
>     >   * The CRH assumes that IPv6 Destination Address semantics are as defined in RFC 8200 and RFC 4291.
>     >   * The CRH is processed identically on every node (See Section 5 of this document). Processing rules do not depend upon information encoded in the IPv6 Destination Address.
>     >   *  
>     >
>     > The CRH conforms to the letter and spirit of RFC 8200. For example:
>     >
>     >   * A packet cannot contain two instances of the CRH
>     >   * A CRH cannot be added or deleted by any node along a packet’s processing path
>     >
>     >  
>     >
>     >  
>     >
>     >
>     > Juniper Business Use Only
>     >
>     >
>     > --------------------------------------------------------------------
>     > IETF IPv6 working group mailing list
>     > ipv6@ietf.org <mailto:ipv6@ietf.org>
>     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     > --------------------------------------------------------------------
>     >
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>