Re: [Srcomp] Section 3 analysis for CRH

[Ron Bonica <[e-mail]>]

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





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

[External Email. Be cautious of content]

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" <[e-mail]<mailto:[e-mail]>> wrote:

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) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, April 13, 2021 7:46 AM
To: Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; Ron Bonica <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Section 3 analysis for CRH

[External Email. Be cautious of content]

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=[e-mail]<mailto:rbonica=[e-mail]>> wrote:

Darren,

Take a look at Section 4 of the CRH draft.

                               Ron




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

[External Email. Be cautious of content]

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" <[e-mail]<mailto:[e-mail]>> wrote:

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