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

[Mark Smith <[e-mail]>]

On Sat, 11 Nov 2023, 20:12 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
> ...
>

Nice selective quoting of my position to suit your argument.

Here's what I said in full again. Care to try to properly respond?

"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."



> > 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
>>> --------------------------------------------------------------------
>>>
>>