Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt

Jeff Tantsura <> Fri, 03 March 2017 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5788E129608 for <>; Fri, 3 Mar 2017 12:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZMrCjqzkhp_s for <>; Fri, 3 Mar 2017 12:52:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AFC1129528 for <>; Fri, 3 Mar 2017 12:52:01 -0800 (PST)
Received: by with SMTP id b129so47524666pgc.2 for <>; Fri, 03 Mar 2017 12:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=rL2d3oHQEMujlhmlYY41MZQ2PCLYYkaaEJOa4JaIaXk=; b=RZLP9X75vstAPLztaxMk9J5IyM2pUvIJ1Myjwa9Jhd1o5+Vc7G1lP5O/ceW/jSDhDt ek7MPiqMsvV1mUp7H1dKIz8uaHzaJBuqEsDUr5ajrc2uxYiSt4SmHwnHpKvlpOcKlnpE jsuEcJn9bHDPWXiWbuOqLQqMp1Is9i73Pk5hBGsifp0M1I4XKwyoOZppwaiG4BiccEKg bxyVUBbHuzxVNzIFmONLR5gNNJrubwO/1ckINWk7JZyQHqjoElpfZA+4K3c8JboTscyd kaCkrY3B4hx7cK8eHl2Lkl3v7WRhI8siLDrUt+vwujCAlL/KiBT1b/tLQPhoQBZ39QHR decw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=rL2d3oHQEMujlhmlYY41MZQ2PCLYYkaaEJOa4JaIaXk=; b=mCPX86gICd9JK4njpUKulMqwjJJ1MdpIxm5i7vY6VoJWq09AYji9tRK7sIrfiwuJ3I eseiXVkc9AUYIPpgRkRRN+ulX/mR7VPpoZrPFnxWO3pXCdjgW2sgek3Z48pk0qw62HHj WrHsDPGb1XLwhegsAqDfeGxRsOg3oR3cHs74LhKWp0apNw2UHKidV3VaBhTeeakMq9jQ 4z/Ui8+rStRbNYzwKmqVtqEdL00FcLB9Yh9Ud7WR1REtl6Edp7P8KafVPSQQt0oVkROG GxJwzi29xufOeNc+pe69uz4dz47plJxonUz0ESOy91FD2reeGGFufdsw9g7eeZouCWFa xLCw==
X-Gm-Message-State: AMke39nAkWzvMGti56wIr85IKU01oN2l2n+v5CaeHe9pg51VQUBIkj6Sy5oLRX6ZNbpEPg==
X-Received: by with SMTP id x78mr5841716pfj.88.1488574320647; Fri, 03 Mar 2017 12:52:00 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id j62sm25176204pgc.54.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 12:51:59 -0800 (PST)
User-Agent: Microsoft-MacOutlook/f.1f.0.170216
Date: Fri, 03 Mar 2017 12:51:59 -0800
From: Jeff Tantsura <>
To: Jeffrey Haas <>, "Van De Velde, Gunter (Nokia - BE)" <>
Message-ID: <>
Thread-Topic: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
References: <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Cc: idr <>
Subject: Re: [Idr] FW: New Version Notification for draft-vandevelde-idr-bgp-ls-segment-routing-rld-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Mar 2017 20:52:02 -0000


This is the approach taken in MSD (Max SID Depth )drafts (IGPs/BGP), both node and link values can be signaled.


On 3/3/17, 12:54, "Idr on behalf of Jeffrey Haas" < on behalf of> wrote:

    On Fri, Mar 03, 2017 at 02:55:39PM +0000, Van De Velde, Gunter (Nokia - BE) wrote:
    > Heads-up… Happy to learn feedback and comments.
    > This draft is short and defines the attribute to use for BGP-LS to expose a 
    > node RLD "Readable Label Depth" to a centralised controller (PCE/SDN).
    This seems like a good idea.  I was not aware of the work in the other area,
    so I believe my primary commment needs to go elsewhere as well:
    While it's true that a given node may have a given limit on its readable
    depth, this may potentially vary on a per interface basis.  What's the
    intent, if any, to accommodate something beyond the least common
    Editorial nit, your references point to the ospf document twice.
    -- Jeff
    Idr mailing list