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

[Mark Smith <[e-mail]>]

Hi Ole,

On 17 December 2017 at 21:20, Ole Troan <[e-mail]> wrote:
> Mark,
>

<snip>

>>>> 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?

If DHCPv6 is being used with the first hop router as a Relay, then the
Relay address could be used as the BGP NEXT_HOP address. Similarly, if
RADIUS accounting records assignment of prefixes to hosts, then the
RADIUS NAS address could be used as the BGP NEXT_HOP address for the
prefix.

If the assignment of prefixes is entirely local to the first hop
router, with no involvement of or reporting to an external service,
then it would be necessary for that first hop router to announce the
host prefix. However, in that case there would likely be a pool of
prefixes to assign to hosts, known to be assigned to a particular
first hop router, so BGP could be used to inject that route somewhere
other than at the first hop router.

> - how do you program the fib of the first-hop router?

In most cases I would expect the first hop router to put the host
assigned prefix in its own FIB, as it was involved in assigning it.

However, if the first hop link has a GUA or ULA prefix, and the host's
address on that link is known externally, as well as the assigned
prefix via RADIUS, then BGP could also be used to program the first
hop router's FIB - the prefix would be injected with the BGP NEXT_HOP
set to the individual hosts' first hop link GUA or ULA address.

Some of these examples are convoluted and unlikely to be used. Others
could be useful depending on goals or network architecture. I
commented really just to show that an absolute statement that the
first hop router must announce the host assigned prefix(es) into the
routing domain isn't necessarily correct if BGP is being used.

Regards,
Mark.


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