Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt

["Mudric, Dusan (Dusan)" <[e-mail]>]

Hi Jen,

Please see inlined. 

Regards,
Dusan.

> -----Original Message-----
> From: Jen Linkova [mailto:[e-mail]]
> Sent: Monday, March 05, 2018 10:03 PM
> To: Mudric, Dusan (Dusan)
> Cc: Gert Doering; [e-mail]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt
> 
> On Sat, Mar 3, 2018 at 9:29 AM, Mudric, Dusan (Dusan)
> <[e-mail]> wrote:
> > " hosts to select the correct source address based
> >>    on the desired egress ISP for that traffic."
> > will not work in the load sharing example. Unlike the router, when the host
> has two prefixes it does not know which one is 'desired'.
> 
> It's not 'desired', it's 'can be used' (== 'communication is
> possible'). In the load sharing scenario both uplinks can be used so
> hosts are free to select addresses in all prefixes.
> 
> Please note that we are not trying to make hosts *full* aware of all
> paths properties, traffic engineering is not in scope. All we are
> doing is signalling to hosts which addresses would provide network
> connectivity (if the ISP uplink is down, there is no network
> connectivity for source addresses in that prefix).
> If a hosts has received a signal that there is more than one prefix is
> available (== network is capable of sending packets with that source
> address out), then the host is using RFC6724 to select the addess.

[[Dusan]] 
[[Dusan]] What I am trying to say is RFC6724 does not know which ISP is preferred, when both prefixes are advertised. If a router will have a new policy to know the ISP preference, the preference should be passed to the host, and RFC6724 should be enhanced to use that preference. This will facilitate a network management where one router policy is configured and all the hosts benefit from that knowledge. When all this is put together, with multiple prefixes, a host will select the preferred source address and a router will use it to forward packet to preferred ISP. If the host part is not addressed, the host will 'randomly' (current RFC6724 will not use the prefix preference) select the source address and packets might go to either ISP1 or ISP2.


> 
> >Possible option is to assign a prefix preference in RA.
> 
> Kind of a combination of Rule 5.5 and router preference? Both of them
> are not widely implemented, that's the whole point of the draft.

[[Dusan]] 
[[Dusan]] Exactly. Since both prefixes are assigned by two next hops, Rule 5.5 should be enhanced to use the preferred prefix. Standards should not address the current deployment state, but provide a better solution. I would not focus on what is not currently implemented but rather on what should be implemented. 

> 
> > "Actually the new text is completely missing the point. Selecting the right
> source address *to select the egress ISP to use* is
> > the part not addressed in host stacks at all yet"
> > If so, the draft needs to make it clear.
> 
> The introduction says:
> "However using IPv6 PA blocks
>    in multihoming scenario introduces some challenges, including but not
>    limited to:
> 
>    o  Selecting the correct uplink based on the packet source address;
> 
>    o  Signaling to hosts that some source addresses should or should not
>       be used (e.g. an uplink to the ISP went down or became available
>       again).
> "

[[Dusan]] 
[[Dusan]] These two cases are valid but they don't cover ".Selecting the right source address *to select the egress ISP to use*". This would be a third problem to address. This comes before the first bullet (the source address needs to be chosen first, then the correct uplink). The second bullet talks about the connectivity issues, where a prefix is removed when a link is down. We need to mention the source address selection when both links are up.

> 
> >The underlined assumption is that the host selected the right source address
> and the router uses that address to send a packet to a right ISP.
> 
> It's the first bullet point, but the second one addresses your
> concern, I believe.
> 

[[Dusan]] To some extent. It needs to be clarified. And the draft should state if, how and where "Selecting the right source address *to select the egress ISP to use*" is done.



> >
> >
> >> -----Original Message-----
> >> From: Gert Doering [mailto:[e-mail]]
> >> Sent: Friday, March 02, 2018 1:57 PM
> >> To: Mudric, Dusan (Dusan)
> >> Cc: Jen Linkova; [e-mail]
> >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt
> >>
> >> Hi,
> >>
> >> On Fri, Mar 02, 2018 at 04:21:32PM +0000, Mudric, Dusan (Dusan) wrote:
> >> > In Abstract:
> >> >
> >> > "The problem of enterprise multihoming without address
> >> >    translation of any form has not been solved yet as it requires both
> >> >    the network to select the correct egress ISP based on the packet
> >> >    source address and hosts to select the correct source address based
> >> >    on the desired egress ISP for that traffic."
> >> >
> >> > Should be:
> >> > "The problem of enterprise multihoming without address
> >> >    translation of any form has not been solved yet as it requires
> >> >    the hosts to select the correct source address based
> >> >    on a destination address for that traffic,
> >> >    the hosts to select a first hop router based on the packet
> >> >    source address, and the network to select the correct egress ISP based on
> >> the packet
> >> >    source address"
> >>
> >> Actually the new text is completely missing the point.  Source address
> >> selection *for a destination address* is something already addressed
> >> nicely (RFC6724).
> >>
> >> Selecting the right source address *to select the egress ISP to use* is
> >> the part not addressed in host stacks at all yet.
> >>
> >> The network part "select egress based on proper source address" is halfway
> >> solved with the homenet protocol suite (source address dependent babel,
> >> hncp, etc.) - but that is stuff not usually found on Enterprise routers.
> >>
> >> Gert Doering
> >>         -- NetMaster
> >> --
> >> have you enabled IPv6 on something today...?
> >>
> >> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> >> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> >> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> >> Tel: [phone]           USt-IdNr.: DE813185279
> 
> 
> 
> --
> SY, Jen Linkova aka Furry