IETF Logo Mail Archive

Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10

Peter Psenak <ppsenak@cisco.com> Tue, 24 March 2020 10:44 UTC

Return-Path: <ppsenak@cisco.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 B868E3A0BDF; Tue, 24 Mar 2020 03:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5CabTP1P3D4P; Tue, 24 Mar 2020 03:44:54 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8693A0898; Tue, 24 Mar 2020 03:44:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2283; q=dns/txt; s=iport; t=1585046692; x=1586256292; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=CmpQy+PZ4iZjDWbM4znGTXzM96ePjiKPplo4Oz8DF2M=; b=FCn256I1J1SmULF6lWv86Vtzv8XskWqAtIDrgBwqhgJD18/F7Se1lvoE hmxyx7YAiv5R8kvfXRvTH8JbaHmTCGTPlW91o4++/nhZzKfktGXm0fU7R vJSmsKnmiUckSJEW8f6gzOQnRw0cKgo3U9Q5L3RII1dKLwuURoJ/+iRhB o=;
X-IronPort-AV: E=Sophos;i="5.72,300,1580774400"; d="scan'208";a="22390645"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2020 10:44:49 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 02OAimxd026291; Tue, 24 Mar 2020 10:44:49 GMT
To: Alvaro Retana <aretana.ietf@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-isis-mpls-elc@ietf.org" <draft-ietf-isis-mpls-elc@ietf.org>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>
References: <CAMMESsyMkZgpU69GyL8TpwPS7EoO2rxTHWREOwEz7pNRFtNEJw@mail.gmail.com> <6bd667d8-6957-894e-f11e-aa727065190c@cisco.com> <CAMMESsxwbv3aUvg_gR+Ssny=YkW3D2_6tVgDpJx9BGH_Mrdh=A@mail.gmail.com> <0d9b6c73-d309-d2ee-15e0-722df9c32629@cisco.com> <CAMMESsxy7KyCMdAFX2iRHYy78qvQ4eoXLxCRmNj1PGNdOO=QDg@mail.gmail.com> <ff3ae6d5-3bfe-d3c9-ff63-725da0d09e62@cisco.com> <CAMMESszNuZ505G_4o-z-A9ts9SR5tV+9xxDORzUPbSQiPdMcag@mail.gmail.com> <d9972943-7de7-c25d-6e2c-5a4eee77756a@cisco.com> <53F0A553-4075-40A1-A262-47E7EB72E887@cisco.com> <CAMMESswZz7REaNFQhRbPxu8eO89fhM4gD-9B4huHUcByBnQsQA@mail.gmail.com> <7f4535c1-3d1d-4c27-77f2-30150b4e9f42@cisco.com> <CAMMESsw70N1P-Bx_mONMbmgL2JWJhwSzeR8vFYoH+0ebLdD24w@mail.gmail.com> <ee75fb01-ba8a-4fa5-80ba-f6b46e1a5c28@cisco.com> <ACBC767D-39FB-4446-B5A8-7FC7381FE6F5@cisco.com> <CAMMESsxJtp5MVi8rpBsVBRBs=c4TPxvmFtxY35RLUESOwEEnug@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <a65f0105-6bf0-5843-041d-c0a0ec8d00af@cisco.com>
Date: Tue, 24 Mar 2020 11:44:48 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CAMMESsxJtp5MVi8rpBsVBRBs=c4TPxvmFtxY35RLUESOwEEnug@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/-8PlzXP0ri03BtrdsVU8nzgHo1A>
Subject: Re: [Lsr] AD Review of draft-ietf-isis-mpls-elc-10
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, 24 Mar 2020 10:44:56 -0000

Hi Alvaro,

I posted a new version - draft-ietf-isis-mpls-elc-11. It should have all 
your inputs incorporated.

Please let me know if you are ok with it. Once it's approved from your 
side, I will update the OSPF draft.

thanks,
Peter


  On 23/03/2020 19:23, Alvaro Retana wrote:
> Ok…let’s move forward.  No need to add more text.
> 
> Alvaro.
> 
> On March 23, 2020 at 10:36:42 AM, Acee Lindem (acee) (acee@cisco.com 
> <mailto:acee@cisco.com>) wrote:
> 
>> Hi Alvaro,
>>
>> On 3/23/20, 5:17 AM, "Peter Psenak" <ppsenak@cisco.com 
>> <mailto:ppsenak@cisco.com>> wrote:
>>
>> Hi Alavaro,
>>
>> On 20/03/2020 19:23, Alvaro Retana wrote:
>> > On March 20, 2020 at 10:34:59 AM, Peter Psenak wrote: 
>> > 
>> > 
>> > Peter: 
>> > 
>> > 
>> >>>>> I don't really see why one would affect the other. 
>> >>>> 
>> >>>> I agree. BMI-MSD is an egress capability and ERLD-MSD is an ingress 
>> >>>> capability. While they may be related in the internal ASIC implementation, 
>> >>>> they are independent from a capability perspective. 
>> >>> 
>> >>> Please write that then. 
>> >> 
>> >> there are many MSDs defined already, are we going to write that the new 
>> >> MSD type is not interacting with any other MSD each time we define a new 
>> >> one? 
>> > 
>> > Yes, when they could be related, we are. More importantly, the reason 
>> > why the will not interact, which is what Acee’s text points to. 
>>
>> honestly I do not see a reason to say that they do not interact. Because
>> if I use your logic I would have to mention hundred other node
>> capabilities that ERLD-MSD is not interacting with. My logic is that if
>> something interacts it needs to be specified, if it does not, it does
>> not need to be.
>>
>> I agree. It seems like a slippery slope to specifically call out 
>> protocol elements which not related from a protocol standpoint.
>>
>> Thanks,
>> Acee
>>
>> > 
>> > BTW, according to the registry there are only 2 MSDs defined: 
>> > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types 
>>
>>
>> there are more defined for SRv6 - draft-ietf-lsr-isis-srv6-extensions-06.
>>
>> thanks,
>> Peter
>>
>>
>> > 
>> > 
>> > Alvaro. 
>> > 
>> > 
>>
>>
>>

v2.23.0 | Report a Bug | By Email