Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt

Jen Linkova <> Sat, 17 March 2018 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E2B51270AB for <>; Sat, 17 Mar 2018 07:09:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 pYMebM_cI3CJ for <>; Sat, 17 Mar 2018 07:09:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46891126E01 for <>; Sat, 17 Mar 2018 07:09:06 -0700 (PDT)
Received: by with SMTP id y19-v6so19344942lfd.4 for <>; Sat, 17 Mar 2018 07:09:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=F7GmimYE2XZL+q/7iNv3UhySesa3Ey1L7Eh0wN7Arm4=; b=ce00xja0TTdEWMlhUdmmfKSGmN3A4LgMQAkjPN4Z3VJW3Qhk8q1vlE5qzs1DGCzWEI /CDInsf/Cm9rhgS6iaUyF1sM2GvcWOMyybPum4JcSAU0OxRmzQh3pUj/jsKVEl9VOCFw 5ByXYmfXAYd7IeEB4M5VRkEIpuAZax+dTu5C8oYrViBs+kRqiWtpOXOta+VM9gBjSVib LwsgIVztZHdCkPvhNoSQNK1UpEsXKwsLlWQqTqGXWlhzKm9u7PSEyQwvv2cspDgC2HBD O1aYbHWBB9kMVDZ2RQal04aib1gBpsrH3J8naVL8ro7fMmxWUM7WHpiXkiNmqSr/nSBV htwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=F7GmimYE2XZL+q/7iNv3UhySesa3Ey1L7Eh0wN7Arm4=; b=YqxXsSDNCOkqxxqYmuHcp9yyCSkJvPNdzsG+949Xi+4D4ga68Ub8EHjVCIxWMKRmlD 3dWuYvm3AcOWQoIeBpfUYJGLATjDTr9Ojc/d84AQycvxX0VHI7ULZi2wdXZmxLsqnxAp NVwRopYr1oFBA+cDziHelm0kxMc4FlpVM+P4dHxXYjcdyl6PRy2oSS31hRURCui6goWx 6HF1zWmavtczFH2Fqw03tCAULQg7CcHN8dAxn0Etxq4XjRKKN6dvWloCaU3pXgjVCOlp xtMGAqQyADMdrPqkS8+ObcFNdSRexIdjytwAhAXrK7z+FveZJCxUYH81q0Hzk+386vn2 UYMg==
X-Gm-Message-State: AElRT7HI08ivoVu+0u51bkfVGRxZYoEj6/kK/2BYUXZsKDRLtGZNsZ29 HSUqwSVHOZXL1O6XikkV1FMS86rzNqWFyQOZIPc=
X-Google-Smtp-Source: AG47ELuNyBosZMxx5jNcNbsqFYgeyx2XW8F+SDHktpnKobC1rPZfbRr5RmGF/WB4f6uA+eCFGsu1laUJ9Z6268387PU=
X-Received: by with SMTP id j22mr3861525lja.27.1521295744342; Sat, 17 Mar 2018 07:09:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Sat, 17 Mar 2018 07:08:43 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <20180302185656.GT56288@Space.Net> <> <> <> <> <>
From: Jen Linkova <>
Date: Sun, 18 Mar 2018 01:08:43 +1100
Message-ID: <>
To: "Mudric, Dusan (Dusan)" <>
Cc: Gert Doering <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Mar 2018 14:09:08 -0000

On Fri, Mar 9, 2018 at 3:40 AM, Mudric, Dusan (Dusan) <> wrote:
> I believe I understood the intent of the draft. Let me explain my understanding of rule 5.5. Please see inlined.

>> ISP uplink is either "preferred" (hosts are allowed to use it, the
>> network can send packets there, because the uplink is up and there is
>> no explict policy which indicates that the uplink should not be used
>> if other uplinks are available) or not preferred (it's down or there
>> is a policy to prevent using this uplink ex. for backup).
>> It's binary state.

> [[Dusan]] The router knows more than that. For 'usable' prefixes, the router knows which prefix is the most preferred.

Would you be able to give an example for 'most preferred'? The network
has two uplinks to two ISPs, two prefixes. Both uplinks can be used.
Each border router has a default route pointing to the uplink.
What prefix is 'most preferred' to reach  Internet?

>The router can pass that knowledge in RA PIO option, using 'reserved' bits, for example (like Prf in rfc4191#section-2.2 ). Without this information, if there are two prefixes (ISP1-D and ISP2-D) how will host know if it should talk to D over ISP1 or ISP2? Rule 5.5 cannot determine it:
>    Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
>    If SA or SA's prefix is assigned by the selected next-hop that will
>    be used to send to D and SB or SB's prefix is assigned by a different
>    next-hop, then prefer SA.
> You can consider the trick in by setting two routes in RA and the Prf from rfc4191#section-2.2, based on the router policy. This would allow a host to select the preferred next hop and use the preferred next hop in Rule 5.5. Using Prf in RIO the router policy is distributed to all hosts and they can select the preferred ISP. A router SHOULD set Prf based on the ISP selection policy. There might be use case when the network would use only one route and advertise one prifix.

I'm not sure if you've been following the whole story....When
draft-ietf-rtgwg-enterprise-pa-multihoming was presented to v6ops in
Berlin, we came to conclusion that while the described trick is nice,
it could not be widely used now. So some tactical solution is needed.
That's why this draft was 'forked' from the RTGWG one.
So anything which require protocol changes/new features/rule 5.5
support is out of scope of this draft by the definition.

> [[Dusan]] Because the router should not limit the communication over one ISP by advertising only one prefix. The host should be able to decide which of the two ISPs to use. Both prefixes should be given to the host

In the 'load sharing' scenario it is exactly what happens. All ISP
prefixes are included in PIO.
In the active/backup scenario only active uplinks prefixes are
advertised, because the network policy does not allow hosts to use the
backup uplink so hosts should not select backup uplinks.

> and they should have the preference assigned.

Which hosts would not recognize.

>> Have I sent this email to 6man@ by mistake? Ah, does not look like that :)
>> And I seem to set the document status to 'Informational'.

> [[Dusan]] If we change IPO option, it is not informational any more.

Again, the goal of *this particular* draft is to document existing
solution, which can be used right now w/o any changes on the host.

If we have ideas how to improve the protocol - great, but those ideas
should not be in this draft.

SY, Jen Linkova aka Furry