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

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. 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?

Regards,
Greg

On Fri, May 15, 2020 at 6:41 PM Brian E Carpenter <
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
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>