[arch-d] Fwd: Use/Modification/Extensibility and Reinvention (Re: some feedback on feedback on draft-bonica-6man-ext-hdr-update-03)

[Fernando Gont <[e-mail]>]

Heads up. This might be of interest to this group.

Thanks,
Fernando




-------- Forwarded Message --------
Subject: 	Use/Modification/Extensibility and Reinvention (Re: some 
feedback on feedback on draft-bonica-6man-ext-hdr-update-03)
Date: 	Sat, 9 May 2020 11:22:12 +1000
From: 	Mark Smith <[e-mail]>
To: 	Robert Raszuk <[e-mail]>
CC: 	6man WG <[e-mail]>





On Sat, 9 May 2020, 10:05 Robert Raszuk, <[e-mail] 
<mailto:[e-mail]>> wrote:

         Any working group other than 6man will now be able to take IPv6 and
         modify it to suit what they want to do, ignoring the specs and the
         6man WG's intent, using PSP and what SPRING has been allowed to
         do to
         justify it.


     And that to me sounds like a feature.

     The best protocols are those which are used way beyond their
     original author's intentions.


Modifying something is not using it.

I have modified blade screw drivers to suit are special purpose. They're 
not blade screwdrivers anymore (they're bicycle wheel spoke nipple 
drivers), and cannot be used as blade screwdrivers.

Modifying IPv6 is not using IPv6.

     Experience shows that we as humans are pretty bad in predicting the
     future so all we can is do to define things in an extensible style
     such that others may ride on it.


Extensibility is being able to add to something that already exists 
without interfering with the existing thing's operation. Modifying 
something that already exists and has fixed definitions, changing its 
behaviour, is not extensibility.

There are areas where IPv6 is extensible, such as via the creation of 
new EHs, and other areas where it is not.

     If they would be denied to modify it and use it as it seems fit to
     realize their ideas - they would need to reinvent the wheel - not
     the best use of time.



I don't think SPRING have tried that hard to follow this principle, 
because there are a number of examples where existing and proven 
mechanisms that work could have been used; instead reinvention occurred.

uSID is trying to reinvent the purpose of the IPv6 Destination Address 
field, by encoding a set of multiple packet destinations in that field, 
despite the word "Address" being singular in RFC 8200.

SRv6 Network Programming needs to reinvent IPv6 DA matching at the 
destination in 3. SRv6 SID because it doesn't assign SIDs (that have 
become IPv6 addresses) to interfaces, contrary to the RFC 4291 
addressing architecture, which dictates that IPv6 addresses are assigned 
to interfaces not nodes.

SPRING tried to reinvent the meaning of the No Next Header EH (type 59) 
to implicitly mean an Ethernet payload followed.

SPRING needed to reinvent AH via the SRH HMAC TLV, because the 
operations being performed on IPv6 packets weren't compliant with 
RFC8200, and therefore AH couldn't be used..

There may be a 5th example I can't quite remember right now.


It has seemed to me that SPRING have had too much of a "greenfield" 
mentality, allowing other existing specs to be taken and casually 
modified, rather than proposing modifications only as a last resort, 
when there is no other way to make the function work within existing 
proven mechanisms.

In all these cases changing SR methods to fit within the existing would 
have been far less time and effort than the reinvention that has 
occurred or was proposed.

Regards,
Mark.