Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

[Brian E Carpenter <[e-mail]>]

On 2011-03-23 09:41, Hemant Singh (shemant) wrote:
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Brian E Carpenter
> Sent: Saturday, March 19, 2011 3:34 PM
> To: Mikael Abrahamsson
> Cc: IPv6 Ops WG
> Subject: Re: [v6ops] I-D
> Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt
> 
> 
>> Border Router Discovery Protocol? See draft-boot-brdp-framework
> 
> I am not convinced that the document above, nor shim6 nor any other
> source-based routing solution is needed just yet for the IPv6 CE Router.

I agree. BRDP is far from cooked as an IETF solution. Shim6 is standardised,
but requires no special action by the CE router anyway.

> Let's first solidify the multihomed requirements in the home for the
> IPv6 CE router and then we can look at solutions.  

I assume you are now talking about a future draft and not about
cpe-router-bis?

> We do hope to
> solidify the requirements during the next few weeks.  For now I have
> snipped the first multihomed diagram in the document mentioned above and
> analyzed the network using existing protocols available. 
> 
> 
>           /^^^^^^^^^^^^^^^^^^^^^^\
>          /                        \
>         {       The Internet       }
>          \                        /
>           \______________________/
>            /                    \
>           /(2001:08db:100::/40)  \(2001:8DB:200::/40)
>      +=======+              +=======+
>      [ ISP_1 ]              [ ISP_2 ]
>      +=======+              +=======+
>          |                       |
>          |(2001:8DB:101::/48)    |(2001:8DB:201::/48)
>    +--------+              +--------+
>    | BR_101 |              | BR_201 |
>    +--------+              +--------+
>      | FE80::101/64            | FE80::201/64
>      | 2001:8DB:101:1::101/64  | 2001:8DB:201:1::201/64
>      |                         |
>     -+---------------------+---+-
>                            |
>    2001:8DB:101:1::1234/64 | 2001:8DB:201:1::1234/64
>              FE80::1234/64 |
>                      +-----------+
>                      | Host_1234 |
>                      +-----------+
> 
> Let's consider the case that Host_1234 has to send a packet to a
> destination D where D does not match any of 2001:8DB:101::/48 or
> (2001:8DB:201::/48.  Also, let's assume it's only the BR_201 router path
> that has a route to send the packet to destination D.  However, the
> Host_1234 sent the packet with destination D with src of
> 2001:8DB:101:1::1234 and the packet reached BR_101. BR_101 does not drop
> the packet because BR_101 runs an IGP between itself and BR_201 and thus
> BR_101 knows that the packet can be forwarded to BR_201.  When BR_201
> receives the packet, BR_201 forwards the packet upstream to ISP_2.
> Also, when BR_101 forwards the packet to BR_201, BR_101 also sends a
> Redirect to Host_1234 to send packets to such a destination via BR_201.
> In the return path when some node in the Internet cloud replies to the
> packet sent from the home, the packet is returned to Host_1234 on the
> same path as the sent packet.  Alternatively, before the host sent out
> any packet, the host has received a MSR (RFC 4191) for a route to
> destination D and hence the host does not send the packet to BR_101 but
> instead sends the packet to BR_201.  
> 
> Thus between, an IGP, MSR/Redirect, the multihomed network issue above
> is resolved.  Also, if one does not want to use the Redirect, just send
> the MSR to Host_1234.

Again - this topic (and your analysis, if it's correct) seems to me to
belong in the multihoming-without-nat66 draft.

As I said a long time ago when MIF was first discussed, it seems that what
we need is to replace the concept of "default router" in the host stack
with a concept of "default router per prefix".

    Brian

    Brian