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

elwynd <elwynd@googlemail.com> Mon, 18 May 2020 21:02 UTC

Return-Path: <elwynd@googlemail.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 837B93A0D3D; Mon, 18 May 2020 14:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 TQTGCKghzycj; Mon, 18 May 2020 14:02:04 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C40C3A0D19; Mon, 18 May 2020 14:02:04 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id i15so13403404wrx.10; Mon, 18 May 2020 14:02:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=message-id:from:savedfromemail:date:subject:in-reply-to:importance :to:cc:mime-version; bh=EQOEuCT8w519Rwy7jszPydFJzxltItYq3Ldbo8zQezc=; b=SlBcXSQhabwXrMMnSKQeWiw6VFgaL1T7yMGQgrAZgwBROmFunQN7nMQKKukGjcfJ1N nj9R9Z66XkAlYO7WDFcqrq8jW60XN0FznOpbtTq9TSipVUGpyOVfdxAxrPH4uEmIvZFf IxKx3aoGf6FctXkgECjdhEIM3IEkET/De0wIZbFD+NTaABnCDPaLbJXwvbzDrronqcGL DdQpOKpe7G6PrAErs/MfkK03vswhmQ+/mbtIhtEshJsVvF2asfryEHtiiCJYyNdYnX8r JC5/YA47DKTin5hVmsGHkhz1IZWml3r9XDmPXbHszVPRVxOWMyaNNHDfbAiTcsnYhb8A 22pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:savedfromemail:date:subject :in-reply-to:importance:to:cc:mime-version; bh=EQOEuCT8w519Rwy7jszPydFJzxltItYq3Ldbo8zQezc=; b=cKzdQpGEXquOa8D3qSBpAoR2dkTAFQMZf7tE3d2HTbwcwe3rLawXe2d21Coofi4gzk AOO+pXZxbpj6DP8UVsKwpmpIjeqn8p/QUHTJZTHg/Pa7yWzPt3LxLHYZPz2j1++MqIjm oV7QfICibJwzljmrTLnsEdSyoukqbh6CDKkkSfMGt3+ayKhJ6lx6EZrHwB61cskkWU0C /GyzkfTTusnJB+Sh+FpUauwKd9hICs7IE8XUy6MkpsNZTaccOphNBDqLZmtsqbD2y5qb V4zIj9auk1zX/EU9jTJpaIvgd0ss/rBDj+74QHPj0k32xMhxVT4hPbS9rkMcgS8mBeS2 3YFQ==
X-Gm-Message-State: AOAM533W8FS21eV7JFVO6cFfZvTiqElPd0hmj5Zm97OuuP44xbzHICbG JTwO4UvMKosC2ogItLr/B3Q=
X-Google-Smtp-Source: ABdhPJwz8GWiMmPsyqMCaQmrU86Z5hTX6lrSdh/hgZEBJTEURzKJNoAcho4wtu70pNJrA48vmOsjlw==
X-Received: by 2002:adf:ce05:: with SMTP id p5mr17443331wrn.423.1589835722643; Mon, 18 May 2020 14:02:02 -0700 (PDT)
Received: from ?IPv6:2001:8b0:bf:1:2dba:aa40:9d16:66ee? (e.e.6.6.6.1.d.9.0.4.a.a.a.b.d.2.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:bf:1:2dba:aa40:9d16:66ee]) by smtp.gmail.com with ESMTPSA id x184sm962015wmg.38.2020.05.18.14.02.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2020 14:02:01 -0700 (PDT)
Message-ID: <5ec2f7c9.1c69fb81.720d3.4998@mx.google.com>
From: elwynd <elwynd@googlemail.com>
X-Google-Original-From: elwynd <elwynd@dial.pipex.com>
SavedFromEmail: elwynd@dial.pipex.com
Date: Mon, 18 May 2020 22:02:00 +0100
In-Reply-To: <D8EB1712-6F32-4015-B8CD-A61E4FEDE3DC@cisco.com>
Importance: normal
To: "Acee Lindem (acee)" <acee@cisco.com>, Alvaro Retana <aretana.ietf@gmail.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-ospf-mpls-elc.all@ietf.org" <draft-ietf-ospf-mpls-elc.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_624598331044530"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1V_SWpC4y0A5n2BPx0Kg3_Yq7AY>
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: Mon, 18 May 2020 21:02:07 -0000

Hi.I am not convinced by the discussion that has ensued from my review.s3, para 3:    If the router supports ELs on all of its interfaces, it SHOULD
   advertise the ELC with every local host prefix it advertises in OSPF.
- Both Acee amd I didn't immediately understand that 'every local host prefix' was not every 
  prefix that the router might advertise.  It would be good to explain that this is the case.- As I previously stated, with a SHOULD it ought to be explained why one might not want to
  advertise the ELC with some subset of the local host prefixes.- Given that there are now two sets of prefixes, would/SHOULD/MUST ELC be advertised with the 
  prefixes that are not local host prefixes?s4, para 3:   The absence of ERLD-MSD advertisements indicates only that the
   advertising node does not support advertisement of this capability.Firstly, I cannot see why this statement or its absence might affect other EL mechanisms that
don't use OSPF to do signaling of ELC.  If I understand RFC 8662 correctly, if OSPF is being used to distribute ELC adverts and the ERLD 
is not advertised by OSPF, then either the ERLD has to be supplied by other means or it will 
effectively default to zero.Thus, I would suggest that the paragraph above should be replaced with:   Advertisement of ERLD via OSPF using ERLD-MSD is OPTIONAL.  If a router does not advertise 
   ERLD, then the EL positioning calculations described in [RFC8662] will assume a vaue of zero
   for the ERLD of this router unless a different value is supplied by alternative means. Regards,ElwynSent from Samsung tablet.
-------- Original message --------From: "Acee Lindem (acee)" <acee@cisco.com> Date: 14/05/2020  21:43  (GMT+00:00) To: Alvaro Retana <aretana.ietf@gmail.com>om>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>om>, Elwyn Davies <elwynd@dial.pipex.com>om>, gen-art@ietf.org Cc: last-call@ietf.org, draft-ietf-ospf-mpls-elc.all@ietf.org, lsr@ietf.org Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13 

Hi Alvaro, Elwyn, 
 

From:
Alvaro Retana <aretana.ietf@gmail.com>
Date: Thursday, May 14, 2020 at 3:46 PM
To: Acee Lindem <acee@cisco.com>om>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>om>, Elwyn Davies <elwynd@dial.pipex.com>om>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "last-call@ietf.org" <last-call@ietf.org>rg>, "draft-ietf-ospf-mpls-elc.all@ietf.org" <draft-ietf-ospf-mpls-elc.all@ietf.org>rg>, "lsr@ietf.org" <lsr@ietf.org>
Subject: Re: Genart last call review of draft-ietf-ospf-mpls-elc-13


 


Hi!


 


Yes, we cannot specify something that routers unaware of this specification should or shouldn’t do.


 


I believe that Elwyn’s point is this: *if a router supports this specification* then when would it not advertise the ELC?  IOW, the specification only obviously
 applies to implementations that support it — in that case I would think that if a router supports ELs on all of its interfaces then it would always advertise the ELC, right?
 
That’s true – but not advertising the OSPF capability could imply that either ELC MSD or advertisement of the OSPF capability is not supported. Although I might not have worded it as such, that was clear to me from the text. Feel free to
 recommend alternate text if you feel it is necessary. 
 
Thanks,
Acee


 


Thanks!


 


Alvaro.

 
On May 11, 2020 at 3:18:34 PM, Acee Lindem (acee) (acee@cisco.com) wrote:


Note that the optionality of ERLD-MSD advertisements appears on 
reflection to be a more serious issue than just an editorial nit. 

So what would you suggest? There are existing implementations that support multipath forwarding entropy using MPLS entropy labels but do not signal that capability in OSPF. We can't have a document that retroactively mandates
 that they signal it. This wouldn't be backward compatible. How can you possibly see this as a serious issue?