Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

[Ron Bonica <[e-mail]>]

Adrian,

Thanks for your insightful review, comments and support.

Response inline [RB] ...........

                                              Ron


Juniper Business Use Only
-----Original Message-----
From: Adrian Farrel <[e-mail]>
Sent: Friday, January 5, 2024 3:55 PM
To: 'Jen Linkova' <[e-mail]>; '6man' <[e-mail]>
Cc: [e-mail]
Subject: RE: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

[External Email. Be cautious of content]


Hi,

During the adoption poll (not so very long ago) I supported this document and promised to review future revisions.

Well, here we are at working group last call already, so this is my review.

Tl,dr; I support publication of this document as Experimental.

Here are a few comments...

== medium ==

I'd like to see a bit more text about the experiment:

- I think it is obvious how you would judge whether it can be
  implemented, but how would you judge whether it can be deployed? Is
  there some measure of that?

[RB] This is a profound question. It should be asked of any new technology, including the CRH.

[RB] I know how to prove that a technology is *not* deployable. That is, to generate a non-exhaustive list of impediments to deployment then demonstrate the technology hitting one of those problems. But because the list is non-exhaustive, this method is not sufficient to prove deployability.

[RB] Can you think of a better method? I would be very happy to work this problem with you and possibly publish something in the OPS area. Seriously! I really think that we should work on this. It may produce something very significant.

[RB] But I don't think lacking this analysis should block the publication of an EXPERIMENTAL RFC. To date, no other EXPERIMENTAL RFCs have been held to that standard.

- How do you measure whether the security considerations can be
  addressed with ACLs?

[RB] The experimenter returns a binary result, either "yes, we did it" or "no, we couldn't do it because". As with any threat mitigation, we need to take all positive responses with a grain of salt. The operator may think that they have mitigated the threat, but the attacker gets the final word.

- Are there other things you are looking for like effectiveness of
  compression, suitability of CRH-16 vs CRH-32,

[RB] That can be predicted a-priori. If you like, I can add a table comparing RHO, CRH-16, and CRH-32 in the appendix.

Would be good to note what information you would like to see reported by this experiment (and its replicants) and where that information should be reported.

[RB] This is a *very good idea* for all Experimental  RFC. In the next version, I will add a section called "Experimental Results".

What timescales are you looking at for the experiment and is there a plan to report back if the experiment is successful?

[RB] I know of two operators who have already done the experiment. But I would like to allow one year for others to participate.

                                                               Ron


--

12.

For clarity, this section should say...

   IANA has made the following temporary early allocations in the
   "Internet Protocol Version 6 (IPv6) Parameters" "Routing Types"
   subregistry.  IANA is requested to make those registrations
   permanent and add this document as the reference.


[RB] Agree

== minor ==

7.

Puzzled by the use of "applications" in the section title. Seems to me that the title would read better as "Scope of SIDs" and that the text that says "Application can:" would be better as either "Implementations can:" or "Deployments can:"

But perhaps you are trying to indicate that some SIDs can have network- wide significance and some local significance in a mixed way within the network? That would feel a bit risky without some form of coordination.

[RB] Agree

---

8.

The assertion about PING and TRACEROUTE is nice to know, but it is exactly that: an assertion. I think one might add a line or two to explain how this is so.

The information about TCPDUMP and Wireshark:
- could use references
- is probably better in the implementation section

[RB] Agree

---

11.

Per RFC 7942 you may want to consider whether this is information that should remain in this document upon publication. It is true, but may become rapidly out of date with more implementations and deployment experience (and experiment reports). It might be better moved to a wiki.

Since this information is useful to the review process, a way to tackle this is to add an RFC Editor Note asking for the section to be removed upon publication.

== nits ==

per idnits, RFC 6890 is an unused reference.

---

1.

You have correctly used "Routing header" per 8200 in nearly all places.
Obviously CRH is still "Compact Routing Header", but apart from that, please check and fix all cases of "Routing Header" (there is one in Section 1).

--

1.

s/access control lists/Access Control Lists/

---

4.

s/(i.e.,strict/(i.e., strict/

---

5.

s/length ( Section 5.1)/length (Section 5.1)/

---

5.1

Wondering why your two lines "return(0)" do not qualify for a semi-colon

---

Best,
Adrian

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Jen Linkova
Sent: 04 January 2024 21:09
To: 6man <[e-mail]>
Cc: [e-mail]
Subject: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

This message starts a new two week 6MAN Working Group Last Call on advancing "The IPv6 Compact Routing Header (CRH)" document (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!DCYfItMl9NbPpo-ec2aQKMQnsXsK_EojJD8HHja93gJGrv1Jva7CfpiVOCfLuq-MuXtRkYoP1XndVzlTWg$ ) as an Experimental document.

Substantive comments and statements of support for publishing this document should be directed to the [e-mail] mailing list.
Editorial suggestions can be sent to the authors.  This last call will end on Jan 21 2024, 23:59:59 UTC.

--
Cheers, Jen Linkova on behalf of 6MAN chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!DCYfItMl9NbPpo-ec2aQKMQnsXsK_EojJD8HHja93gJGrv1Jva7CfpiVOCfLuq-MuXtRkYoP1Xn7w6zxlQ$
--------------------------------------------------------------------