Re: [v6ops] Updating RFC 7084

What’s the problem you’re trying to solve here?

Op ma 21 nov. 2022 om 10:59 schreef Vasilenko Eduard <
vasilenko.eduard@huawei.com>

> It was not about routing.
>
> DHCP-PD propagates prefixes that would be used for PIOs.
>
> If Carrier is not available anymore, hosts should stop using these PIOs
> for source addresses.
>
> But the stub router should be informed that particular prefixes should not
> be used anymore.
>
> How?
>
> Then stub router could deprecate PIO (zero preferred lifetime).
>
> Ed/
>
> *From:* Ole Troan [mailto:otroan=40employees.org@dmarc.ietf.org]
> *Sent:* Monday, November 21, 2022 6:53 PM
> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
> *Cc:* Ted Lemon <mellon@fugue.com>; IETF v6ops WG <v6ops@ietf.org>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> Eduard,
>
>
>
> I think you confuse addressing with routing.
>
>
>
> O.
>
>
>
> On 21 Nov 2022, at 16:39, Vasilenko Eduard <
> vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
>
> 
>
> Imagine that the uplink to the Carrier (DSL for example) is down.
>
> All hosts on the site should stop using the /48 prefix received from this
> carrier. It should happen preferably sub-second.
>
> How this negative information would propagate over the site? (multi-hop)
>
> Default PIO preferred time is 1 week. Fernando has the intention to change
> it to 2hours – still pretty bad.
>
> The resolution by the current ND is very bad.
>
> Eduard
>
> *From:* Ted Lemon [mailto:mellon@fugue.com <mellon@fugue.com>]
> *Sent:* Monday, November 21, 2022 6:30 PM
> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
> *Cc:* IETF v6ops WG <v6ops@ietf.org>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> The DHCPv6 server could send a notification to the DHCPv6 client if we are
> concerned about this. But it’s not clear to me that we should be. If you
> think we should be, you need to actually make a case for that, not just
> assert that it’s so.
>
>
>
> Op ma 21 nov. 2022 om 08:52 schreef Vasilenko Eduard <vasilenko.eduard=
> 40huawei.com@dmarc.ietf.org>
>
> Hi all,
>
> I do not understand how DHCP-PD may be used for prefix distribution inside
> the site.
> Because uplink could go down.
> Should be some signaling to all routers on site that the prefix is not
> available anymore (and should be deprecated on all links).
> But DHCP is stateless in principle.
> This "flush renumbering problem" would be pretty difficult to fix.
> It would kill MHMP completely.
>
> Eduard
> -----Original Message-----
> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
> Sent: Friday, November 18, 2022 9:02 PM
> To: Timothy Winters <tim@qacafe.com>; IPv6 Operations <v6ops@ietf.org>
> Subject: Re: [v6ops] Updating RFC 7084
>
> On 19-Nov-22 03:47, Timothy Winters wrote:
> > Hello,
> >
> > I've started a draft to update RFC 7084 to support prefix delegation on
> the LAN interfaces.  The current state of IPv6 in home networks is ISP are
> assigning prefixes of appropriate sizes but they currently are under
> utilized due to the lack of prefix delegation on LAN interfaces.
> >
> > This draft is an attempt to add that support to the draft.
> >
> > https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/
> > <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>
> >
> > This is only an update to 7084 at the moment, there has been some
> discussion on the snac working group about leveraging this work as well.
> >
> > One item being discussed is this currently doesn't solve multi-homed
> networks.
>
> As a historical note, we've spent a lot of time in the past on
> multi-homing and more or less failed (and the HOMENET approach was designed
> for home nets, not for enterprises where the problem is probably more
> important).
>
> To summarise what I've said over on SNAC:
>
> 1. If we're going to mention PvDs in the 7084 update, I think we should
> also mention RFC 8028. It isn't that a CE router should necessarily support
> 8028, but that in a network that does implement 8028 on its subnet routers,
> the following part of 8028 applies:
>
> 2.2.  Expectations of Multihomed Networks
>
>     Networking equipment needs to support source/destination routing for
>     at least some of the routes in the Forwarding Information Base (FIB),
>     such as default egress routes differentiated by source prefix.
>     Installation of source/destination routes in the FIB might be
>     accomplished using static routes, Software-Defined Networking (SDN)
>     technologies, or dynamic routing protocols.
>
> Those egress routes of course lead to CE routers.
>
> (There is some other thinking about this topic in
> draft-vv-6man-nd-support-mhmp).
>
>     Brian
>
>
> >
> > I welcome any feedback about the proposal.
> >
> > ~Tim
> >
> > _______________________________________________
> > 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
>
>