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

[Robert Raszuk <[e-mail]>]

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

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