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

[Mark Smith <[e-mail]>]

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.

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