On Sun, 22 Sep 2019 at 23:52, Robert Raszuk <[email protected]> wrote: > > Hey Mark, > > >> >> The entire use of the word "insertion" is incorrect if the ID is now only >> proposing encapsulation/tunnelling to carry transit traffic across the SR >> domain. > > > That is not what the discussed draft says. The draft proposes encapsulation > on ingress edge of the domain, decapsulation on the egress edge of the domain > AND freedom of insertion, deletion (and IMHO also it should also add > modification) of any SRH(s) within the encapsulated header at any point in > the domain. Yes there can be more then one SRH per current notion of the > draft too during the protection. >
Sigh, now you're inserting into the outer IPv6 packet. Still not allowed. I'm getting off of this merry go around. I can't spend any more time on this. This Internet Draft is a denial of service attack on the 6man working group, exhausting resources that could be better spent elsewhere. This ID has been submitted now 7 times, and despite how many times it has been pointed out that EH insertion is prohibited, how RFC 8200 has been specifically updated to be more explicit about it, how many times I and others have pointed out the protocol, practical and operational problems it causes, that is being ignored. I'm not going to point out how CRH/SRv6 complies with RFC 8200. It does, and if you don't understand how, then you'll need to read RFC 8200 more thoroughly. >> The new outgoing segment tunnel header would have the local device as its >> source address, providing attribution. > > > Who told you that ? > > Just please read network programming draft and you see that "swapping" source > address is never the case at segment end points: > > Quote: > > Node 8 originates packets with the received SRH with HMAC TLV. > > P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC) > > Node 5 receives and verifies the HMAC for the SRH, then forwards the > packet to the next segment > > P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC) > > Node 6 receives > > P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC) > > Node 9 receives > > P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC) > > > > Please notice that encapsulated packet by A8 has source address of A8. And > that never changes through the entire domain ! > > > Are you now questioning the entire concept of SRv6 architecture ? > > > Just FYI all documents describing SRv6+ architecture and CRH also do not swap > source address at segment end nodes. > > > Ref draft-bonica-6man-comp-rtg-hdr-07 - Appendix A where src 2001:db8::a > never changes. > > >> This model is entirely compliant with RFC 8200, and as tunnels end points >> are hosts using RFC 8200's definitions, host EHs such as Destination Option, >> or AH and ESP can be used in an RFC 8200 compliant manner. > > > See the issue you are missing is that even if one would follow strictly to > what you are recommending in SRv6 it is still not possible to enable TI-LFA > with SR in the domain as you can not just treat each PLR as Segment End node. > > Of course I guess you can question if TI-LFA with SRv6 is something IPv6 want > to support with SR - but as there is some demand I guess more rationale is > required then just say "No". And of course using SRH is one way to encode TE > topology for TI-LFA. There are other options too, but for now this discussion > is about use of SRv6 technology to achieve that. > > Kind regards, > R. > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
