Re: [Srcomp] Section 3 analysis for CRH

["Darren Dukes (ddukes)" <[e-mail]>]

See Inline... [DD]

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.

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


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.

[DD] Same argument applies

Darren
                               Ron


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