Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13

Peter Psenak <ppsenak@cisco.com> Thu, 07 May 2020 07:54 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 E6A5A3A09F1; Thu, 7 May 2020 00:54:04 -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 Fq5rlBo6uP-w; Thu, 7 May 2020 00:54:03 -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 30CA13A07F7; Thu, 7 May 2020 00:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3791; q=dns/txt; s=iport; t=1588838042; x=1590047642; h=from:subject:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3wgxOeB77Yv+gw8Cf4n7UgqaNnZakyM7Y9O+spvWgoY=; b=EoF4eflBEflQYn4b15bhFLce6460aumubIP4x4qTg0UqkSufNh81zr9x TwJJPWuKNsyFwe6WWyyvrtXtSQbgwDPRaU72zmfc+IODvcDjJQZkX71cc TBWzkPIcy99nJbtQz0SpOT8S8C4GWMekzOq+B/aHmsGws3anPyQ6J5VIi s=;
X-IPAS-Result: =?us-ascii?q?A0DMAwA3vbNe/xbLJq1mHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UeDGFUgEoRNiQGHWwglm14LAQEBDiMMBAEBhEQCgig4EwIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQUEbYVWDIVxAQEBAQIBIw8BBTMOBQsLFAQCAiYCAlcGAQwIAQGDI?= =?us-ascii?q?gGCXCAPr0J2gTKFUINOgToGgQ4qjF6BQT+BEAEnDIJdPoJnAoR3gmAEjmyTX?= =?us-ascii?q?5AGglKCcIUoj3gGHYJbiGGEVI0QkBeJVJNwgWkigVYzGggbFRqDC08YDZlIh?= =?us-ascii?q?UQ/A2cCBgEHAQEDCZABLIIZAQE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,363,1583193600"; d="scan'208";a="23634346"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 07:54:00 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id 0477rxQ0029193; Thu, 7 May 2020 07:54:00 GMT
From: Peter Psenak <ppsenak@cisco.com>
To: Elwyn Davies <elwynd@dial.pipex.com>, gen-art@ietf.org
Cc: draft-ietf-ospf-mpls-elc.all@ietf.org, last-call@ietf.org, lsr@ietf.org
References: <158877512992.25308.14489968716385236242@ietfa.amsl.com>
Message-ID: <5f206fd3-8918-9c1f-e403-8591c54acf83@cisco.com>
Date: Thu, 7 May 2020 09:53:59 +0200
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: <158877512992.25308.14489968716385236242@ietfa.amsl.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-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/3W35mf9apRzOwGoda8b--QyPueI>
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13
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: Thu, 07 May 2020 07:54:05 -0000

Hi Elwyn,

please see inline:

On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote:
> Reviewer: Elwyn Davies
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-ospf-mpls-elc-13
> Reviewer: Elwyn Davies
> Review Date: 2020-05-06
> IETF LC End Date: 2020-05-05
> IESG Telechat date: 2020-05-21
> 
> Summary:
> Ready with nits.  Aside:  I have to say that the convolutions and
> cross-referencing of doing the OSPF and IS-IS  extensions plus BGP-LS added to
> the cross-linking with MPLS is leading to mind-blowing complexity.  Sooner or
> later something is going to blow up here!
> 
> Major issues:
> None
> 
> Minor issues:
> None
> 
> Nits/editorial comments:
> 
> Abstract and title :  The application to BGP-LS (s5) is not mentioned in the
> abstract or the title.  Also the first use of BGP-LS needs to be expanded.

Why would the BGP-LS need to be mentioned in the abstract?

I have expanded the first use of BGP-LS

> 
> Abstract: s/tunnel/LSP/

done

> 
> s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/
> 
> s1: Query:  As a non-expert in this area, I was wondering if the signalling
> capability is or will be implemented in IS-IS?  A brief comment on the status
> wrt IS-IS would be helpful.  [It turns out that you already reference the
> document that implements this later in this draft.]

yes, it is being added to ISIS. Yes, this draft reference the ISIS 
draft. I see no reason to to include ISIS draft status in this document 
though.


> 
> s1, last sentence: s/it's/it is/

done

> 
> s3: It would be a good idea to expand 'prefix' to 'address prefix
> advertisement' on its first occurrence here.  Thereafter 'prefix' is fine by me.

"prefix" is being used in almost all OSPF and ISIS document, we never 
use address prefix.


> 
> s3, para 3: Why would a router not advertise the ELC with all prefixes?  Can
> you say why this ought not to be a MUST.

advertising ELC property with prefix advertisement is optional. We can
not mandate it. It would make all routers not advertising this data
violating this spec.

> 
> s4, para 3: In that case, what does the absence signify?  Should we care?

the absence of ERLD-MSD advertisements only indicates that a node
does not support advertisement of ERLD

It can not be interpreted that ERLD is not supported.  Old nodes that do
not advertise ERLD-MSD can not be assumed not to support non-zero ERLD.


> 
> s4, para 4:
> This needs a correction and a reference to where the Link MSD Sub-TLV is
> defined.  As a matter of interest, is there any reason why this should be sent
> in an OSPF context?  If not why not just prohibit sending it? If it is received
> should it provoke an error rather than being ignored? OLD: When the ERLD
> MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV, it MUST be
> ignored. NEW:
>   When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV
>   [RFC8476], it MUST be ignored.

done.

> ENDS
> 
> s5:  This section needs to be rewritten to be 'future proof' rather than
> referring to the temporary allocations.  A note about the temporary allocations
> can be added with a RFC Editor note requesting its removal on final publication.

I suppose you meant section 6 - IANA Considerations.

I have updated the IANA section.

thanks,
Peter
> 
> 
> 
> 
>