Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt - END.T

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 29 September 2020 16:11 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A643A0EEB for <lsr@ietfa.amsl.com>; Tue, 29 Sep 2020 09:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-7iqPs0jgco for <lsr@ietfa.amsl.com>; Tue, 29 Sep 2020 09:11:12 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928623A0EE1 for <lsr@ietf.org>; Tue, 29 Sep 2020 09:11:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4C14BS2YYsz1ny8L; Tue, 29 Sep 2020 09:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1601395872; bh=dJEvlPIYm8Q+9Z42Uz77WLRed0hP5mrIcKia4rcXk88=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iocCe1Ozs/0u0nJx3hscCLQKnJCUMFLLbSuO8YQfRwuowsqFBeNVRdIoREWd7gr0j xCJBHQkfLq/oUILkKMP6FCO6r/PgvSVqUShfPKogUJ9AXzKKk9kFsNJ70LXz9igQ0H No+/TSQFMOufcWHJgh14GstvbFHvbzZ0jyJ/dZyo=
X-Quarantine-ID: <c5ZRKixyN6Pa>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4C14BR4yLsz1ntm0; Tue, 29 Sep 2020 09:11:11 -0700 (PDT)
To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
References: <160089362905.18505.1337918393869303045@ietfa.amsl.com> <97d0c988-d984-489c-8f48-907647ee1204@joelhalpern.com> <4084D1D0-03E8-453C-AE3C-911016101E6D@cisco.com> <4db2073b-fa38-a30c-ccdf-4d00f435522c@joelhalpern.com> <MW3PR11MB4570A24D30A4E07C499BF773C1360@MW3PR11MB4570.namprd11.prod.outlook.com> <0c12484e-31fc-dc00-4494-c1ce1d9f65bb@joelhalpern.com> <MW3PR11MB4570F2FB09ED768914A08D5AC1350@MW3PR11MB4570.namprd11.prod.outlook.com> <22812c1a-5283-b764-773d-da8e12aab2f5@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <22d94283-68df-9864-cee2-a1dd063d2295@joelhalpern.com>
Date: Tue, 29 Sep 2020 12:11:09 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <22812c1a-5283-b764-773d-da8e12aab2f5@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/nKJbY5f6SHEwVCqqfoXSPidGKXQ>
Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt - END.T
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 16:11:15 -0000

Thanks for the clarifications to Peter and Ketan.  (I now understand 
what I missed about the control for END.DT2M.)

It seems that as currently laid out, the document appears to define the 
encoding for END.T, but does not provide enough information to use it?

Which suggests that we should either improve it or remove it.
The inclusion of END.T in the network programming draft means that 
removing it will leave a gap with us standardizing the meaning of END.T 
but not the control to communicate it.  That seems better than a partial 
definition of how to communicate it.

Yours,
Joel

On 9/29/2020 4:39 AM, Peter Psenak wrote:
> Joel, Ketan,
> 
> On 28/09/2020 15:25, Ketan Talaulikar (ketant) wrote:
>> Hi Joel,
>>
>> Please check inline below.
>>
>> -----Original Message-----
>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Joel M. Halpern
>> Sent: 25 September 2020 19:08
>> To: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>rg>; 
>> lsr@ietf.org
>> Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-isis-srv6-extensions-10.txt
>>
>> Thanks Ketan.  Let me paraphrase to confirm I understand, with some 
>> suggestions.  And repeat the last question which seems to have gotten 
>> lost.
>>
>> It seems that you are saying that the arg field is defined for now so 
>> the format is consistent, but is not used by any behavior defined in 
>> this draft.
>> [KT] The ISIS draft does not actually define any behavior - it only 
>> specifies signaling of a subset of behaviors defined in net-pgm. You 
>> are right that the behaviors that are listed as being signalled by 
>> ISIS in the current document do not support an ARG.
> 
> ARG is part of the SID. The fact that it is not used currently by any 
> SID that is defined for ISIS, does not mean the ARG part of the SID does 
> not exists. We advertise the SID as 128 bits in ISIS, so we ARG is part 
> of it.
> 
>>
>> If so, should we say explicitly that ARG is (or MUST be) 0 for all the 
>> behaviors defined in this draft?
>> [KT] I am not sure it is necessary. A future ISIS extension may 
>> introduce support for signaling of a behavior that supports ARG.
> 
> draft-ietf-spring-srv6-network-programming only defines ARG for END.DT2M.
> 
> We can certainly say in ISIS draft that for the SIDs defined in it, 
> there are no ARGs.
> 
>>
>> Then separately the folks working on the END.DT2M behavior can write 
>> their own draft one how to advertise that in is-is?  Presumably with 
>> an additional sub-TLV dealing with k and x?
>> [KT] End.DT2M is signaled in BGP and specified in BGP extensions. If a 
>> future ISIS extension was to advertise a SID with a behavior 
>> supporting ARG, then it would need to clarify its handling of the ARG.
>>
>> Also, can you tell me how the association of an END.T behavior with a 
>> table is understood from the advertisement as described in the draft?
>> [KT] Indeed, the End.T signaling does not carry the table context with 
>> it.
> 
> I would tend to remove the END.T from the ISIS draft. If we need it, we 
> could define it in a separate document.
> 
> thanks,
> Peter
> 
>>
>> Thanks,
>> Ketan
>>
>> Thank you,
>> Joel
>>
>> On 9/25/2020 1:39 AM, Ketan Talaulikar (ketant) wrote:
>>> Hi Joel,
>>>
>>> Please check inline below.
>>>
>>> -----Original Message-----
>>> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Joel M. Halpern
>>> Sent: 25 September 2020 03:18
>>> To: Acee Lindem (acee) <acee@cisco.com>om>; lsr@ietf.org
>>> Subject: Re: [Lsr] I-D Action:
>>> draft-ietf-lsr-isis-srv6-extensions-10.txt
>>>
>>> First, there is a slight confusion in the way I formed the quesiton, 
>>> but I think it still applies.
>>>
>>> The piece of this draft is section 9, which advertises the length of 
>>> the arg portion of the SID.  But does not provide specific meanings 
>>> for specific values.
>>> [KT] This is quite appropriate for this draft since it is only 
>>> specifying a generic SID structure and not associated with any 
>>> specific behavior.
>>>
>>> The example of an ARG in the network programming draft does provide 
>>> part of the explicit interpretation of the ARG.  It says that it is a 
>>> list of k items, each of x bits, where each x bit blob identifies an 
>>> OIF.
>>> [KT] The net-pgm draft in sec 4.12 introduces a specific End.DT2M 
>>> behavior which includes support for ARG. That said, I am not quite 
>>> sure about that text in that section which talks about how the ARG 
>>> bits are formed and what they signify. I believe the ARG in this case 
>>> is a locally assigned identifier that maps to an ESI so that it can 
>>> be used for ESI filtering - much the same as an ESI label for 
>>> split-horizon filtering. I see a comment from one of the ADs on this 
>>> and I expect that the authors will clarify.
>>>
>>> This leaves two gaps, and a more general question.
>>> 1) How does the receiver know the meanings of the OIF indices so that 
>>> he can correctly fill them in?
>>> 2) The NP draft says that k and x are defined on a per SID basis.  
>>> But I do not see anywhere in the isis draft to advertise the values 
>>> of k and x, only arg (which is k*x).
>>> [KT] I hope the previous comment explains.
>>>
>>> The more general question is, is there a requirement we can write 
>>> down about how receivers will be able to understand ARG fields in 
>>> general?
>>> One can argue that it would belong in the network programming draft; 
>>> I would prefer not to delay that with a significant technical addition.
>>> [KT] I don't believe the handling of ARG is something that can be 
>>> generalized. It has to be something specific to the behavior that it 
>>> is associated with. Therefore, each behavior that supports an ARG 
>>> needs to specify its handling. The net-pgm draft is doing it for 
>>> End.DT2M and future documents that introduce other behaviors 
>>> requiring ARG would be expected to the same.
>>>
>>> Thanks,
>>> Ketan
>>>
>>> There is a related question that I came across while trying to 
>>> explain this question.
>>>
>>> END.T must be associated with a forwarding table.  I presume this is 
>>> done by where one puts the END.T (however-many-subs) TLV.  But I can 
>>> not find anything in this draft that says this.  There is precisely 
>>> one reference to End.T in the draft.
>>>
>>> Thank you,
>>> Joel
>>>
>>> On 9/24/2020 5:25 PM, Acee Lindem (acee) wrote:
>>>> H Joel,
>>>>
>>>> Can you reference the specific section in the IS-IS SRv6 draft you 
>>>> are commenting on? I seem to remember this discussion but it was at 
>>>> least a month back, if not more.
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>> On 9/23/20, 6:31 PM, "Lsr on behalf of Joel Halpern" 
>>>> <lsr-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:
>>>>
>>>>        The announcement prompted me to look again and think about an
>>>>        interaction between this and the network programming draft.  
>>>> To be
>>>>        clear, I am NOT objecting to either this or the network 
>>>> programming
>>>>        draft.  I am just wondering what I am missing.
>>>>
>>>>        The NP draft, and the advertisement mechanism allows a router to
>>>>        advertise the number of bits for the ARG portion of a SID.
>>>>
>>>>        Q1: The point presumably is to avoid needing to advertise 
>>>> each of the
>>>>        individual values?
>>>>
>>>>        An example of this is, I think, and ARG for the table 
>>>> selection where
>>>>        the ARG is the table number for the packet to be looked up in?
>>>>
>>>>        Q2: If so, how does the head end know what table number 
>>>> corresponds to
>>>>        what meaning?    If this requires a separate advertisement 
>>>> there seems
>>>>        to be no savings.  if this requires out-of-band knowledge 
>>>> then we seem
>>>>        to have lost the benefit of advertising all of this in the 
>>>> routing protocol.
>>>>
>>>>        I suspect I am simply missing a piece.  can someone explain 
>>>> please?
>>>>
>>>>        Thank you,
>>>>        Joel
>>>>
>>>>        On 9/23/2020 4:40 PM, internet-drafts@ietf.org wrote:
>>>>        >
>>>>        > A New Internet-Draft is available from the on-line 
>>>> Internet-Drafts directories.
>>>>        > This draft is a work item of the Link State Routing WG of 
>>>> the IETF.
>>>>        >
>>>>        >          Title           : IS-IS Extension to Support 
>>>> Segment Routing over IPv6 Dataplane
>>>>        >          Authors         : Peter Psenak
>>>>        >                            Clarence Filsfils
>>>>        >                            Ahmed Bashandy
>>>>        >                            Bruno Decraene
>>>>        >                            Zhibo Hu
>>>>        >     Filename        : 
>>>> draft-ietf-lsr-isis-srv6-extensions-10.txt
>>>>        >     Pages           : 25
>>>>        >     Date            : 2020-09-23
>>>>        >
>>>>        > Abstract:
>>>>        >     Segment Routing (SR) allows for a flexible definition 
>>>> of end-to-end
>>>>        >     paths by encoding paths as sequences of topological 
>>>> sub-paths, called
>>>>        >     "segments".  Segment routing architecture can be 
>>>> implemented over an
>>>>        >     MPLS data plane as well as an IPv6 data plane.  This 
>>>> draft describes
>>>>        >     the IS-IS extensions required to support Segment 
>>>> Routing over an IPv6
>>>>        >     data plane.
>>>>        >
>>>>        >
>>>>
>>>>        _______________________________________________
>>>>        Lsr mailing list
>>>>        Lsr@ietf.org
>>>>        https://www.ietf.org/mailman/listinfo/lsr
>>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>> _______________________________________________
>>> Lsr mailing list
>>> Lsr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>>
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr