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

Peter Psenak <> Thu, 07 May 2020 07:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6A5A3A09F1; Thu, 7 May 2020 00:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.601
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fq5rlBo6uP-w; Thu, 7 May 2020 00:54:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30CA13A07F7; Thu, 7 May 2020 00:54:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.73,363,1583193600"; d="scan'208";a="23634346"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 07:54:00 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id 0477rxQ0029193; Thu, 7 May 2020 07:54:00 GMT
From: Peter Psenak <>
To: Elwyn Davies <>,
References: <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Lsr] Genart last call review of draft-ietf-ospf-mpls-elc-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> <>.
> 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/


> 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 

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


> 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.


> 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.