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

Mark Smith <markzzzsmith@gmail.com> Sat, 16 May 2020 05:09 UTC

Return-Path: <markzzzsmith@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 DDAC63A03FE for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 22:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.928
X-Spam-Level: *
X-Spam-Status: No, score=1.928 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.626, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, 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 VYaZIOEQWC04 for <ipv6@ietfa.amsl.com>; Fri, 15 May 2020 22:09:10 -0700 (PDT)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 BCEE43A00B0 for <6man@ietf.org>; Fri, 15 May 2020 22:09:10 -0700 (PDT)
Received: by mail-oi1-x236.google.com with SMTP id o24so4289622oic.0 for <6man@ietf.org>; Fri, 15 May 2020 22:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n4DS2p65LtiJuVNex5CwYbLNTPToU04vAGXIZWwpRfo=; b=OdXTfvlKANAkuSpmjICyjUeW5g/Rm7H2SKOXV4b/iM5GPzEGtD4EiTME5fboF3Xmbn DzHo4WCEO2m/R24dLQU7Ebzev8VbSkOIx8V4EeU/qbncs0GsxqvJEbwamklljYc91wHS tz7FVvzWJatmpLC2qbmgk1Pd8B3mcH6EWhZG9gae3RZrGgYs3Rrp00AlZ8P/zsq203ba QbdnZtbLYLyn+f09PvSrQGSmCphdeu2G5weF0AyAdMbD6Wlo3ec/ZTCcBDWk9amPKMcJ RxpNzkZpZio1Y2p3EzUFqsS/o3mF8jIuwNJfxx1GWh5hne+KNN+TzSiFoes4gdsUqOzy Rbvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n4DS2p65LtiJuVNex5CwYbLNTPToU04vAGXIZWwpRfo=; b=WRameJn17cyC4BXxPAUAMnS9Ka71K7enKfGjC7cSIf3xbzo7PQiBLAPWD+zRW4U5Zi YezNsedqIDsfx5Aq57V42G8GmKQFzpnGvR8ncN3kfSjOr1FM1RauEw4rrETV2RkFVX7k vTENXOnihd0fGtI+qRqw2nrrnJZH+BcXBtLr+CGv9M4ssT2KHlZ27hZ/CORZz4l8QxpD CU2dVncEORt2m8y9KnsUdhgalpMK4wYM4I53utMya9u4Wz7XPT+C3fyYuKeddn8dZ0Oo B2tVvyoKfPsJKRpkh2Lucvw4K+VJ6U6GKrpPnHoT4XzDLJkvg0ff8254oF3ZgatkT+xe Os0g==
X-Gm-Message-State: AOAM530xHFy7Qf8XnvNfPoO10DXIUFoO4z4dVvLvflGQ48mQ+XSWw0a0 Dnd4PDRh8aLVsbWb31cIjMqSJ73JuqY3dJKDw8E=
X-Google-Smtp-Source: ABdhPJzuGdQWkkFnjfRLH1THVuLBD0ZesFUpLrC03vvgLL4lQPRXupngAmrVldImh/1ffzhv4Vu6hXRiyjbN062L3Ik=
X-Received: by 2002:aca:d7c6:: with SMTP id o189mr4302405oig.164.1589605749935; Fri, 15 May 2020 22:09:09 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR05MB634898C57C186C0133B2F852AEBA0@DM6PR05MB6348.namprd05.prod.outlook.com> <fec4e31b-0c98-7b3b-bbf0-d3225a21bc30@gmail.com> <DM6PR05MB634857FF18A11F58C42EC176AEBA0@DM6PR05MB6348.namprd05.prod.outlook.com> <a6f6ff2c-3ae7-6ffc-928d-fcf37557abfe@gmail.com>
In-Reply-To: <a6f6ff2c-3ae7-6ffc-928d-fcf37557abfe@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sat, 16 May 2020 15:08:58 +1000
Message-ID: <CAO42Z2xkmZdL0G=1iafyFKz6wWy69VcHtQ5ntu497eL8iVuzWw@mail.gmail.com>
Subject: Re: Applicability, Use-cases, and Architecture for the CRH
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Ron Bonica <rbonica@juniper.net>, 6MAN <6man@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000ed5cf05a5bcee92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/4cAm_EFh44BASUaB1msfGeulcGE>
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 05:09:13 -0000

On Sat, 16 May 2020, 14:46 Brian E Carpenter, <brian.e.carpenter@gmail.com>
wrote:

> Ron,
>
> Definitely, if it isn't the same, I would rename it. I like memorable
> acronyms, so could I suggest FIDO (Forwarding IDentity Object)?
>

The longer term used in RFC 8200 for these things is "route segments"
(although another issue with RFC 8200 is that it doesn't specifically
explicitly define what they are).

So in CRH I think they should be called "Route Segments", and identified
with "Route Segment Identifiers" (RSIDs, pronounced "R-SIDs") or "Compact
Route Segment Identifiers" (CRSIDs, pronounced "C-R-SIDs").

Regards,
Mark.


Regards,
Mark.



>    Brian
> On 16-May-20 15:45, Ron Bonica wrote:
> > Brian,
> >
> >
> > An SRH SID is semantically very different from a CRH SID. So, I would be
> happy to rename the CRH SID to something else. Maybe the CRH-FIB-ID?
> >
> > I would also be glad to recognize the contributions of
> draft-lc-6man-generalized-srh-00.
> >
> >
>                                         Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> > Sent: Friday, May 15, 2020 9:41 PM
> > To: Ron Bonica <rbonica@juniper.net>et>; 6man@ietf.org
> > Subject: Re: Applicability, Use-cases, and Architecture for the CRH
> >
> > [External Email. Be cautious of content]
> >
> >
> > 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH9tRrUf-$
> >
> > 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
> >> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH-k2Yi-w$
> >> --------------------------------------------------------------------
> >>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>