Zafar, One of the things I keep seeing below is you referring to the operators perspective. So - as someone who actually is from an operator - and has done substantial testing of the proposed solution let me give you the perspective of an operator.
Firstly - as an operator - on the table mapping - I've seen absolutely no problem with this - particularly if I add bgp crh signaling which lets me build a mapping table that can be understood in multiple systems which do not necessarily need to know about the rest of the network (this is particularly useful on inline DPI systems and other such things) Secondly - as an operator - the segregation between what is an address and how said address is directed - rather than a constant change in the address to us seems far safer. In the uSID draft, a leak of a more specific prefix in the network because of finger trouble - can fundamentally break routing - and well, that could be rather interesting to start debugging. Thirdly - as an operator - without retaining the uncompressed list of SID's in the header, I have a debugging nightmare - and zero ability to figure out packet pathing through the network at intermediary points - and you keep saying that this is addressed by retaining the full SID list - but - if I do that - can you explain to me what the point of the micro sid is - since - I was under the impression that the point was to remove the overhead - the moment I take this approach - how am I not back at square one with the same overhead? Forth - as an operator - I am deeply uncomfortable with the fact that the proposal fundamentally redefines the semantics of the address with potential unintended consequences - and despite the fact that multiple times I have raised the redefinition of the semantics of the address when compared against RFC4291 - I have yet to see this addressed Fifth - as an operator - I have concerns about the inflation of the IGP, and this was raised in Montreal. I was told that this could be addressed by renumbering my network - sorry - I hardly view this as viable Sixth - as an operator that has to apply for space from the RIR's - and has concerns about address space utilization - a request was made in Montreal for an evaluation of actual address space required by this solution - which as of yet has not been forthcoming. However, when looking closely, I'm pretty sure we can figure out how much space this is. To this end, as per Nick Hilliards suggestion, perhaps we should approach the RIR's about allocation policies to seek the viewpoints from them as the allocators of space. I am even willing to take this on, and prepared to put a global policy into the RIR system through all 5 RIR's to change the allocation policies to cater for this once I have a firmer grasp on h ow much address space will be utilized. At that point we can see what the appetite is from that perspective. (In fact some prelim work on such a policy proposal has already begun) Thanks Andrew From: ipv6 <ipv6-boun...@ietf.org> On Behalf Of Zafar Ali (zali) Sent: Friday, 6 September 2019 09:18 To: Ron Bonica <rbon...@juniper.net>; Srihari Sangli <ssan...@juniper.net>; Tarek Saad <tsaad....@gmail.com>; Rob Shakir <ro...@google.com>; SPRING WG List <spring@ietf.org>; 6...@ietf.org Subject: Re: [spring] Beyond SRv6. Hi Ron, Please see in-line. Thanks Regards … Zafar From: Ron Bonica <mailto:rbon...@juniper.net> Date: Friday, September 6, 2019 at 1:57 AM To: "Zafar Ali (zali)" <mailto:z...@cisco.com>, Srihari Sangli <mailto:ssan...@juniper.net>, Tarek Saad <mailto:tsaad....@gmail.com>, Rob Shakir <mailto:ro...@google.com>, SPRING WG List <mailto:spring@ietf.org>, "mailto:6...@ietf.org"; <mailto:6...@ietf.org> Subject: RE: [spring] Beyond SRv6. Inline….. Juniper Business Use Only From: Zafar Ali (zali) <mailto:z...@cisco.com> Sent: Friday, September 6, 2019 1:42 AM To: Srihari Sangli <mailto:ssan...@juniper.net>; Tarek Saad <mailto:tsaad....@gmail.com>; Ron Bonica <mailto:rbon...@juniper.net>; Rob Shakir <mailto:ro...@google.com>; SPRING WG List <mailto:spring@ietf.org>; mailto:6...@ietf.org Cc: Zafar Ali (zali) <mailto: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? [ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029. [ZA] Are you suggesting you will introduce something similar to RFC8029? 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
