Re: What 's the process?

[John Scudder <[e-mail]>]

(Judging by the archives this didn’t go through on first send; trying again.)

Hi All,

I confess I don’t know all the process history some of you are referring to, forgive me if I don’t go familiarize myself with it before commenting. I feel OK about this since I do understand the technology reasonably well and also on my good days imagine I understand IETF process as well as the next person. (As the old joke goes, it may depend on who the next person is.)

It seems to me there are a few questions for the WG to consider here:

- Is there a reasonable application for the draft other than Segment Routing? It’s facially obvious that there is. (Furthermore we are told that there is interest in deploying such.)
- Is there a resource limitation such that prudence requires us to be very selective about what routing headers we allow to move forward? Bob helpfully pointed out that there’s no scarcity of code points. So, no.
- Does the spec make any other change to IPv6 the WG should look askance at? On the contrary, it fits carefully into the established IPv6 architecture.
- Does progressing this draft represent an end-run around SPRING, as has been suggested? I don’t see it. If SPRING doesn’t want to build on top of the spec, they shouldn’t. If they do, they should.

As for the fact the CRH-FIB has to be populated somehow, I don’t see how that is either here or there. To take an analogy, the plain old IPv6 FIB has to be populated somehow; this doesn’t mean 6man has to seek permission from every WG that maintains a routing or management protocol that might conceivably be put to that purpose, before it does something with IPv6. That kind of arbitrary insertion of organizational dependencies seems like a great recipe for deadlock.

As I read the 6man charter, this work falls squarely in 6man’s bailiwick. I don’t see a genuine problem here.

Thanks,

—John

On Feb 19, 2020, at 3:54 PM, James Guichard <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ron,

Having reminded myself of what RH0 was 😉 CRH seems very different given it is not a standalone IPv6 extension header since it introduces a notion of SIDs as its base forwarding construct. These SIDs need to be advertised and signaled via routing protocols and other mechanisms (indicating that other documents will in fact be necessary and therefore become a dependency) in order to distribute the mapping tables and setup the CRH FIB. This is quite different from RH0 which used IPv6 addresses as segments and did not need any new extensions in IPv6 routing protocols (CLI does not count in a serious deployment).

Respectfully,

Jim
[...etc...]