Inline.....
Juniper Business Use Only From: Zafar Ali (zali) <[email protected]> Sent: Friday, September 6, 2019 1:42 AM To: Srihari Sangli <[email protected]>; Tarek Saad <[email protected]>; Ron Bonica <[email protected]>; Rob Shakir <[email protected]>; SPRING WG List <[email protected]>; [email protected] Cc: Zafar Ali (zali) <[email protected]> Subject: Re: [spring] Beyond SRv6. <snip> Hi Srihari, > DA manipulation along the hop (shifting as the draft proposes) on each router > and reconstructing the DA - can make it harder to debug when > there is problem. It has been clarified during the Spring WG session in Montreal. Repeating the same - * The original segment list is maintained by using the non-Reduced flavor (in which case the SID list is fully preserved in the SRH). [RB] At the cost of encoding efficiency. 50% decrease !! In reality, debugability is a huge issue in CRH proposal. [RB] In reality, the debuggability characteristics of SRv6+ are very similar to those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID or SR-MPLS Label) to an IPv6 address. [RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS? Ron For example, the CRH requires an IPv6 address to the "labels" mapping table (Yuck!). An operator cannot determine the path packet will take by looking at CRH. Have you realized how painful it will be for the operator to: * Walk the CRH, * Map each per-node "local labels" to its associated IPv6 address, * Repeat the process for the entire label chain encoded in CRH. Not to mention, this requires the operators to get the "mapping table" from each node in the network. Thanks Regards ... Zafar <snip>
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
