On Thu, 28 May 2020, 08:40 Robert Raszuk, <[email protected]> wrote: > /*adjusting subject */ > > > The scope of CRH is “limited domain” and not the “Internet”. >
The scope of SR-MPLS is also "limited domain", because, quite obviously, after 20 years, MPLS isn't yet end-to-end across the Internet, never was designed to be and never will be. So SPRING need to declare SR-MPLS deprecated first before the "limited domain" argument can be attempted to be used against CRH. > 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 >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
