RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC)

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Hemant,

> -----Original Message-----
> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
> Sent: Tuesday, January 05, 2010 2:12 PM
> To: Templin, Fred L; Fred Baker (fred); v6ops@ops.ietf.org
> Cc: kurtis@kurtis.pp.se; rbonica@juniper.net
> Subject: RE: CPE router acting as host on its WAN interface (RE: draft-ietf-v6ops-ipv6-cpe-router-
> 03.txt WGLC)
> 
> 
> 
> >-----Original Message-----
> >From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> >Sent: Tuesday, January 05, 2010 12:00 PM
> 
> >The IsRouter discussion was on this list (v6ops); not
> >the 6man list. Maybe you were talking about a different
> >discussion on the 6man list?
> 
> No.  I am talking about "Stub Router Advertisements in IPv6
> NeighborDiscovery" that was being discussed in the 6man mailer between
> you, Bob Hinden and Thomas Narten.  One example of your IsRouter
> discussion is an email with following date, time, etc. to the 6man list
> of ipv6@ietf.org.
>
> "Sent: Tuesday, November 24, 2009 11:37 AM"
>
>
> >The final sentence of Appendix D also says:
> 
> >  "In these cases, a subsequent Neighbor
> >   Advertisement or Router Advertisement message will set
> >   the correct IsRouter value."
> 
> >but if the CPE will not send any RA messages over its
> >WAN interface then the NA is the only other option for
> >setting the correct IsRouter value.
> 
> Yes, the CE Rtr is not expected to send any RA over its WAN interface
> upstream to the SP.  So what's the concern if the SP router upstream of
> the CE Rtr has an incorrect IsRouter value temporarily?  When the CE Rtr
> is a requesting router for delegated prefix, the SP router knows the CE
> Rtr is a router.  Note the CE Rtr is both a host and a router.

Does the SP router know enough to update the neighbor
cache entry for a CE router and and change IsRouter from
FALSE to TRUE based only on the act of delegating a prefix?
Where is that behavior specified?

> >If a provider router garbage-collects a FIB entry because
> >it sees that IsRouter in the nexthop nbr cache entry is
> >FALSE, the FIB entry is gone and there is no route to the
> >CE router's prefixes. That is what I am meaning to say
> >regarding interoperability issues and circumstances.
> >First, the delegating router need not be co-resident on
> >the provider router that sends RA to the CE router; it
> >could be behind a chain of relays instead. Second, just
> >because the delegating router (and I guess also any
> >relays in the chain) come to know that the CE router is
> >a requesting router does not necessarily mean that the
> >provider router will know enough to reach into its kernel
> >and set the IsRouter flag in the nbr cache entry to TRUE.
> >Or, maybe that behavior is specified somewhere that I
> >didn't see?
> 
> The FIB does NOT include the Neighbor cache, so why are you discussing
> "nbr cache entry"?

No; the FIB does not include the neighbor cache and that is
not what I said. The neighbor cache is a per-interface data
structure, and FIB entries maintain a "next_hop" that points
to a neighbor cache entry. If a FIB entry garbage-collection
algorithm examines the IsRouter flag in the neighbor cache
entry to which the FIB entry points, and the flag is FALSE,
the FIB entry may be incorrectly purged.

> Further, since DHCPv6 (used for requesting a
> delegated prefix) travels over a link-local address, the CE Rtr will see
> only the SP router that is in the CE Rtr link-local domain.  Therefore
> any discussion of relay and chains is moot.  Sorry, I still don't see a
> clear problem definition from you.

I don't want to address the DHCP relay point because it
is a distraction from the core problem definition, which
I provided above.

Fred
fred.l.templin@boeing.com

> Hemant