Re: [v6ops] Updating RFC 7084

[Ted Lemon <[e-mail]>]

In this scenario the stub router knows the router is deprecated. Why would
it not deprecate the prefix?

Op ma 21 nov. 2022 om 12:23 schreef Vasilenko Eduard <
[e-mail]>

> In-line
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:14 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> You’ve described a situation, not a real world scenario. How did the host
> wind up in this situation?
>
> *[EV] his stub router just joined some infrastructure where connections to
> 2 carriers were available. Hence, the stub router received 2 prefixes and
> announced 2 PIOs to the host*
>
> Why is the network configured this way?
>
>
> *[EV] The person managing infrastructure would like resiliency. He has
> connected one router to 2 Carriers. Then received /56 prefixes from both.
> It is not MHMP – It is one router connected to different carriers.*
>
> Why is it that only by deprecating the prefix can the host experience
> reliable connectivity?
>
>
> *[EV] The host may use the PIO as the source address that is not connected
> anymore to the owner (Carrier). The different carrier would always do a
> uRPF check to drop the packet from the wrong source address (belonging to
> the different carrier).*
>
>
>
> Op ma 21 nov. 2022 om 12:11 schreef Vasilenko Eduard <
> [e-mail]>
>
> The host had many PIOs (from many PA prefixes).
>
> One prefix has become outdated somewhere upstream (because the connection
> to the carrier is lost), but the information has not been propagated to the
> host (DHCP is not the best for negative information propagation).
>
> The host may still try to use a dead PIO despite the same host having
> another alive PIO.
>
> The end user is unhappy, he could not open the site, and he calls you for
> help.
>
> Ed
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 8:04 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *Subject:* Re: [v6ops] Updating RFC 7084
>
>
>
> Try to give us an example of an actual user experience that would be
> affected by the behavior you are concerned about. Describe the network
> configuration.
>
>
>
> The reason I am skeptical of your concern is that I have no idea what real
> world scenario is motivating it.
>
>
>
> Op ma 21 nov. 2022 om 12:02 schreef Vasilenko Eduard <
> [e-mail]>
>
> Hi Ted,
>
> I do not want to ignore you.
>
> But I am not capable to explain it differently.
>
> It looks so obvious…
>
> Eduard
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Monday, November 21, 2022 7:36 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>; Ole Troan <otroan=
> [e-mail]>
> *Subject:* 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 <
> [e-mail]>
>
> 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=[e-mail]]
> *Sent:* Monday, November 21, 2022 6:53 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* Ted Lemon <[e-mail]>; IETF v6ops WG <[e-mail]>
> *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=[e-mail]> 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:[e-mail] <[e-mail]>]
> *Sent:* Monday, November 21, 2022 6:30 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* IETF v6ops WG <[e-mail]>
> *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=
> [e-mail]>
>
> 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 <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: Friday, November 18, 2022 9:02 PM
> To: Timothy Winters <[e-mail]>; IPv6 Operations <[e-mail]>
> 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
> > [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
>
>