Inline.....
Juniper Business Use Only
From: Zafar Ali (zali) <z...@cisco.com>
Sent: Friday, September 6, 2019 1:42 AM
To: Srihari Sangli <ssan...@juniper.net>; Tarek Saad <tsaad....@gmail.com>; Ron
Bonica <rbon...@juniper.net>; Rob Shakir <ro...@google.com>; SPRING WG List
<spring@ietf.org>; 6...@ietf.org
Cc: Zafar Ali (zali) <z...@cisco.com>
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
