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

[Ole Troan <[e-mail]>]

Mark,

> On 17 Dec 2017, at 02:37, Mark Smith <[e-mail]> wrote:
> 
> On 16 December 2017 at 15:50, Alexandre Petrescu
> <[e-mail]> wrote:
>> 
>> 
>>> Le 16/12/2017 à 00:44, Mark Smith a écrit :
>>> 
>>> Hi,
>>> 
>>> On 16 December 2017 at 08:20, Templin, Fred L
>>> <[e-mail]> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>>> -----Original Message----- From: v6ops
>>>>> [mailto:[e-mail]] On Behalf Of Brian E Carpenter Sent:
>>>>> Friday, December 15, 2017 1:09 PM To: Ole Troan
>>>>> <[e-mail]> Cc: [e-mail] 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.
>> 
> 
> In some unspecified way. Point I'm making is that it isn't a necessity
> that the first hop router is the one that injects the route. In a
> large network running BGP there can be value in more centralising
> functions such as route advertisement e.g. BGP Route Reflectors.
> 
> e.g if you have centralised DHCP server infrastructure, a few BGP
> routers adjacent to the DHCP servers that are injecting routes would
> reduce the need to have each and every first hop router perform that
> function.

If hand waving is all that’s required, sure. :-)
- how do you “know” the next-hop address of first-hop or last-hop?
- how do you program the fib of the first-hop router?

Sure, you can do that with some out-of-band mechanism, but you’re still only hand waving. 

Cheers 
Ole


> 
>> (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).
> 
> That's a possible model, although I don't like "big machines" because
> the consequence of their failure as also usually big.
> 
> It's finding the right balance between highly distributed and highly
> centralised, weighing up the trade-offs between.
> 
> 
>> 
>> 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
>>>>>>> <[e-mail]> 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 [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________ v6ops mailing
>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ v6ops mailing list
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> 
>>> _______________________________________________ v6ops mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops