Hi Parag, Inline.
Cheers, Pablo. From: spring <[email protected]> on behalf of Parag Kaneriya <[email protected]> Date: Friday, 26 July 2019 at 10:58 To: SPRING WG <[email protected]> Subject: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-00 Hello, I have gone though this draft and below are my thought with respect to CRH comparison given in the draft 1) At ingress node has to more work by gathering individual micro sid . for example Node A configured with micro sid FC00::A000/32 Node B with FC00::B0000/32. Now at ingress node has to concinnated these 2 micro sid into one FC00::A000:B000: followed by of carrier which is 0000 . So this is more complex stuff introduced at ingress while programing path. PC: False. This is control plane work done once. 2) Even shifting of bit are hardware friendly , it is still more work then normal CRH processing where additional CPU cycle to form new Destination by playing with bits and from new destination header. PC: False. Are you kidding? uSID- One IPv6 lookup (ingress), one shift (SID processing), one IPv6 lookup (egress) is much less than: CRH- One IPv6 lookup (ingress), one CRH label lookup in a new database, one IPv6 copy to dest, one IPv6 lookup (egress). That’s 3 lookups. Not to mention all the destination option header parsing before AND after CRH. SRH/uSID processing is already supported in many h/w platforms including merchant silicon. Has CRH and its related DOHs been actually implemented and publicly demonstrated at linerate on h/w ASICs? Regards Parag Juniper Business Use Only
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
