It makes sense of using source routing across the Internet. For example, using source routing for traffic steering across edge networks just like Akamai's SureRoute which is a limited domain over the Internet indeed. In that case, it's necessary to protect the source route information carried within packets by some means (e.g., indirection), in other words, it'd better not to directly carry the source routes in the form of an IP address list within the source routed packets. BTW, it may be worthwhile to consider the scenario where the source routed packets need to traverse both IPv4 and IPv6 Internet along the path towards their final destinations.
Of course, whether using CRH or RFC8663 is purely a matter of personal preference from my point of view, just like someone prefers to use VXLAN rather than MPLS-over-UDP (http://tools.ietf.org/html/rfc7510) for network virtualization, and someone prefers to use EVPN rather than Virtual Subnet (https://tools.ietf.org/html/rfc7814) which is fully built on the mature MPLS/BGP L3VPN (https://tools.ietf.org/html/rfc4364) for pure Layer3-based overlays. Best regards, Xiaohu ------------------------------------------------------------------ From:Robert Raszuk <[email protected]> Send Time:2020年5月28日(星期四) 06:40 To:Zafar Ali (zali) <[email protected]> Cc:Ron Bonica <[email protected]>; [email protected] <[email protected]>; 6man <[email protected]>; Brian E Carpenter <[email protected]>; Andrew Alston <[email protected]> Subject:[spring] Limited domains ... /*adjusting subject */ > The scope of CRH is “limited domain” and not the “Internet”. Well that is only what the document under adoption call says. However we have all seen described use cases over Internet ... so much of limited domain. Explanation given is that "limited domain" does not to be continuous ... very clever indeed ! I am observing this point as my use case is also over Internet. So if I apply any RH on my application host_1 carry it over Internet to my server host_2 clearly those two hosts create a "limited domain". Maybe we should just drop right here this "limited domain" restriction/scope for any solution being discussed here ? Thx, R. On Thu, May 28, 2020 at 12:32 AM Zafar Ali (zali) <[email protected]> wrote: Hi, The authors of CRH has already have multiple drafts and more CP/ DP changes will be required. E.g., it will require ISIS changes (draft-bonica-lsr-crh-isis-extensions) To carry VPN information (draft-bonica-6man-vpn-dest-opt) For SFC (draft-bonica-6man-seg-end-opt) BGP changes (draft-alston-spring-crh-bgp-signalling, draft-ssangli-idr-bgp-vpn-srv6-plus) PCEP extension (TBA) OAM for debugging the mapping table Yang interface More to come The scope of CRH is “limited domain” and not the “Internet”. Given this, where the IETF community discuss how these so-called “building blocks” fits together? If author’s claim is that the home for the architecture work is not Spring, then the authors should create a BoF in routing area to first defined architecture, use-case and requirements. This is the hard worked everyone else did before the CRH authors. Why they are looking for a short cut? CRH is a “major” change and outside the scope of 6man charter. It should follow the proper IETF review process. Why CRH authors are trying to “skip the queue” and “skip the routing area”? Thanks Regards … Zafar
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
