Re: CRH and RH0

[Robert Raszuk <[e-mail]>]

Dear Ron,

Two questions:

*The CRH can be used within any network where:*

   - *All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and
   forwarding methods*

Can you confirm that if I have at least one node which can not maintain
CRH-FIB CRH can not be used in the entire network ? To me that is
sever limitation and deployment blocker. Are you saying that legacy node -
pure IPv6 transit - can not just forward based on the DA address and must
always inspect CRH ?

*The CRH can be used to provide traffic steering in:*



   - *Data centers*
   - *Service provider networks*
   - *Enterprise networks*

Is there any reason why you have not listed "Home networks" and "Lab
networks" ?

Many thx,
R.


On Thu, May 14, 2020 at 3:30 AM Ron Bonica <[e-mail]> wrote:

> Darren,
>
>
>
> If I were to add the following sections to the draft, would they address
> your concern. If not, what else is needed? Please be specific.
>
>
>
>
>                                   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.
>    - All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses
>    and forwarding methods
>    - 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
>       - Stand-alone
>       - 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 intermediate 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
>
> *From:* Darren Dukes (ddukes) <ddukes=[e-mail]>
> *Sent:* Wednesday, May 13, 2020 6:01 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Robert Raszuk <[e-mail]>; Mark Smith <
> [e-mail]>; 6man <[e-mail]>; Bob Hinden <
> [e-mail]>
> *Subject:* Re: CRH and RH0
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Ron, like Shuping mentioned, SHR has an architecture document
> (RFC8402), problem statement (RFC7855) and use cases in RFC8354 & RFC8355
> to justify need for a SRH (RFC8754).
>
> CRH now has none.  Where are its architecture, applicability statement,
> use-cases documents?  This will let the WG evaluate the overall solution.
>
> You used to have a normative reference to SRm6 but you removed it
> apparently to distance this work from SPRING and SRm6.
>
>
>
> Darren
>
>
>
> On May 13, 2020, at 4:39 PM, Ron Bonica <
> rbonica=[e-mail]> wrote:
>
>
>
> Robert,
>
>
>
> As Darren points out, the SRH has so much stuff that CRH lacks:
>
>
>
>    - Tags
>    - Flags
>    - TLVs
>
>
>
> The CRH is a humble routing header that steers a packet along a delivery
> path. It can be describe in fourteen pages, with lots of white space.
>
>
>
> Maybe it should be called the Unpretentious Routing Header (URH) 😉
>
>
>
>                                                                  Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Wednesday, May 13, 2020 4:16 PM
> *To:* Mark Smith <[e-mail]>
> *Cc:* Ron Bonica <[e-mail]>; 6man <[e-mail]>; Bob Hinden <
> [e-mail]>
> *Subject:* Re: CRH and RH0
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> > Compact Routing Header.
>
>
>
> I am actually completely shocked what happened and why is it not being
> called *SRH+* ....
>
>
>
> ;-)
>
>
>
> Take care,
>
> R.
>
>
>
> On Wed, May 13, 2020 at 10:09 PM Mark Smith <[e-mail]>
> wrote:
>
> Compact Routing Header.
>
> On Thu, 14 May 2020, 05:58 Ron Bonica, <rbonica=
> [e-mail]> wrote:
>
> Erik,
>
> I could rename the CRH to something else. Maybe the Programmed Routing
> Header (PRH)? But would that make a difference to the folks who are voicing
> objections?
>
>                                                  Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Erik Kline <[e-mail]>
> Sent: Wednesday, May 13, 2020 1:56 PM
> To: Ron Bonica <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; 6man <[e-mail]>
> Subject: Re: CRH and RH0
>
> [External Email. Be cautious of content]
>
>
> I too find myself agreeing with Bob.
>
> Two random comments:
>
>   [1] there might be a better term than "compressed" with less baggage
> (naming is hard)
>
>   [2] for many, the architecture for distributing CP information is "my
> SDN", so I'm not convinced all the CP distribution needs to be worked out
> in advance
>
> On Wed, May 13, 2020 at 9:27 AM Ron Bonica <rbonica=
> [e-mail]> wrote:
> >
> > Bob,
> >
> > I think that your analysis is absolutely correct. Anything that relies
> on SPRING routing protocols is SPRING.
> >
> > I would add the corollary statement, anything that does not rely on
> SPRING routing protocols is not SPRING.
> >
> > Therefore, if CRH can be deployed in the absence of any routing protocol
> at all  (i.e., with static routes and a statically configured CRH-FIB), it
> is not SPRING.
> >
> >
>
> > Ron
> >
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: Bob Hinden <[e-mail]>
> > Sent: Wednesday, May 13, 2020 12:16 PM
> > To: 6man <[e-mail]>
> > Cc: Bob Hinden <[e-mail]>; Ron Bonica
> > <[e-mail]>; Robert Raszuk <[e-mail]>
> > Subject: Re: CRH and RH0
> >
> > Gentlepeople,
> >
> > IPv6 routing headers starting with RFC1883 published in 1995 used the
> term “segments” to identify elements in the list of addresses.   In that
> sense, all IPv6 routing headers do some form of segment routing.  It’s a
> generic term that has been around for 25 years.
> >
> > I think the underlying question with CRH is does it conflict with what
> is being done in the Spring w.g.
> >
> > To my thinking, what is being done in Spring is an architecture for
> distributing information that can be used to create source routes for SRH
> (RFC8754).   Anything that relies on that set of Spring routing protocols
> is part of the working being done in Spring.
> >
> > Likewise, to my thinking I don’t think that means that all new IPv6
> routing headers conflict with the work being done in the Spring w.g.
> >
> > Bob
> >
> >
> > > On May 13, 2020, at 8:55 AM, Robert Raszuk <[e-mail]> wrote:
> > >
> > > Ron,
> > >
> > > Oh - haven't we established just yesterday that you will not be
> referencing RH0 any longer with CRH proposal  ?
> > >
> > > It's like you are trying to build a vehicle  .. it has wheels,
> steering and even seats (no engine and no belts for now). But you keep
> insisting - it is not a car.
> > >
> > > See if you put normative reference to segment routing up to version
> -10 then suddenly drop it with no major change to the body of the draft the
> intentions are just obvious:
> > >
> > > 13.  References
> > >
> > >
> > >
> > > 13.1.  Normative References
> > >
> > >
> > >    [
> > > I-D.bonica-spring-srv6-plus
> > > ]
> > >               Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques,
> > >               D., Jalil, L., Halpern, J., Linkova, J., and G. Chen,
> > >               "Segment Routing Mapped To IPv6 (SRm6)",
> > > draft-bonica-
> > > spring-srv6-plus-06 (work in progress), October 2019.
> > >
> > > REF:
> > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica>
> > > -6man-comp-rtg-hdr-10__;!!NEt6yMaO-gk!QcAL7_ALlBjQGtAnsGVN1JsDVd305D
> > > lUw8Cr1FGDjAbPI5e93Il4WpTsbTWL9bL9$
> > >
> > > On Wed, May 13, 2020 at 5:41 PM Ron Bonica <[e-mail]>
> wrote:
> > > Robert,
> > >
> > >
> > >
> > > Oh, btw. RH0 had a “Segments Left” field. Because it talked about
> segments, would you like to claim that it was also SR?
> > >
> > >
> > >
> > >
>
> > > Ron
> > >
> > >
> > >
> > >
> > >
> > > Juniper Business Use Only
> > > From: Ron Bonica
> > > Sent: Wednesday, May 13, 2020 11:40 AM
> > > To: Robert Raszuk <[e-mail]>
> > > Cc: Bob Hinden <[e-mail]>; 6man <[e-mail]>
> > > Subject: RE: CRH and RH0
> > >
> > >
> > >
> > > Robert,
> > >
> > >
> > >
> > > So, you are really sure that these people don’t exist. Would you like
> to make a more explicit statement?
> > >
> > >
> > >
> > >
> > > Ron
> > >
> > >
> > >
> > >
> > >
> > > Juniper Business Use Only
> > > From: Robert Raszuk <[e-mail]>
> > > Sent: Wednesday, May 13, 2020 11:22 AM
> > > To: Ron Bonica <[e-mail]>
> > > Cc: Bob Hinden <[e-mail]>; 6man <[e-mail]>
> > > Subject: Re: CRH and RH0
> > >
> > >
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > >
> > > Hi Ron,
> > >
> > >
> > >
> > > >  Are you questioning whether that statement is true?
> > >
> > >
> > >
> > > Yes. Especially this point: " Are not interested in SR"
> > >
> > >
> > >
> > > Your draft only talks about SIDs and segments so no matter how you
> call it the core purpose is segment routing.
> > >
> > >
> > >
> > > Take care,
> > > R.
> > >
> > >
> > >
> > > On Wed, May 13, 2020 at 5:13 PM Ron Bonica <[e-mail]>
> wrote:
> > >
> > > Robert,
> > >
> > >
> > >
> > > At the interim meeting, I said that there are IPv6 operators who:
> > >
> > >
> > >
> > > ·         Want CRH
> > >
> > > ·         Are not interested in SR
> > >
> > > ·         Are averse to SRv6
> > >
> > >
> > >
> > > Are you questioning whether that statement is true?
> > >
> > >
> > >
> > >                                                           Ron
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Juniper Business Use Only
> > > From: Robert Raszuk <[e-mail]>
> > > Sent: Wednesday, May 13, 2020 3:22 AM
> > > To: Ron Bonica <[e-mail]>
> > > Cc: Bob Hinden <[e-mail]>; 6man <[e-mail]>
> > > Subject: Re: CRH and RH0
> > >
> > >
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > >
> > > Hi Ron,
> > >
> > >
> > >
> > > Given that it is only fifteen pages long, I suspect that progressing
> it would be less work than arguing about whether to progress it.
> > >
> > >
> > >
> > > Sometimes committing a bit more work yields much better results in the
> long run ...
> > >
> > >
> > >
> > > So it is clear that you are not just trying to fix suboptimalities of
> IPv6 encoding out of the woods. The goal is clear to get this in and use it
> as a hook to show in SPRING and other routing WGs in IETF that since you
> have CRH accepted as a WG docs in 6man other groups should follow along and
> work on SRm6 encodings.
> > >
> > >
> > >
> > > The mapping plane between SIDs and labels is already in place in
> SR-MPLS. Just changing few bit here and there does not make new proposal to
> stand on its own.
> > >
> > >
> > >
> > > I think it has been clearly stated by 6man chairs and AD that any work
> on SRm6 can be taken on only after SPRING WG accepts the main concept and
> adopts the main doc as a WG item.
> > >
> > >
> > >
> > > So I recommend we go via this proper path with the full picture in
> mind and the ultimate objective for CRH.
> > >
> > >
> > >
> > > Best regards,
> > >
> > > R.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests:
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6>
> > __;!!NEt6yMaO-gk!QcAL7_ALlBjQGtAnsGVN1JsDVd305DlUw8Cr1FGDjAbPI5e93Il4W
> > pTsbVcgbtWl$
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TjE3Uqlf3fJa9c2ENZOsvyJsNfZo_fj0sAV2EQTo1IIC8Q3TyFLz3m5vPgpU7JdB$>
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TjE3Uqlf3fJa9c2ENZOsvyJsNfZo_fj0sAV2EQTo1IIC8Q3TyFLz3m5vPgpU7JdB$>
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RFHzGcUlAy_yKte9j0LvSMyl512vVcOHpMtJNak9PgeVCPi4-rmsxuwpNLvR631g$>
> --------------------------------------------------------------------
>
>
>