[IPv6]Re: Éric Vyncke's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)

[Ron Bonica <[e-mail]>]

Eric,

See response, inline [RB].

I will post an updated version tonight so that you can clear your discuss.

                               Ron



Juniper Business Use Only

________________________________
From: Éric Vyncke via Datatracker <[e-mail]>
Sent: Wednesday, May 29, 2024 3:16 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Éric Vyncke's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


Éric Vyncke has entered the following ballot position for
draft-ietf-6man-comp-rtg-hdr-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcjnBaXmI$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcZZQBom0$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-08

Thank you for the work put into this document. I do like the idea of
compressing SRH-like header, but the document has room for improvements.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Bob Hinden for the shepherd's detailed write-up including the
WG consensus *but* it lacks the justification of the intended status (and IMHO
experimental is the right one).

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcZOFq8Vg$ , a
DISCUSS ballot is a request to have a discussion on the following topics:

## Section 5

`Decrement the IPv6 Hop Limit.` what do to when hop limit is 0 ? Is there a
deviation from RFC 8200 section 3, else why repeating this step ?

[RB] Agree. IPv6 already decrements the Hop Limit as it processes the base IPv6 header. So, decrementing it again would be a bad thing. I have removed that step

## Section 7

It is not clear to me why this document needs to make an allowance for
intermediate nodes (sic) that verify transport layer checksums. Transport layer
checksums are expected to be verified by the Transport layer endpoints and not
in the network. So since when the Internet architecture has changed to take
care of `it prevents intermediate nodes from verifying transport layer
checksums`? Actual references are required for such statement. And,
explanations should be given whether this "sentence" helps RFC 7258 pervasive
monitoring perhaps in the security considerations section.

[RB] Agree. I have removed section 7 in its entirety.

## Section 11

While not a real DISCUSS criteria, I am really surprised to see an IPv4-like
notation for CRH SID.

[RB] Why not? IPv4-like is a convenient notation for 32-bit values. Is there a reason not to like it? Can you propose an alternaive?

## Section 12

As AH is end-to-end, intermediate nodes do not have the shared secret, hence
`The CRH is not compatibile with AH processing at intermediate nodes.` is
useless and confusing. Please remove. Very similar to the DISCUSS about section
7.

[RB] Agree. I have removed that sentence


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# COMMENTS (non-blocking)

## Abstract

Can we really write `deployed` for an experimental I-D?

[RB] The purpose of any IETF experiment is to demonstrate that something can be deployed. You might want to deploy in a risk-free environment at first. But if you don't demonstrate deployability, why bother.

## Section 1

s/to its destination/to its destination(s)/ (think multicast/anycast). Twice in
the section ;)

[RB] Done

Suggest to move the motivation to its own section.

[RB] I am going to push back on this. If we did that, the introduction would contain only one paragraph.


## Section 3

Any recommendation on when to do `The first CRH SID in the path can be omitted
from the list.`?

[RB] Changed the sentence to read "The first CRH SID in the path is omitted from the list unless there is some reason to preserve it."

What is the expected behavior of any CRH-aware router and final node(s) when
`the Type- specific data field MUST be padded with zeros` is not respected ?

[RB] If it is padded with non-zero data, there should be no problem. CRH processing does not inspect padding values.

[RB] If it is not padded at all, IPv6 will not be able to find the beginning of the header following the CRH and the packet will be dropped.

[RB] I don't think that we need to mention this because it is generic IPv6 behavior and not specific to CRH.


## Section 4

Can the IPv6 address in the CRH-FIB be a link-local or multicast or can only be
a unicast ? Section 5 gives some more explanations, but an early one would be
better.

[RB] Added the following:

[RB]
The IPv6 address can be a Global Unicast Address (GUA), a Link Local Unicast address (LLU), or a
Unique Local Address (ULA). When the IPv6 address is the final address in a path,
it can also be a multicast address.


## Section 5

The first bullet can probably be removed as it is the normal behavior of any
IPv6 node per RFC 8200.

[RB] Done

`If Hdr Ext Len indicates that the CRH is larger than the implementation can
process, ` suggest using code 6 per
https://urldefense.com/v3/__https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml*icmpv6-parameters-codes-5__;Iw!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmc25Y-TxM$

[RB] Done

While wasting octets with too large CRH (i.e., larger than the minimum length)
is a bad thing, does it deserve to discard the packet on transit ? Why not
requesting the source to enforce this mimimum length?

[RB] This is defensive coding. The source may be buggy or hostile. If the CRH is malformed, the processing node should attempt to access bits beyond the end of it. This could cause a router to crash.

`If the search does not return a CRH-FIB entry` is the code 0 the most suitable
code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destination
unreachable' ?

[RB] I'm going to push back on this. Destination Unreachable isn't appropriate because it suggests that the destination in the base IPv6 header isn't reachable. That isn't the case. I could create a new code, but I don't want to clutter up the registry with experimental stuff. So, parameter problem is good enough for now

`If Segments Left is greater than 0` this will always be the case per first
bullet `If Segments Left equals 0` ;-)

[RB] Not true. Segments left was decremented two steps above.

The reader will welcome a justification of `CRH-FIB entry contains a multicast
address, discard the packet and`.

[RB] Added a parenthetic comment that this prevents packet storms.

## Section 6

I guess that this is linked to RFC 4302 (AH), so, please state this clearly.

[RB] Yes, RFC 4302 demands that this section is present. But do we really need another reference back to RFC 4302?

## Section 7

Is it about `Destination Address Transparency` or privacy ?

[RB] This section was deleted in response to your previous comment.

## Section 8

`Each CRH SID is processed by exactly one node.` isn't it rather "Each CRH SID
is processed by exactly one CRH-configured router whose one address matches the
packet destination address" ?

[RB] Done

## Section 9

The title should rather be "operational considerations"

[RB] Done

What are the "representations described herein" in ` It is recommended that the
experimental versions of PING use the text representations described herein` ?
Is it about section 11 ? Then please add a forward reference.

[RB] Done

## Section 10

This is the usual considerations about ICMP, please consider to remove this
section. Or refer for section 5 of RFC 4443.

[RB] Removed

## Section 11

Beside the above semi-DISCUSS, please state that hexadecimal should be in lower
case.

[RB] Words "lower-case" added.

## Section 12

`The Source Address does not identify an interface on a trusted node.` is there
any hint how this can be done ? How will it scale if all CRH-enabled router
must know all the specific address of all trusted nodes ? The same scalability
issue for `The ACL discards packets whose source address identifies an
interface on a trusted node.`

[RB] This is one of the things that we ask the experimenters to report on. Some numbering plans support efficient ACLs. Others don't

[RB] SRv6 has the same problems. Maybe we should develop common text that we both can use.

## Section 13

If the Wireshark/tcpdump modifications (cited in section 9) are public, then
references to code will be welcome.

[RB] The citations of which I am aware are comprehensible to Wireshark/tcpdump developers, but not to the general public. Do you know of any better citations.

`Interoperability among these implementations has not yet been demonstrated.`
should rather be in section 14 'experimental results'

[RB] Not really. Section 14 doesn't provide experimental results. It describes experimental result documents that should be written when the experiment is complete.

## Section 14

I am indeed very curious to see the experimental result of
```
Mechanism used to populate the FIB
Scale of deployment

[RB] Is this comment within the scope of this document? Or are you anticipating the experimental results document?
```
even if the text states in one year after publication as an RFC, this work
started back in 2019 and was adopted in 2023, do we already have some results ?

[RB] Again, is this comment within the scope of this document? Or are you anticipating the experimental results document?

What are the possible next steps as seen by the authors / 6MAN WG is the
experiment is assumed to be successful ? And what are the criteria to declare a
successful experiment ?

[RB] Section 14 describes experimental results to be reported. To the best of my knowledge, these results will provide a pretty good picture of whether the experiment succeeded or failed.

[RB] If the experiment fails, it fails. If it succeeds, the community will have a few options. Is there any outcome to which you would object.

                                  Ron

# NITS (non-blocking / cosmetic)

## Section 12

s/This is becasue /This is because/