Types of Segment IDs in CRH - same as Spring SIDs !

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi Ron,



You still do not name segment types in this version of the draft.

*        You called them "loose" and "strict" in your email [1].

*        In previous versions you called them "Prefix SID" and "Adjacency" [2] and in your ISIS draft [3].



It seems clear to anyone that knows and understands Spring work; these are the same fundamental Segment Routing Prefix and Adjacency SIDs [4].



It seems clear that you are trying to package what is essentially a RH that is based on Spring work as something else - but it comes through obviously in the draft.

Changing names, removing references and avoiding their identification does not change the sole use of CRH.



https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4 has:



   Each CRH-FIB entry contains:



   o  A IPv6 address.



   o  A forwarding method.

KT> This is nothing but a function/behavior in SRv6. In case of SR-MPLS, it would map to Prefix, Adjacency and Binding SID instructions.



   o  Method-specific parameters (optional).

KT> This is same as arguments or context



Further on



   The forwarding method specifies how the processing node will forward

   the packet to the next segment endpoint.  The following are examples:



   o  Forward the packet to the next-hop along the least-cost path to

      the next segment endpoint.

KT> Exactly the definition of Prefix SID



   o  Forward the packet through a specified interface to the next

      segment endpoint.

KT> Exactly the Adjacency SID.



   Some forwarding methods require method-specific parameters.  For

   example, a forwarding method might require a parameter that

   identifies the interface through which the packet should be

   forwarded.

KT> It is clear you mean to introduce more such "methods" - this is nothing but the other Spring Segment ID types and their associated instructions.



The change done in https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-5 processing rules says :


   o  Submit the packet and optional parameters to the IPv6 module.
      Optional parameters are derived from the CRH-SID.  See NOTE.

   NOTE: By default, the IPv6 module determines the next-hop and
   forwards the packet.  However, optional parameters may ellicit
   another behavior.  For example, if a next-hop is provided as an
   optional parameter, the IPv6 module forwards to that next-hop.

KT> How is this not exactly like the different instructions/behaviors specified in Spring.



It is clear that this work is associated with and leverages the Spring architecture. The original motivation for this work was for bringing compression efficiency (which is being worked on in Spring).



No amount of removal of references and taking things out of this draft will change its original and still intended purpose. A leopard cannot change its spots!



Adoption call for this draft in 6man WG without the compression discussion in Spring WG will be going against the decisions that we've heard in the past about how the Spring and 6man WGs are going to collaborate.



Thanks,

Ketan



[1] https://mailarchive.ietf.org/arch/msg/ipv6/9zu-vMqJSdvJAzQENExWMEP4kYw/

[2] https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-5.2.2

[3] https://tools.ietf.org/html/draft-bonica-lsr-crh-isis-extensions-02#section-4

[4] https://tools.ietf.org/html/rfc8402#section-3





-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Ron Bonica
Sent: 14 May 2020 21:14
To: 6man <[e-mail]>
Subject: FW: New Version Notification for draft-bonica-6man-comp-rtg-hdr-19.txt



Folks,



This draft version addresses Ketan's comment. It also adds Gyan Mishra as a contributor, as he helped work through this and many other issues.



                                       Ron





Juniper Business Use Only



> -----Original Message-----

> From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

> Sent: Thursday, May 14, 2020 11:36 AM

> To: [e-mail]<mailto:[e-mail]>

> <[e-mail]<mailto:[e-mail]>>; Luay Jalil

> <[e-mail]<mailto:[e-mail]>>; Tomonobu Niwa <[e-mail]<mailto:[e-mail]>>; Yuji

> Kamite <[e-mail]<mailto:[e-mail]>>; Ron Bonica <[e-mail]<mailto:[e-mail]>>; EXT-

> [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

> Subject: New Version Notification for draft-bonica-6man-comp-rtg-hdr-

> 19.txt

>

> [External Email. Be cautious of content]

>

>

> A new version of I-D, draft-bonica-6man-comp-rtg-hdr-19.txt

> has been successfully submitted by Ron Bonica and posted to the IETF

> repository.

>

> Name:           draft-bonica-6man-comp-rtg-hdr

> Revision:       19

> Title:          The IPv6 Compact Routing Header (CRH)

> Document date:  2020-05-14

> Group:          Individual Submission

> Pages:          14

> URL:             https://www.ietf.org/internet-drafts/draft-bonica-6man-comp-rtg-hdr-19.txt

> Status:         https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr

> Htmlized:     https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-19

> Htmlized:     https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr

> Diff:              https://www.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-19

>

> Abstract:

>    This document defines two new Routing header types.  Collectively,

>    they are called the Compact Routing Headers (CRH).  Individually,

>    they are called CRH-16 and CRH-32.

>

>

>

>

> Please note that it may take a couple of minutes from the time of

> submission until the htmlized version and diff are available at tools.ietf.org.

>

> The IETF Secretariat

>

--------------------------------------------------------------------

IETF IPv6 working group mailing list

[e-mail]<mailto:[e-mail]>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------