Subject: [Srcomp] Section 3 analysis for CRH

From: Ron Bonica <[email-masked]>
Date: Fri, 9 Apr 2021 15:58:07 +0000

Folks,

The following is CRH data for Section 3 of the analysis document:

3.1 - TBD. I will work on this Monday and Tuesday
3.2.1      FSID - Compliant
                FSCOPE - Compliant
                F.PFX - Compliant
F.ADJ - Compliant
F.BIND - Compliant
F.PEER - specification required
F.SVC - compliant
F.ALG - compliant (see IP Flexalgo draft)
F.TILFA - compliant
F.SEC - Compliant
F.IGP - Compliant ( see ISIS CRH draft)
F.BGP - Compliant (see CRH BGP draft)
F.POL - compliant
                F.BLS - specification required
F.SFC - compliant
                F.PING: compliant

3.2.2 Compliant. Satisfies this requirement by using a binding SID to impose an additional SRv6 header (IPv6 header plus optional SRH) with non-compressed SID.

3.2.3. Compliant. See Section 2.1. for compression at each SR path length.

3.2.4. Not compliant

3.3.1. Compliant. And classic SID can be represented by a CRH SID.

3.4 Compliant. The 16-bit CRH SID can represent 65K objects. The 32-bit SID and TPF can represent 4G objects.

                                              Ron

Juniper Business Use Only

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 12 Apr 2021 14:33:30 +0000

Hi Ron, the CRH draft does not describe how adjacency nor binding segments work for CFIB.
Can you please point to the specifications describing the functionality claimed in 3.2.1.

Thanks
  Darren

On 2021-04-09, 11:58 AM, "Srcomp" <[email-masked]> wrote:

Folks,

3.1 – TBD. I will work on this Monday and Tuesday
3.2.1      FSID – Compliant
                FSCOPE – Compliant
                F.PFX – Compliant
F.ADJ – Compliant
F.BIND – Compliant
F.PEER – specification required
F.SVC – compliant
F.ALG – compliant (see IP Flexalgo draft)
F.TILFA – compliant
F.SEC – Compliant
F.IGP – Compliant ( see ISIS CRH draft)
F.BGP – Compliant (see CRH BGP draft)
F.POL - compliant
                F.BLS – specification required
F.SFC - compliant
                F.PING: compliant

3.2.4. Not compliant

                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 12 Apr 2021 14:48:30 +0000

Darren,

Take a look at Section 4 of the CRH draft.

                               Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, April 12, 2021 10:34 AM
To: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: [Srcomp] Section 3 analysis for CRH

[External Email. Be cautious of content]

Thanks
  Darren

On 2021-04-09, 11:58 AM, "Srcomp" <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

3.2.4. Not compliant

                                              Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 13 Apr 2021 11:46:29 +0000

Thanks for that pointer, however there is no mention of adjacency nor binding SIDs in that text.

   Each CRH-FIB entry contains:

   o  An IPv6 address.

   o  A topological function.

   o  Arguments for the topological function (optional).

   o  Flags.

   o  A service function (optional).

   o  Arguments for the service function (optional).

   The IPv6 address can represent either:

   o  An interface on the next segment endpoint.

   o  An SRv6 SID [I-D.ietf-spring-srv6-network-programming],
      instantiated on the next segment endpoint.

Darren
On 2021-04-12, 10:48 AM, "Ron Bonica" <rbonica=[email-masked]> wrote:

Darren,

                               Ron

Thanks
  Darren

Folks,

3.2.4. Not compliant

                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Apr 2021 13:55:52 +0000

Darren,

If you read a little farther, you will see the following text:

   The topological function specifies how the processing node forwards
   the packet to the next segment endpoint.  The following are examples:

   o  Forward the packet through the least-cost path to the next segment
      endpoint.

   o  Forward the packet through a specified interface to the next
      segment endpoint.

The first bullet point clearly refers to prefix segments while the second clearly refers to adjacency segments. These are only two examples. The text  does not preclude binding segments.

Last year, when this draft was up for adoption, there was considerable pressure to avoid SRv6 terminology. However, I would be glad to use it if it clarifies anything.

                                                                                        Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Tuesday, April 13, 2021 7:46 AM
To: Ron Bonica <rbonica=[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: Section 3 analysis for CRH

   o  An IPv6 address.

   o  Flags.

Darren
On 2021-04-12, 10:48 AM, "Ron Bonica" <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Darren,

                               Ron

Juniper Business Use Only
From: Srcomp <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, April 12, 2021 10:34 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Srcomp] Section 3 analysis for CRH

Thanks
  Darren

Folks,

3.2.4. Not compliant

                                              Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 13 Apr 2021 17:07:04 +0000

Thanks for the specific text reference, I have two observations:
1 – the CRHSID adjacency segment requires adjacent nodes support CRH, since the next segment endpoint of the topological adj function is the adjacent node.  The adjacent node must lookup the next segment (prefix or adjacency).
This needs to be noted in the F.ADJ analysis since it’s a significant difference in functionality vs the SRv6 adjacency functionality which only requires adjacent nodes support IPv6.

2 – Relating the CRH adjacency behavior to binding segment, the CRHSID binding segment requires the binding segment endpoint node support CRH as well.
This needs to be noted in F.BIND analysis.

Thanks
  Darren

On 2021-04-13, 9:56 AM, "Ron Bonica" <[email-masked]> wrote:

Darren,

                                                                                        Ron

   o  An IPv6 address.

   o  Flags.

Darren

Darren,

                               Ron

Thanks
  Darren

Folks,

3.2.4. Not compliant

                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Apr 2021 18:41:22 +0000

Darren,

     Inline....

           Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]>
Sent: Tuesday, April 13, 2021 1:07 PM
To: Ron Bonica <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: Section 3 analysis for CRH

Thanks for the specific text reference, I have two observations:
1 - the CRHSID adjacency segment requires adjacent nodes support CRH, since the next segment endpoint of the topological adj function is the adjacent node.  The adjacent node must lookup the next segment (prefix or adjacency).
This needs to be noted in the F.ADJ analysis since it's a significant difference in functionality vs the SRv6 adjacency functionality which only requires adjacent nodes support IPv6.

[RB] I don't agree. Consider a CRH FIB entry where the IP address is several hops away but the topological function is to forward through a specific interface. I can't see why anybody would want to do this, but it can be done.

2 - Relating the CRH adjacency behavior to binding segment, the CRHSID binding segment requires the binding segment endpoint node support CRH as well.
This needs to be noted in F.BIND analysis.

[RB] The same argument applies here.

                               Ron

Thanks
  Darren

On 2021-04-13, 9:56 AM, "Ron Bonica" <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

                                                                                        Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, April 13, 2021 7:46 AM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Section 3 analysis for CRH

   o  An IPv6 address.

   o  Flags.

Darren

Darren,

                               Ron

Thanks
  Darren

Folks,

3.2.4. Not compliant

                                              Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 14 Apr 2021 11:10:40 +0000

See Inline... [DD]

[RB] I don’t agree. Consider a CRH FIB entry where the IP address is several hops away but the topological function is to forward through a specific interface. I can’t see why anybody would want to do this, but it can be done.

[DD] Consider a CRH FIB entry where the topological function is to forward via a specific interface, or set of interfaces, to the next segment in the segment list (not an intermediate nodes IPv6 address).
This is the adjacency SID functionality documented in RFC8402 and RFC8986.
The CRH FIB entry does not provide this functionality, it requires an IP address of a CRH supporting node be used for each CRH FIB entry.
Therefore CRH it does not support SRv6 adjacency segment functionality.
This fact must be stated in the analysis, it has very broad impact.  One impact as stated above with non-CRH adjacent nodes.

[DD] Same argument applies

Darren
                               Ron

Thanks
  Darren

Darren,

                                                                                        Ron

   o  An IPv6 address.

   o  Flags.

Darren

Darren,

                               Ron

Thanks
  Darren

Folks,

3.2.4. Not compliant

                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Wed, 14 Apr 2021 19:31:57 +0000

Darren,

I am baffled by your response. I have running code that supports the adjacency segment using the CRH.

The only rationale that you offer to support your claim is that the CRH "requires an IP address of a CRH supporting node be used for each CRH FIB entry".

Which node is "the supporting node"? The one upstream of the node that instantiates the adjacency segment? The one immediately downstream? Another?

And if it does require another IP address, how do we jump from there to a claim that CRH doesn't support adjacency segments.

      Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Wednesday, April 14, 2021 7:11 AM
To: Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: Section 3 analysis for CRH

See Inline... [DD]

Darren
                               Ron

Thanks
  Darren

Darren,

                                                                                        Ron

   o  An IPv6 address.

   o  Flags.

Darren

Darren,

                               Ron

Thanks
  Darren

Folks,

3.2.4. Not compliant

                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Thu, 15 Apr 2021 21:48:15 +0000

Folks,

In Section 3.2.1, we can put a Yes with the following note in the CRH column. The note is long, so we need to find a place for it.

                                       Ron

NOTE
-------
In one use-case, the uncompressed SRv6 END.X SID works differently than the CRH compressed END.X SID.  Consider the following network topology:

                          Network A
                        /          |            \
     S  ----  P                 | --------  D1
                        \             -------- DN
                           \          |         /
                            Network B

  *   The SR domain contains Node S, Node P, and a set of destination nodes (D1 through DN)
  *   S is connected to P
  *   P is connected to Network A and to Network B. Neither of these networks are SR-capable.
  *   The destination nodes  connect to both Network A and Network B

S needs to reach each destination node through two SR paths. One SR path traverses:

  *   A prefix segment that is instantiated on node S and takes the packet to Node P
  *   An adjacency segment that is instantiated on Node P and takes the packet through Network A to a destination node

The other SR path traverses:

  *   A prefix segment that is instantiated on node S and takes the packet to Node P
  *   An adjacency segment that is instantiated on Node P and takes the packet through Network B to a destination node

Uncompressed SRv6 can achieve this goal by instantiating 2 adjacency SIDs on Node P (one per outbound interface). CRH compressed SRv6 can achieve this goal:

  *   by 2 * N adjacency SIDs on Node P (one per path).
  *   By adding a segment to the path. In this scenario, two segments are instantiated on Node P. The first segment causes the destination address to be updated, but does not cause the packet to be forwarded. The second segment is an adjacency segment.

                                                                                                    Ron

Thanks
  Darren

Darren,

                                                                                        Ron

   o  An IPv6 address.

   o  Flags.

Darren

Darren,

                               Ron

Thanks
  Darren

Folks,

3.2.4. Not compliant

                                              Ron