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

[Robert Raszuk <[e-mail]>]

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.

 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.