Re: [spring] Limited domains ...

On Thu, 28 May 2020, 08:40 Robert Raszuk, <robert@raszuk.net> 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) <zali@cisco.com> 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>