There were several issues raised. I don't think fragmentation actually came up as one of them, but that is good point. [Uma]: Yes. Intermediate nodes cannot fragment packets in IPv6. …
- The proposal attempted to carve out an exception to RFC8200 for just SR and limited use to controlled domains. That entails many caveats an assumptions that would need to be MUSTs. - Encapsulation is recommended to allow EH insertion and several people asked why not use it. It will work inasmuch as encapsulation within the network already works. - If a host is already using extension headers and the network tries to add more, there is an ambiguity about which ones the.network is responsible for. When packet leaves the domain, the EH that the network added needs to be removed and it needs to be unambiguous which ones are to be removed. - ICMP is a problem. If a host gets an ICMP error that contains extension headers that it did not possibly send then that will be confused. Presumably, ICMP errors will need to be stripped of EH before forwarding to a source node. - PTB is interesting. For instance, EH insertion could force PMTU to drop below 576 minimum. - If the added extension headers are causing packet drops this is a major problem. The intermediate node that is inserting the EHs will never get feedback that its actions are doing harm. An end host might detect packet loss at the transport layer or might get an ICMP error (maybe something like draft-herbert-6man-icmp-limits-02<https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-02>), But, even if it knows that inserted EHs are causing drops, there's is no action a host can take to stop it. At least with encapsulation the tunnel ingress might get and ICMP error about what it's doing. I suppose the primary argument against encapsulation is that it's too much overhead. But, I would point out that in the examples if only one sid is required for mobility (address of destination) in an IP/IP encapsulation this would be the destination of the inner packet and SRH wouldn't be needed. [Uma]: SRH in the proposal not only put a sort of mobility solution (encoded in the SID) but also use to guide the packet through non shortest path from the source as needed and as listed in the SRH. One of the assumption, I saw the discussion here, ILA and 5GIP seems to assume delivering the packet to the shortest path but this may not be necessary the case for lot of 5G slices and also tunneling in couple of cases is unavoidable (if you ought to overlay IPSec in few cases). So encapsulation overhead = 40 bytes, SRH overhead = 20 bytes. I'm not sure that difference justifies the complexity of EH insertion. [Uma]: If you include the above difference is not quite that. But re-encap seems lot safer for some of the points you raised above. -- Uma C.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
