Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 16 December 2017 04:50 UTC

Return-Path: <alexandre.petrescu@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 02ED612711B for <v6ops@ietfa.amsl.com>; Fri, 15 Dec 2017 20:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 uIbrbIHJs17W for <v6ops@ietfa.amsl.com>; Fri, 15 Dec 2017 20:50:33 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27601126C19 for <v6ops@ietf.org>; Fri, 15 Dec 2017 20:50:33 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vBG4oVCa015689 for <v6ops@ietf.org>; Sat, 16 Dec 2017 05:50:31 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 174E72014E8 for <v6ops@ietf.org>; Sat, 16 Dec 2017 05:50:31 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0C7C2201173 for <v6ops@ietf.org>; Sat, 16 Dec 2017 05:50:31 +0100 (CET)
Received: from [132.166.84.1] ([132.166.84.1]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vBG4oUUl015997 for <v6ops@ietf.org>; Sat, 16 Dec 2017 05:50:30 +0100
To: v6ops@ietf.org
References: <b9e5919554204ad48f33740eaac4ccb8@XCH15-06-08.nw.nos.boeing.com> <DB4EE076-6231-4305-8514-0CC165C9EFD9@gmail.com> <827FCFAE-6A5A-4BC8-AF20-0A7D65F4EEB1@employees.org> <e1590482-b8ce-ccf1-1d71-873e1b6d7285@gmail.com> <0FF2EE3E-C839-48AC-B169-B39B5E01C95A@employees.org> <26114dec-a4a7-d96d-a925-bef0100d80cf@gmail.com> <fdcac9d5c361485986575f522d0d9f21@XCH15-06-08.nw.nos.boeing.com> <CAO42Z2yZijv_VZ7BqTo8ALD4faZKnHXX1YxxiwuJFK5TPgZczg@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <263a3201-fc29-2662-4abd-971272f33e5b@gmail.com>
Date: Sat, 16 Dec 2017 05:50:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2yZijv_VZ7BqTo8ALD4faZKnHXX1YxxiwuJFK5TPgZczg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/E9ezBa3sorfCb3IfdCIDsZ1gz4M>
Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
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: Sat, 16 Dec 2017 04:50:36 -0000


Le 16/12/2017 à 00:44, Mark Smith a écrit :
> Hi,
> 
> On 16 December 2017 at 08:20, Templin, Fred L
> <Fred.L.Templin@boeing.com> wrote:
>> Hi,
>> 
>>> -----Original Message----- From: v6ops
>>> [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter 
>>> Sent: Friday, December 15, 2017 1:09 PM To: Ole Troan
>>> <otroan@employees.org> Cc: v6ops@ietf.org Subject: Re: [v6ops]
>>> draft-templin-v6ops-pdhost a working group draft?
>>> 
>>> On 16/12/2017 09:20, Ole Troan wrote:
>>>> Brian,
>>>> 
>>>> Sure, but we have learnt that the matter of route injection is
>>>> a thorny problem.
>> 
>> Without question, the first-hop router has to do route injection.
> 
> Actually, I don't think that is true. Some other router in the
> network running BGP could inject the route into the routing domain,
> with a BGP route NEXT_HOP attribute for the route set to either a
> non-Link-Local address of the client host's interface, or the
> NEXT_HOP attribute for the route set to one of the first-hop router's
> addresses (likely a loopback interface address ), with that first-hop
> router then resolving the last hop IPv6 address/link-layer address to
> reach the host. (I'd be inclined to do the latter to make it easier
> to identify from the BGP route table  NEXT_HOPs where a particular
> set of host with assigned prefixes are attached, and I think BGP
> implementations commonly consume less memory when a set of prefixes
> share the same NEXT_HOP address.)
> 
> This "route injection" BGP router(s) would need to somehow learn of 
> the host assigned prefixes when they're assigned to then inject the 
> assigned host prefixes.

But then, how that 'route injection' BGP router learns these prefixes?
If the 'route injection' BGP router is the DHCP Relay, then it is very
easy: they are processes on the same filesystem and they can coordinate
easily.

(the DHCP Relay must be the first-hop router from the perspective of the 
pdhost).

> Haven't thought enough about whether it would be worth doing this
> way or not. It might be operationally better or simpler to have a
> smaller set of routers do this type of injection on a network rather
> than having all first hop routers, which could, for example, number
> in the 1000s, do it.

A question is who triggers the 'route injection' BGP router to inject:
is it the Server or the Relay?  If it is the Relay, then one may end up
with 1000s of Relays not doing route injection, but triggering 1000
messages to the 'route injection' BGP router which in turn would inject
routes.

(as a side note, in a certain deployment there is no DHCP Relay, and the
DHCP Server is a unique and big machine that executes also BGP and does
the BGP route injection too upon prefix delegation).

Alex

> 
> Regards, Mark.
> 
>> It also has to honor route lifetimes, route revocations and
>> link-layer address changes of the requesting router.
>> 
>> I think this latter point is one that may need some further
>> consideration. If the requesting router's link-layer address
>> changes, and the requesting router signals the first-hop router by
>> sending unsolicited NAs, wouldn't it be much easier if the
>> first-hop router were also an active participant in the prefix
>> delegation process? Because, an off-link entity would never see the
>> NAs.
>> 
>>>> If you do not topologically restrict the problem, how do you
>>>> solve it? Among separate administrative domains.
>>> 
>>> Agreed. It can get very tricky. I just prefer the language in the
>>> draft not to be restrictive.
>> 
>> I think the language can be relaxed, but I go back to the point
>> about the first-hop router also being an active participant in the
>> PD exchange. AFAICT, the first-hop router is the only node that can
>> both inject the prefix and observe the on-link behavior of the
>> requesting router.
>> 
>> Thanks - Fred
>> 
>>> Brian
>>> 
>>>> 
>>>> Ole
>>>> 
>>>>> On 15 Dec 2017, at bu20:07, Brian E Carpenter
>>>>> <brian.e.carpenter@gmail.com> wrote:
>>>>> 
>>>>> On 16/12/2017 02:21, Ole Troan wrote:
>>>>>>>> Please review and send any new comments to the list,
>>>>>>>> and please confirm whether earlier comments have been
>>>>>>>> addressed.
>>>>>>> 
>>>>>>> It continue to describe the entity delegating the prefix
>>>>>>> as a "Delegating Router 'D'". The IPAM (IP address
>>>>>>> Management, and by
>>> extension IP Prefix Management) software can be implemented in a
>>> computer sold as a router, but there is no requirement that it
>>> be, and it usually is not. As a matter of fact, if a router is a
>>> system that forwards messages directed to addresses other than
>>> its own, in the context of an application such as a DHCPv6
>>> address/prefix management process, it is acting as a host, not a
>>> router.
>>>>>> 
>>>>>> Prefix delegation, more so than address assignment is
>>>>>> coupled with the routing system. Which is why RFC3633 only
>>>>>> described a model where the delegating router and
>>>>>> requesting router was directly connected.
>>>>> 
>>>>> They're coupled, but it isn't logically required that the
>>>>> entity that gives prefix P to a device is also the upstream
>>>>> router that will include P in an aggregate. I agree that's a
>>>>> natural implementation, but it isn't the only one. IPAMs and
>>>>> their generalisation in CASM, and
>>>>> draft-ietf-anima-prefix-management, are alternatives.
>>>>> 
>>>>> So I agree - it is a false assumption that the prefix
>>>>> delegator is a router, and that the delegation mechanism is
>>>>> RFC3633.
>>>>> 
>>>>> As far as the draft goes, I'd like to see this qualified:
>>>>> 
>>>>> "An example IPv6 PD service is the Dynamic Host Configuration
>>>>> Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633].  An 
>>>>> alternative service based solely on IPv6 ND messaging has
>>>>> also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]."
>>>>> 
>>>>> Maybe by adding that other, non-router, mechanisms may
>>>>> exist, such as proprietary IPAMs,
>>>>> draft-ietf-anima-prefix-management and
>>>>> draft-sun-casm-address-pool-management-yang (expired).
>>>>> 
>>>>> Brian
>>>>> 
>>>>> _______________________________________________ v6ops mailing
>>>>> list v6ops@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>>> 
>>> 
>>> _______________________________________________ v6ops mailing
>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> _______________________________________________ v6ops mailing list 
>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>