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

[Antonio Cianfrani <[e-mail]>]

Dear Adrian,
thanks for your reply.


>
> I just worked with Ron on creating Section 13 (“Experimental Results”) in
> the -02 version. You’ll notice there that one of the suggestions is that
> results of the experiment should be collected and reported, and that this
> should include information about interoperability. Interoperability is
> clearly an important aspect of deployability.
>

ok, I agree interoperability is a very important aspect to be taken into
account.


>
>
> That said, this document is proposed as an Experimental RFC and that is
> very different from a Standards Track document. The intention is to
> encourage implementation and experimentation, not to (immediately) produce
> a specification. Thus, Section 12 describes the implementation status at
> the time of publication, and is not a full report of the experiment. (FWIW,
> my advice is that Section 12 should be removed before publication as an RFC
> with a new “living document” created on a wiki, in github, or in a new
> draft, so that it can be updated to collect more information about
> experimentation.)
>
>
>
> Lastly, you say that “open source implementations are reported in the
> paper”, but I find no such reference in this version of any of the previous
> versions. Just the text in Section 12 reporting on two private
> implementations (one on hardware and one in a software router).
>

It was my fault: reading that a software router implementation is available
I thought about open source code. The reason is that I'm interested in
implementation details (that I cannot find in the paper) for research
activity and I wasn't able to find the code. For instance, it could be
interesting to take a look at the data model used for the new CRH FIB.

Anyway thanks a lot for the clarification.
Best,
Antonio


>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* ipv6 <[e-mail]> *On Behalf Of *Antonio Cianfrani
> *Sent:* 17 January 2024 23:00
> *To:* Ron Bonica <rbonica=[e-mail]>
> *Cc:* 6man <[e-mail]>; [e-mail]
> *Subject:* Re: [IPv6] Working Group Last Call for
> draft-ietf-6man-comp-rtg-hdr
>
>
>
> Dear Authors,
>
> in my opinion there are some open issues that should be clarified:
>
> - it seems that the solution is implemented on a single vendor devices:
> maybe an interoperability test with other vendors is necessary.
>
> - open source implementations are reported in the paper but no reference
> is provided (and I couldn’t find it on the web).
>
> Best regards,
>
> Antonio
>
>
>
> Il Sab 6 Gen 2024, 22:40 Ron Bonica <rbonica=[e-mail]>
> ha scritto:
>
> Fair enough.
>
>
>
>                       Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Tom Herbert <[e-mail]>
> *Sent:* Saturday, January 6, 2024 4:22 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Jen Linkova <[e-mail]>; 6man <[e-mail]>;
> [e-mail]
> *Subject:* Re: [IPv6] Working Group Last Call for
> draft-ietf-6man-comp-rtg-hdr
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> On Sat, Jan 6, 2024, 12:57 PM Ron Bonica <[e-mail]> wrote:
>
> Tom,
>
>
>
> Revealing the ultimate destination address to intermediate nodes has never
> been an explicitly stated requirement of the IPv6 Routing header.
> Therefore, it is beyond the scope of the current experiment.
>
> Ron,
>
>
>
> It may not be an explicit protocol requirement, but as I pointed out it
> may be an implicit operational requirement at least in some networks. Even
> if there's not a solution in this draft, I think it's worth mentioning in
> the draft the loss of visibility of the final destination and potential
> ramifications.
>
>
>
> Tom
>
>
>
>
>
> However, that doesn’t close the door to subsequent experiments. Please
> feel free to post a follow up draft.
>
>
>
>
> Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Tom Herbert <[e-mail]>
> *Sent:* Saturday, January 6, 2024 11:19 AM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Jen Linkova <[e-mail]>; 6man <[e-mail]>;
> [e-mail]
> *Subject:* Re: [IPv6] Working Group Last Call for
> draft-ietf-6man-comp-rtg-hdr
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> On Fri, Jan 5, 2024, 4:35 PM Ron Bonica <[e-mail]> wrote:
>
> Hi Tom,
>
> I believe that we have discussed this topic before, but it may have been
> off-list. So, I will repeat my argument on list.
>
> When considering your objection, we must consider:
>
> - its scope
> - the cost / benefit trade-off
>
> Regarding scope, you comment applies to many routing header compression
> scheme's not only the CRH. So, we should search for a solution that
> addresses all routing header compression schemes, not just the CRH.
>
>
>
> Hi Ron,
>
>
>
> Agreed.
>
>
>
>
> Regarding the cost / benefit trade-off, some operators may be concerned
> about the issue that you raise. They would be willing to sacrifice a few
> bytes of overhead for the additional functionality that you propose. Other
> operators, not so much.
>
>
>
> Yes, this trade-off could be one of the questions answered in the
> experiment.
>
>
> So, it seems that we should look for a solution that a) is applicable to
> many routing header compression scheme's and b) is optional. Clause a)
> precludes a solution that is embedded in the CRH.
>
>
> What do you think of a HBH Option that displays the ultimate destination.
> This can apply to any routing header compression scheme. It is also
> optional. If you like the idea, I would support a draft.
>
>
>
> No, I suspect a new HBH option for this would be overkill.
>
>
>
> Since this is experiment, how about defining two routing header types for
> CRH where last SID is compressed, and one where it's not. The additional
> processing and implementation complexity for the handling two variants
> shouldn't be very significant, and both could be deployed side-by-side. It
> would allow us to get feedback from real use cases, particularly on rather
> a FIB containing all possible final destinations is scalable.
>
>
>
> Tom
>
>
>
>
>
>
>                                                                         Ron
>
>
>
> Juniper Business Use Only
> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Friday, January 5, 2024 5:56 PM
> To: Jen Linkova <[e-mail]>
> Cc: 6man <[e-mail]>; [e-mail]
> Subject: Re: [IPv6] Working Group Last Call for
> draft-ietf-6man-comp-rtg-hdr
>
> [External Email. Be cautious of content]
>
>
> Hi,
>
> I have a concern with this proposal. As I understand it, the addresses of
> all intermediate destinations and the final destination can only be
> correctly deduced with access to the external state (the CRH-FIB). In
> particular, the final destination address can no longer be deduced by
> simple inspection of the packet contents. I think it may have ramifications
> on debugging and security. I suspect this also would be a concern for SR
> CRH.
>
> This will make much hardware to track and diagnose flows in the network.
> Also, if the destination is obfuscated the TCP and UDP checksum cannot be
> validated in the network (strictly not needed, however it is done when
> debugging corrupted checksums. Even if the diagnostic tools do have access
> to the FIB, it has to be the correct FIB in time. So to do post mortem
> analysis on a flow could only be done if the correct state is accessed for
> when the packet was accessed.
>
> Security may be a problem due to the potential of misdelivery. Correct
> delivery depends on FIB state being correct and synchronized between nodes.
> Presumably, misdelivery would be detected by transport layer checksum with
> pseudo header, however not all protocols have a checksum, and RFC6936
> allows UDPv6 to be sent with a zero checksum in the case of tunnels.
>
> To avoid ambiguity and misinterpretation, I suggest that the final address
> in the SIDs should be sent uncompressed as a plain address or compressed
> using some stateless method. I think this also could reduce the size of the
> FIB table since final destinations are likely to be hosts and there may be
> an order of magnitude more hosts than routers in the network.
>
> Tom
>
> On Thu, Jan 4, 2024 at 1:09 PM Jen Linkova <[e-mail]> wrote:
> >
> > 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-ie
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ie>
> >
> tf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!CWvVGIuSGSWauTRliWk7FJg8VvZNfVPLMcMeOdaUrfqmrfb7flEI0bndmOe3UuwngN0gXiuPTOerJkI$
> ) 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
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6>
> > __;!!NEt6yMaO-gk!CWvVGIuSGSWauTRliWk7FJg8VvZNfVPLMcMeOdaUrfqmrfb7flEI0
> > bndmOe3UuwngN0gXiuPTMIkwPI$
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>