Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

[Giuseppe Fioccola <[e-mail]>]

Hi John, Sue, Ketan, All,
I can confirm what Ketan just said. The IFIT solution is made by several building blocks and this document (draft-qin-idr-sr-policy-ifit) is one of these. When we have defined the IOAM and Alt-Mark methodologies, we did not have the signaling. Now we are defining the signaling and the next step is the middle part.
We agree with Ketan to work on a new SPRING document that describes the SRPM operations and procedures for IFIT (IOAM and Alt-Mark). Anyway no additional changes are needed for draft-qin-idr-sr-policy-ifit so far. We could simply state in the next revision that the SRPM details are described in another document and we will add the reference as soon as it is published.

Meanwhile we believe that this draft, as one building block, is quite stable and can be adopted since it complements draft-ietf-idr-segment-routing-te-policy.

Regards,

Giuseppe


-----Original Message-----
From: Idr [mailto:[e-mail]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, November 19, 2020 8:21 AM
To: Joel M. Halpern <[e-mail]>; John Scudder <jgs=[e-mail]>; Hares Susan <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

And I would like to clarify that my comments were not a "No" to the adoption.

It is very difficult (at least for me) to see how the proponents of IFIT solution see it progressing as an IETF standard if they are only trying to standardize the signalling protocol encoding parts and leave out the "middle part (i.e. SRPM related)" as a black box. For me at least, that is the crux - the BGP encoding part is just opaque bits that BGP is doing almost nothing with!

That was essentially my suggestion to Giuseppe - for the authors to work that "middle part" out (I would have preferred doing that first but ...). I thought that Giuseppe got my point and agreed to it - but I will let him confirm/clarify.

Of course, what looks like a black box to me might not be so and I am happy to be pointed to a document that describes these "SRPM related parts".

About the "uncoordinated" part, I've left it to the chairs - if they have any preference for the order in which different parts of this work are taken up in different WGs.

Thanks,
Ketan

-----Original Message-----
From: Idr <[e-mail]> On Behalf Of Joel M. Halpern
Sent: 19 November 2020 12:35
To: John Scudder <jgs=[e-mail]>; Hares Susan <[e-mail]>
Cc: [e-mail]
Subject: Re: [Idr] IPR Call and WG Adoption for draft-qin-idr-sr-policy-ifit-04.txt (11/1/2020 to 11/16/2020)

Yes, I have cleared my objection.
Yours,
Joel

On 11/19/2020 1:53 AM, John Scudder wrote:
> Hi Sue,
> 
> Here’s my tally on this one:
> 
> Yes (but co-authors):
> - Giuseppe F
> - Yali
> - Fengwei
> - Tianran
> 
> Yes:
> - Peng Liu
> - Yisong
> - Huzhibo
> - Chen Huan
> - Shuanglong
> - Fabio B
> - Massimo N
> - Jie
> - Mauro C
> - Weiqiang
> - Ran Pang
> - Huaimo
> - Mach
> - Dhruv
> - Chengli
> 
> No:
> - Ketan — interaction with SR policy module isn’t clear, "might seem 
> like an uncoordinated protocol development effort”. (Not explicitly ’no’
> but I read it that way for now.)
> - Zafar — "It is better to have a framework draft to reach maturity
> (adoption) first.”
> 
> Comments/questions:
> - Joel H — frame behavior not adopted by relevant WGs, therefore 
> premature to adopt?
> 
> Some of the concerns raised are potentially serious. I think we can 
> call Zafar “in the rough”. I’m not sure if Ketan and Giuseppe fully 
> converged during the WG meeting — do you have a sense of this? And I 
> think Joel cleared his concern later. So Ketan’s is the only concern I 
> think is still outstanding, but I’d like to be clearer on it before proceeding.
> 
> —John
> 
>> On Nov 2, 2020, at 12:56 AM, Susan Hares <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>> [External Email. Be cautious of content]
>>
>>
>> This begins a 2 week WG adoption call for 
>> draft-qin-idr-sr-policy-ifit-04.txt (11/2/2020 to 11/16/2020).
>> The draft can be accessed at:
>> https://datatracker.ietf.org/doc/draft-zhu-idr-bgp-ls-path-mtu/
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-z
>> hu-idr-bgp-ls-path-mtu/__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQ
>> lCdbDTqTHwgxWJUCrM2yIeftGvCmylR-A$>
>> The authors should provide IPR statements by 11/5/2020 so the IDR WG 
>> can consider the IPR status in their decision.
>> This draft adds the IFIT sub-TLV to the BGP Tunnel Encaps attribute 
>> for the SR policy tunnel type. This sub-TLV is only valid for SR 
>> Policy tunnel types.  Within the IFIT  sub-TLV value field, 5 
>> sub-TLVs may be included (4 for IOAM and 1 for Enhanced Alternate Marking).
>> The IDR co-chairs thank the authors for their patience.  The WG 
>> adoption call for this draft has been delayed by the process of 
>> switching shepherds for BGP Tunnel Encaps draft.  Many BESS and IDR 
>> drafts currently refer to the BGP tunnel encapsulation drafts.
>> In your review of this draft, please differentiate between the following:
>> ·Support/rejection of In-situ Flow Telemetry (IFIT) as a IP routing 
>> technology, ·Support/rejection of alternate marking as a IP routing 
>> technology, ·Support/rejection of adding new sub-TLVS for SR Policy 
>> tunnel type of BGP Tunnel Encap Attribute, and ·Specific issues with 
>> the descriptions of these features in the draft.
>> Cheers, Susan Hares
>> _______________________________________________
>> Idr mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr
>> __;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIef
>> tGv96xWXpg$
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/id
>> r__;!!NEt6yMaO-gk!S2_evVk0qH-qYiwpJrdQMKbVgbTIQlCdbDTqTHwgxWJUCrM2yIe
>> ftGv96xWXpg$>
> 
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr