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

[Mark Smith <[e-mail]>]

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.

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.

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