Zafar,
Many of the drafts that you list below are unrelated to the CRH (e.g.,
draft-bonica-6man-vpn-dest-opt). Many do not exist and are not required (e.g.,
OAM for debugging the mapping table).
Try to understand that the CRH is a building block that can be deployed in many
scenarios. It is not a grand architecture.
Ron
Juniper Business Use Only
From: Zafar Ali (zali) <[email protected]>
Sent: Wednesday, May 27, 2020 6:32 PM
To: Brian E Carpenter <[email protected]>; Robert Raszuk
<[email protected]>; [email protected]
<[email protected]>
Cc: Ron Bonica <[email protected]>; [email protected]; 6man <[email protected]>;
Zafar Ali (zali) <[email protected]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring]
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
[External Email. Be cautious of content]
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
From: ipv6 <[email protected]<mailto:[email protected]>> on behalf of
Brian E Carpenter
<[email protected]<mailto:[email protected]>>
Date: Wednesday, May 27, 2020 at 6:09 PM
To: Robert Raszuk <[email protected]<mailto:[email protected]>>, Andrew Alston
<[email protected]<mailto:[email protected]>>
Cc: Ron Bonica
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>, 6man
<[email protected]<mailto:[email protected]>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring]
CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
On 28-May-20 09:50, Robert Raszuk wrote:
Andrew,
I don't think this is about killing innovation. After all no one is saying you
can not use it in your network.
WG acceptance calls
Adoption is not acceptance. At least half the messages on this topic are
written as if we were in the middle of a WG Last Call.
are evaluated in terms of WG rough consensu if significant number of members of
WG find a proposal useful and if they are willing to work on it.
Indeed. Exactly. Not in the least about consensus that the proposal is ready
for approval. Just that it is ready for discussion and, as you say, that there
are people willing to work on it.
It seems clear that other then one vendor and very few individuals majority of
the WG members do not support the adoption.
That's for the WG Chairs to evaluate, and I expect them to evaluate singing in
chorus appropriately. Also, and this is not a grammatical quibble, we don't
have "members". We have participants, and we don't count votes.
I am not against CRH. But what I am against is that CRH/SRm6 authors already
bounced back via SPRING doors so they have chosen to try to enter via 6man
window. That is not proper style for any proposal.
I agree that CRH is not in scope of the SPRING charter as it stands today ("the
home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6)"). But let me
say again that we should hear the opinion of the routing ADs.
Regards
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]<mailto:[email protected]>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X9nnCHwtlMnfPJCt-JAQWt_RZK_9HziPYxC-DEez6J3r6JBFErtYntrfAskH9yNv$>
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
