On 22/9/19 16:52, Robert Raszuk 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. > > 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 ?
Curiously enough you seem to be specifying an architecture by breaking that of the protocol it relies on. -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
