Re: [IPv6] Adoption call for draft-bonica-6man-comp-rtg-hdr

[Tom Herbert <[e-mail]>]

On Sat, Nov 11, 2023 at 1:13 AM Robert Raszuk <[e-mail]> wrote:
>
> Hi Mark,
>
> Since you mentioned IETF and exp status of the RFCs. Just one question ...
>
> This draft clearly defines a solution for source packet routing. There is dedicated WG for that called SPRING with charter which says:
>
> https://datatracker.ietf.org/wg/spring/about/
>
> So shouldn't 6man wait till SPRING WG adopts as at least a WG doc CRH framework or CRH architecture document before it adopts draft-bonica-6man-comp-rtg-hdr with proposed RH extensions ?
>
> Few more points ....
>
> > No overloading of the IPv6 Destination Address field
>
> We have been through this debate too many times. I do not think there is any overloading. Since the early days of IPv6 concept the remaining 64 bits were meant to be used locally as it seems fit the operator. See the draft from Feb 22, 1996: https://datatracker.ietf.org/doc/draft-ietf-ipngwg-unicast-addr-fmt/03/
>
> > No modification of packet analysis tools such as 'tcpdump' and 'wireshark'
>
> I am afraid those tools are meant to accommodate new encoding in the packets. Do not see a problem there. If we would go by this observation we should just delacare networking as completed and close IETF, IEEE, IRTF etc ...

Robert,

I don't understand what you mean here. tcpdump and wireshark are
continually extended to support new protocols, and they are essential
tools in diagnosing problems in networks. I don't think they can be
dismissed so easily. And if they are incapable of decoding SRv6
packets, can you provide a reference to the tools that are able to do
that?

Thanks,
Tom

>
> > Complex equals more things that can break.
>
> True but very subjective.
>
> Cheers,
> Robert
>
>
> On Sat, Nov 11, 2023 at 3:59 AM Mark Smith <[e-mail]> wrote:
>>
>> Hi Robert,
>>
>> On Sat, 11 Nov 2023, 08:32 Robert Raszuk, <[e-mail]> wrote:
>>>
>>> Hi Ron,
>>>
>>> Is there any single technical advantage when comparing functionality of SR with micro-SID to the proposed CRH encoding ? I can't find any in your draft.
>>
>>
>>
>> No overloading of the IPv6 Destination Address field with a sequence of multiple destination identifiers, as micro-SID is doing.
>>
>> No modification of packet analysis tools such as 'tcpdump' and 'wireshark' to decode the overloading that has occurred in the IPv6 DA field.
>>
>> Overloading of existing fields (or variables in programming code) with different semantics, structures and processing adds complexity. Complex equals more things that can break.
>>
>>
>>>
>>> Sure it is fun to experiment and even more fun to demonstrate that something you invented works in practical ways. But is IETF a playground for experimentation or for solving real customer issues in as little as possible ways ?
>>
>>
>> I think your question is directly answered by the existence of the Experimental status of RFCs.
>>
>> The increased operational costs of dealing with the complexity of an overloaded, commonly used field is a real customer issue. The chance of human error goes up. Troubleshooting is harder and takes longer.
>>
>> Regards,
>> Mark.
>>
>>>
>>> Cheers,
>>> Robert
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------