Re: [Idr] comments on draft-ietf-idr-rs-bfd

Robert Raszuk <> Wed, 02 August 2017 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C46A131EB8 for <>; Wed, 2 Aug 2017 03:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 AVQPNOgYmhwX for <>; Wed, 2 Aug 2017 03:49:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A1FC131FBE for <>; Wed, 2 Aug 2017 03:49:42 -0700 (PDT)
Received: by with SMTP id o9so18975326iod.1 for <>; Wed, 02 Aug 2017 03:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AtIi9EF7DKxduZrmukjzzNAazuGEUX+ojlKvj8MZYK8=; b=jRVpimiDdmfDTyw6VawJZ/aP/0V3RclkYOwKmmw8LDXPTicJ81DrBumi0J22mU3T8L nWcN5xPkTVLmCNrEPb/AEyr+bk3lwQRGjGOmNs9fviseabwJj15caZTvwtkQCunFhWvE Cq4HQVKJICzQRK7oD+yH/lGvQp3ZCJKEaOHXnkpXWXw4Z3+5U195KWyfTgYAammLfIxl d6OXsGMAPN7acAyx5hpnhWDphJssMnhCbHjgPG8dpEL6vqvs/kE9PlXRWFcNSFmeKNus z5xPI96tuqovgIlygBnR6vSaGjMX1QERIPn+NOgtsW52EtVkX3hgf1722QgGoWPZwr/O CRqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AtIi9EF7DKxduZrmukjzzNAazuGEUX+ojlKvj8MZYK8=; b=njorS9KUAvwedw7y8YMRH0DgWh/C+Su5tJ8KZcpI/v0VCgWDf3jJoy0AyqynU9fEDK 6PTvQ1vKcLwstyFmYbI3rBQx6DZCUpMXkmFSj4FOz6UZjrggYddrLLgj8JsW6wC2kDfI +FcsIbGrFsXFEZGB30HJD82dtnp154IFHBx8Z4jjkxwtMcdRMgz8mCjU40uXry8ui7lo tKAvq0gsVgqaHU7vlcxoWLmpLm+qGixthWOC2afxfHQswhy5VMnRRdqMhmEKD4OWEr8m FdtwsXETIfUSnFgILTCOxHWCLZAt4XQ5n2sQsDUyG2sxi3Mze0b5329SLUulW/PuSCub PxUQ==
X-Gm-Message-State: AIVw1117iK9QEJJUSeAQ7kYF2LLDVN9k0YfriXGJY/r5TBvWEMOkG50P /gEgw18NiH2D8IXuLptv00+DbKsWMg==
X-Received: by with SMTP id y98mr24771874ioi.196.1501670981847; Wed, 02 Aug 2017 03:49:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 2 Aug 2017 03:49:40 -0700 (PDT)
Received: by with HTTP; Wed, 2 Aug 2017 03:49:40 -0700 (PDT)
In-Reply-To: <20170802093233.GR45648@Space.Net>
References: <> <> <> <> <> <20170802093233.GR45648@Space.Net>
From: Robert Raszuk <>
Date: Wed, 2 Aug 2017 12:49:40 +0200
X-Google-Sender-Auth: fu0DZEnNVyW-k__KQMdjWHHXwfg
Message-ID: <>
To: Gert Doering <>
Cc: idr wg <>, Randy Bush <>
Content-Type: multipart/alternative; boundary="001a113e9f627150f50555c3053e"
Archived-At: <>
Subject: Re: [Idr] comments on draft-ietf-idr-rs-bfd
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Aug 2017 10:49:44 -0000

Hi Gert,

Sure you can say that this is implementation detail ... but if you design
protocol right implementation becomes much easier.


Let's consider a scenario that RS client has a view with some bgp policy.
Now this client is using 1500 mtu lan and 9k mtu lan for ipv4 connectivity
via ix.

As reachability to next hops may be different for each lan are we going to
have two sessions of new safi between RS and said client ? Or are we in
this case going to put such client into two different contexts on RS ?


On Aug 2, 2017 5:32 AM, "Gert Doering" <>; wrote:


On Wed, Aug 02, 2017 at 11:07:45AM +0200, Robert Raszuk wrote:
> Interesting ...
> Look at section 5 of yr draft:
> "The next hop field is the key for the NH-Reach NLRI type".
> As defined today your new NLRI encoding in MP_REACH does not have per
> client distinguisher. And if it is the NLRI key as the draft states good
> luck to have the next hop information it carries scoped to be per client.

It's an implemention decision on whether the RS sees this as global
or per-client thing.

Since RSs already today do many things in ways the original BGP specs
did not envision (like, per-client bestpath calculation) doing this
particular one globally does not sound (as said before) like the most
reasonable implementation decision.

OTOH, if the draft had a few more words on this (like, "It is RECOMMENDED
that next-hop reachability is considered a per-client value.  A route-server
MAY decide that a given next-hop should not be considered anymore for
any client if more than a configurable threshold of clients report
unreachability.") it would help to de-confuse readers.

Gert Doering
        -- NetMaster
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279