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

Jen Linkova <furry13@gmail.com> Tue, 06 March 2018 22:58 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A986126D05 for <v6ops@ietfa.amsl.com>; Tue, 6 Mar 2018 14:58:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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] 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 UDXgvUFyQZOq for <v6ops@ietfa.amsl.com>; Tue, 6 Mar 2018 14:58:48 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 B20CD1200FC for <v6ops@ietf.org>; Tue, 6 Mar 2018 14:58:47 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id i80-v6so435835lfg.5 for <v6ops@ietf.org>; Tue, 06 Mar 2018 14:58:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Smfyq9wGfoPUWH/S3eLNMJtZKGb3+6AqbPw4jNI8iUk=; b=GU84gBylorR1RbzH1bNhW/NGmRgUcq/Q1HOO/hrvTjaJdNk+WSyiHMqT3ZArzNVjZ4 aHLUuNPtwUXXj6AskImpL0oFt5hd2VVJbGnAcAf2Xs4Lbpy9YuhYUhXMtcaIQE4/Cw5G /YK6Ibhpy4WiX/tjdpw1dNpwlYgcp6Ru4yT0NJK1y/1pOB4pD98ExsqSTYoRFhqUMEOA 29MIXW4QszpASTr0Uu0UtUxdszO2nnDslI3MOVKa8Ga79RRrVVvtbdwO9fR3HDJF2z3o GAx0kkpaVAvnB7Je1YDFLnTxz4TzvrZWPEaxbjl6p8gC/c3RixeaqipjjPMu8T1tecrb YpQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Smfyq9wGfoPUWH/S3eLNMJtZKGb3+6AqbPw4jNI8iUk=; b=dIjUmx+G00PdzumRuWsSIFWILH040DWV0efygHzEiGImlb0W+deyV7GxzOBHg02nrJ 0Wk/VNS1TwJ8sho48ITdbd9Uq8Q2ReXnhtigi4DZpm/22qMZA4In8H+F/voFTTyCdH3N pFUmxEkHetYERZRKeNbq03i0JSNjUf8vrQfRYJEHu2EVhoaynuqRxVWj5/7UuIMkwM91 6EtGKL93UMaHm62640dbr9+QBHrujWUOX9Vn3RkV4hTmtbUXgK96NYI3cuSzd0sL6DYK XAXRVk1/FBghXYfYMO5ZBTtEMRp2Ax5a8meCKLQ5lI3RWYVQfDyzofl9wWIKa2PV09t8 VhtA==
X-Gm-Message-State: AElRT7GB621A+F2I9WqMNAE/rFocsRbL8/A30e+8KHNAC3TwsGt533Y5 Io8ASVZ4IRpMsf3gk332tzxtDAvd1aQOIji/Qc0=
X-Google-Smtp-Source: AG47ELv/knOVk9gJ0KZOyT3PB8f6JspUvlPPjD6/+B2gbQ7dsurddC38pE3l3VmDL2U9KbAdGpU0/MP5pRnqZWHrBKY=
X-Received: by 10.25.38.11 with SMTP id m11mr13633566lfm.22.1520377124399; Tue, 06 Mar 2018 14:58:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.209.10 with HTTP; Tue, 6 Mar 2018 14:58:23 -0800 (PST)
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com>
References: <151976142032.28517.14035738749286138638@ietfa.amsl.com> <CAFU7BAR=ax86N6YMhQeN9fQTgnYO7mzyJNwK2x1OzwpXWwACYQ@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E459B55D41A@AZ-US1EXMB03.global.avaya.com> <20180302185656.GT56288@Space.Net> <9142206A0C5BF24CB22755C8EC422E459B55EA0A@AZ-US1EXMB03.global.avaya.com> <CAFU7BAR+Uyk1PrWN=UCBhuUic-+GO7fAYvSknpLKjr5YixX2iQ@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E459B560FB5@AZ-US1EXMB03.global.avaya.com>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 07 Mar 2018 09:58:23 +1100
Message-ID: <CAFU7BARdE+pzsQVpoWMvDSF7SQpbfR_yP9Ri9xk6togRSmMRgA@mail.gmail.com>
To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
Cc: Gert Doering <gert@space.net>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OGKIqqDowGuSWvcgznfM9lS1qP0>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 22:58:50 -0000

On Wed, Mar 7, 2018 at 1:54 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote:
> [[Dusan]] What I am trying to say is RFC6724 does not know which ISP is preferred, when both prefixes are advertised.

Sorry, it looks like I did not explain it very well..

If/when both prefixes are advertised, both ISPs are "preferred" (in
the same way IPv6 address can be in "preferred" state, which means 'it
can be used for outgoing communications".

Again, we are not solving traffic engineering issue, nor we are trying
to make hosts be fully aware of various paths properties (shameless
plug: please come to PANRG  for that :)).
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).

If an uplink is preferred - the corresponding prefix is advertised
with non-zero preferred lifetime.
It's perfectly fine to have multiple preferred uplinks/ISPs. Hosts can
use addresses from any of them.

>If a router will have a new policy to know the ISP preference, the preference should be passed to the host,

It's binary state. ISP is either "usable" (preferred lifetime > 0) or
not (preferred lifetime == 0). It's how the preference is passed to
the host.

>and RFC6724 should be enhanced to use that preference.

No changes in RFC6724 are needed.
Hosts with Rule 5.5 and default support will do it anyway (if R1 has
is a preferred default router,  then the host selects a source address
from prefixes received from R1).

>This will facilitate a network management where one router policy is configured and all the hosts benefit from that knowledge. When all this is put together, with multiple prefixes, a host will select the preferred source address and a router will use it to forward packet to preferred ISP. If the host part is not addressed, the host will 'randomly' (current RFC6724 will not use the prefix preference) select the source address and packets might go to either ISP1 or ISP2.

If ISP2 should not be used and ISP1 should be preferred (is it the
scenario you are talking about??) then ISP2 prefix should be
advertised to hosts with preferred_lifetime 0. Then hosts will not
select addresses from ISP 2 prefix but use ISP1 prefix instead and
routers will forward packet to preferred ISP1.
Why do we need "prefix preference" for this?

>> >Possible option is to assign a prefix preference in RA.
>>
>> Kind of a combination of Rule 5.5 and router preference? Both of them
>> are not widely implemented, that's the whole point of the draft.
>
> [[Dusan]]
> [[Dusan]] Exactly. Since both prefixes are assigned by two next hops, Rule 5.5 should be enhanced to use the preferred prefix. Standards should not address the current deployment state, but provide a better solution. I would not focus on what is not currently implemented but rather on what should be implemented.

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'.

This draft documents a solution which works right here, right now, the
solution I can deploy today in my network.
Better (more general, covering more use cases, relying on Rule 5.5)
approach to the problem is documented in
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-03
but it can not be used in networks with hosts which do not support
5.5.
Also there is mPVD work etc.

>> The introduction says:
>> "However using IPv6 PA blocks
>>    in multihoming scenario introduces some challenges, including but not
>>    limited to:
>>
>>    o  Selecting the correct uplink based on the packet source address;
>>
>>    o  Signaling to hosts that some source addresses should or should not
>>       be used (e.g. an uplink to the ISP went down or became available
>>       again).
>> "
> [[Dusan]]
> [[Dusan]] These two cases are valid but they don't cover ".Selecting the right source address *to select the egress ISP to use*". This would be a third problem to address. This comes before the first bullet (the source address needs to be chosen first, then the correct uplink). The second bullet talks about the connectivity issues, where a prefix is removed when a link is down. We need to mention the source address selection when both links are up.

If the both uplinks are up and can be used (so load sharing scenario)
then hosts can use either uplink. ISP1 or ISP2. Why is it a problem?
If one uplink (let;s say ISP2) should not be preferred (low
bandwidth/higher price etc) then it's a 'primary/backup' scenario and
hosts are selecting ISP1 prefix as it's the only prefix with non-zero
preferred lifetime.

>> >
>> >
>> >> -----Original Message-----
>> >> From: Gert Doering [mailto:gert@space.net]
>> >> Sent: Friday, March 02, 2018 1:57 PM
>> >> To: Mudric, Dusan (Dusan)
>> >> Cc: Jen Linkova; v6ops@ietf.org
>> >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt
>> >>
>> >> Hi,
>> >>
>> >> On Fri, Mar 02, 2018 at 04:21:32PM +0000, Mudric, Dusan (Dusan) wrote:
>> >> > In Abstract:
>> >> >
>> >> > "The problem of enterprise multihoming without address
>> >> >    translation of any form has not been solved yet as it requires both
>> >> >    the network to select the correct egress ISP based on the packet
>> >> >    source address and hosts to select the correct source address based
>> >> >    on the desired egress ISP for that traffic."
>> >> >
>> >> > Should be:
>> >> > "The problem of enterprise multihoming without address
>> >> >    translation of any form has not been solved yet as it requires
>> >> >    the hosts to select the correct source address based
>> >> >    on a destination address for that traffic,
>> >> >    the hosts to select a first hop router based on the packet
>> >> >    source address, and the network to select the correct egress ISP based on
>> >> the packet
>> >> >    source address"
>> >>
>> >> Actually the new text is completely missing the point.  Source address
>> >> selection *for a destination address* is something already addressed
>> >> nicely (RFC6724).
>> >>
>> >> Selecting the right source address *to select the egress ISP to use* is
>> >> the part not addressed in host stacks at all yet.
>> >>
>> >> The network part "select egress based on proper source address" is halfway
>> >> solved with the homenet protocol suite (source address dependent babel,
>> >> hncp, etc.) - but that is stuff not usually found on Enterprise routers.
>> >>
>> >> 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
>>
>>
>>
>> --
>> SY, Jen Linkova aka Furry



-- 
SY, Jen Linkova aka Furry