Re: New Version Notification for draft-voyer-6man-extension-header-insertion-07.txt

[Mark Smith <[e-mail]>]

On Sun, 22 Sep 2019 at 23:52, Robert Raszuk <[e-mail]> 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.
>