Inline. Thanks, Pablo
From: spring <[email protected]> on behalf of Rajesh M <[email protected]> Date: Wednesday, 24 July 2019 at 13:33 To: SPRING WG <[email protected]> Subject: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-00 Hi, I was looking at < draft-filsfils-spring-net-pgm-extension-srv6-usid-00> and have few comments. 1) As per section 5.2: “(A1::, FC00:0500:0700::)(B:8:D0::; SL=1; NH=4)(X, Y) When 5 receives the packet, 5 matches FC00:0500::/32 in its "My SID Table" and executes the uN behavior “ Here longest prefix match (which is 32 bit) will be done. Once longest prefix match is done we will come to know it’s a uSID. Now on a forwarding packet we are modifying destination address. Which is not a recommended solution. Till now SRV6 only modify locally destined packet. Even security risks will be high, just 32 bit matching is required. PC: The packet is destined to node 5, it receives it, and performs uN resulting in the packet being forwarded to the next segment. This is a basic SRv6 operation. 2) 7 uSID’ per uSID carrier, but in CRH solution where SID is 16 bit (default case) it can support 8 SIDs (16*8). Unable to get why it is better than CRH ? PC: I’d suggest you re-do the maths considering the entire header stack that is required in both cases. Thanks Rajesh Juniper Business Use Only
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
