Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Thu, 01 February 2018 22:17 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C6412EB08; Thu, 1 Feb 2018 14:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=gmail.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 zt7cAWVx0VWQ; Thu, 1 Feb 2018 14:17:19 -0800 (PST)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 0CA8A12EAC4; Thu, 1 Feb 2018 14:17:19 -0800 (PST)
Received: by mail-oi0-x236.google.com with SMTP id 8so3384698oix.7; Thu, 01 Feb 2018 14:17:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=faTSJIMKsb6v0tCrrLCWZ+EVxsmfrWIdw0Rau2ATeug=; b=lhNlj+fuMh9tCOhSVNSWnWeBzQ9+yic6/L6GEMRNyyFmDJut5pPt0JY/Y3Zvtrtd4n ul+9GukboFM6huFhkZqyTn1ISbg2fpGyWhac1Ya0jGjaz1stbE2pyk66iSh7LnIZAJPd IT3InPDnvqDZE3mVc+WHzhOvBGGad64BOVTcz3BblQSQuJnITVYzDn6n7A0S699Z6ol9 Li+0MOH16peu0Aox59j2Cgsgp3wVMehczo/J+hBQp+NAR5f3/fgV3Ggd+QTcWy6pV+Z2 7JKmuKUQgo8/zH4H1ngqBf8+tPeN1v3Uellp8DFbvUrLxTN2S7tTL6ZmRRa94HP9idIv xHow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=faTSJIMKsb6v0tCrrLCWZ+EVxsmfrWIdw0Rau2ATeug=; b=t2QFi22y5VXR9bEZR3WwMxWnQnqhCm5oZ1X4mfkWhpSy1oaN7hnr2F10I5Z7oCa5Q8 daC2jzvy2Pa9F5P9YVcaduFb9qiRisyUa5nOFIqtpRb/CxjUCO5Me4ESn6hP536B/Z7l QxuU0p7ViZ+fT4VGCRCtWAXVMk6J2+OaeUEAXcSzRazFsvS19Dvhs+jXKxbZR6ypvv9m UoyI2K0E717+8WCZVMLYOr8CMj7nJt6yTa9qSRMNEcTZOjWrEhgbOyAdSWqo+dVIlU1C 4Mhq+PcWg145NZmWbP9b5YFz6gYXNrx4JduPkIXX4OfWwe2qOizQMKv9mC1Bdo+uE8qe 5g5g==
X-Gm-Message-State: AKwxytfA1zf9/q91BsiUkZilKn+4ZpOI/JEK33/I6tZMLiahNzxYH+NU zC3VDcwlTjiWsv0fCwd+JgmnVjj5ZF9Z8YGhfMo=
X-Google-Smtp-Source: AH8x224L0rdimlye0ut4eWfT7qfFxjX0Xk9/WGhvhVadtNmIni+2jOGInM6GEU1qP6KYcjYNGpRIWpXqqrd64qB4YCo=
X-Received: by 10.202.60.196 with SMTP id j187mr4622636oia.216.1517523438411; Thu, 01 Feb 2018 14:17:18 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 1 Feb 2018 14:17:18 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <BN3PR05MB27066EEB2F8E4FAF89B27AF0D5FB0@BN3PR05MB2706.namprd05.prod.outlook.com>
References: <151681659533.22557.7134296491991402002.idtracker@ietfa.amsl.com> <CY1PR05MB2714C3DBC131C4438C64604CD5E10@CY1PR05MB2714.namprd05.prod.outlook.com> <CAMMESswhnUqNi5bW2Auk3j5qE4M51Ez0Hxsmgn=t0zqn1gvr8Q@mail.gmail.com> <BN3PR05MB27066EEB2F8E4FAF89B27AF0D5FB0@BN3PR05MB2706.namprd05.prod.outlook.com>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Thu, 01 Feb 2018 14:17:18 -0800
Message-ID: <CAMMESsyEGkypy6s=y6HEqUtrqmtYH36sbi9EwaPfKtDHmgh1BQ@mail.gmail.com>
To: Shraddha Hegde <shraddha@juniper.net>, The IESG <iesg@ietf.org>
Cc: Acee Lindem <acee@cisco.com>, "draft-ietf-ospf-link-overload@ietf.org" <draft-ietf-ospf-link-overload@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>
Content-Type: multipart/alternative; boundary="001a113cced87c23c805642df50a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/s3vneX8KRQIQvkOS7un_AUXlPos>
Subject: Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-link-overload-13: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Feb 2018 22:17:21 -0000

On January 30, 2018 at 11:43:53 PM, Shraddha Hegde (shraddha@juniper.net)
wrote:


...

(3) Section 4.5. mentions that a "new TLV called Graceful-Link-Shutdown is
defined" for BGP-LS, but there are no details on the format, etc. The IANA
Considerations section suggests a value, not for a TLV but for an NLRI Type!

<Shraddha> OK. Refered section 3.1 of RFC 7752 and described the contents
of the TLV
IANA section seems ok to me. Could you be more specific what needs to
change?


BGP-LS Link NLRI Registry [RFC7752] >>>>>>>Registry

i)Graceful-Link-Shutdown TLV - Suggested 1101 >>>>>>>TLV type

Maybe it’s just me and I just don’t understand…which is completely
possible.  There are two points:

(1)

It looks like you’re defining a new Graceful-Link-Shutdown TLV for BGP-LS.
This TLV (based on the updated description) has no information in it.  How
does the receiver know which link the sender is referring to?

Note that for the OSPF graceful-link-shutdown sub-TLVs, you are indicating
where to carry them so that there is an obvious indication of which link is
being shutdown.  I would like to see explicitly specified how the receiver
associates this TLV with the appropriate link.  Again, I may be missing the
details.



(2)

The value for the TLV was reserved by IANA in the "BGP-LS NLRI-Types"
registry, not in the "BGP-LS Node Descriptor, Link Descriptor, Prefix
Descriptor, and Attribute TLVs” register, which is where I would have
assumed a modifier to the link would reside.  IOW, according to the
registry you are defining a new NLRI Type, not a new TLV — and, according
to the updated description in the document there’s no information in this
NLRI.

<Shraddha> The TLV code point registration should be in “BGP-LS Node
Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” I have
corrected this in the document.

Will e-mail to IANA for correction as well.

Does that answer your concerns?

That addresses the concern #2 above.  I still don’t see anywhere how the
receiver associates this (empty) TLV with the right link.

Alvaro.