Ketan, I am trying to figure out which documents you think were adopted
and approved elsewhere to drive the 6man work on SRH.
I did find RFC 8354, which was a use case. It is not a problem
statement. It is most definitely not an architecture. The only
architecture documents I can find are general SR documents. Those did
not justify a need for SRH. And I (at least) did not object to SRH on
the basis of that gap.
Yes, SRH normatively references 8402. But 8402 does not drive any need
for SRH. In fact, the actual text references to SRH are fairly cursory.
(The most significant is some terminology.)
In fact, as far as I can tell, the ties are such that there is no
evidence in the documents that SPRING had any say in SRH. (the reality
is more complex, I grant you. But there was no formal approval or signoff.)
As far as I can tell, there was no formal approval of anything by SPRING
that can be read as a request to 6man to work on SRH. (Do remember that
the SRH document was adopted by 6man in December of 2015.) The network
programming draft did not even appear at 00 until March of 2017, 15
months later.
How, given this history, can you claim that CRH needs something more.
We have operators asking for this.
Yours,
Joel
On 5/21/2020 11:53 PM, Ketan Talaulikar (ketant) wrote:
Hi Bob,
Perhaps I will try to make my case to you (and everyone else here) … one
last time.
This is how I've seen RH work being done in 6man until now (in a matter
that fits its charter).
1) There is a WG (not 6man) that defines the problem statement,
use-cases and architecture that requires RH
2) The 6man being the experts on IPv6 design, either take up the
document that specifies that RH (or even if it is done in another WG,
reviews it).
So 6man has always had work done in (1) to reference and lean upon when
doing (2).
My argument of the shortcut in the case of this specific adoption is
that we don't have (1).
It is not in 6man charter nor expertise to take up (1) because CRH is
not purely IPv6 work. It is not meant for "Internet" but a specific
"limited domain". The SIDs that it introduces is a new "mapping ID"
concept. It is not an IPv6 address and neither it is MPLS. This is a
*_Routing_* Header and part of a new Source *_Routing_* solution.
Therefore, without (1) being made available to 6man, I believe that
working on (2) in 6man is to me a shortcutting of the IETF technical
review process (specifically of the *_Routing_* area in this case) for a
solution and does not provide the necessary reference for 6man to work on.
Why the rush?
I close my arguments.
Thanks,
Ketan
-----Original Message-----
From: Bob Hinden <bob.hin...@gmail.com>
Sent: 22 May 2020 09:03
To: Ketan Talaulikar (ketant) <ket...@cisco.com>
Cc: Bob Hinden <bob.hin...@gmail.com>; Brian Carpenter
<brian.e.carpen...@gmail.com>; Ron Bonica <rbon...@juniper.net>; Chengli
(Cheng Li) <c...@huawei.com>; Zafar Ali (zali) <z...@cisco.com>; Robert
Raszuk <rob...@raszuk.net>; spring@ietf.org; 6man <6...@ietf.org>
Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of
CR in CRH
Ketan,
> On May 21, 2020, at 8:12 PM, Ketan Talaulikar (ketant)
<ketant=40cisco....@dmarc.ietf.org
<mailto:ketant=40cisco....@dmarc.ietf.org>> wrote:
>
> Hi Brian,
>
> Please see my previous response to your comments.
>
> My argument is not legalistic. I am not as experience in IETF work as
you and Bob are. But what I understand is that the reason why we have
these "legal" process of charters and BoF is to enable a proper
technical discussion with the right context and details of the proposal
presented for review of the community.
>
> I do not see how shortcutting them helps anyone and I wonder why it
is being done in this case?
There is no short cutting here. The adoption call is to determine if
there is interest in the w.g. to take this work into 6man. If it
becomes a w.g. draft, then the w.g. is responsible to decide what
happens next.
It’s a first step, it is not a decision to publish it.
Bob (w/ w.g. chair hat on)
>
> Thanks,
> Ketan
>
> -----Original Message-----
> From: Brian E Carpenter <brian.e.carpen...@gmail.com
<mailto:brian.e.carpen...@gmail.com>>
> Sent: 22 May 2020 04:18
> To: Ketan Talaulikar (ketant) <ket...@cisco.com
<mailto:ket...@cisco.com>>; Ron Bonica <rbon...@juniper.net
<mailto:rbon...@juniper.net>>; Chengli (Cheng Li) <c...@huawei.com
<mailto:c...@huawei.com>>; Zafar Ali (zali) <z...@cisco.com
<mailto:z...@cisco.com>>; Robert Raszuk <rob...@raszuk.net
<mailto:rob...@raszuk.net>>
> Cc: spring@ietf.org <mailto:spring@ietf.org>; 6man <6...@ietf.org
<mailto:6...@ietf.org>>
> Subject: Re: CRH is back to the SPRING Use-Case - Re: Size of CR in CRH
>
> On 22-May-20 05:26, Ketan Talaulikar (ketant) wrote:
> ...> It is the 6man charter that precludes it from defining a new
Source Routing solution..
>> “It is not chartered to develop major changes or additions to the
IPv6 specifications.”
>
> If this addition was major, that would be true. But adding a new RH
type is well within the scope of maintenance, IMHO. We have already done
it quite recently.
>
> In any case, legalistic arguments about WG charters are really not
how we should take technical decisions.
>
> Regards
> Brian
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org <mailto:spring@ietf.org>
> https://www.ietf.org/mailman/listinfo/spring
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
