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

["Hemant Singh (shemant)" <shemant@cisco.com>]

Fred,

Humble apologies for missing one step in our description below.  Please
change the following text from our email

FROM:

"The Prefix List returns the destination for the host behind the CE Rtr
as off-link.  Then the Neighbor Cache is looked up - since you said, the
Neighbor Cache entry is not nuked, the lookup succeeds and the packet is
sent out and also a Destination Cache entry is created."

TO

"The Prefix List returns the destination for the host behind the CE Rtr
as off-link.  Then the Default Router List is looked up and that lookup
will succeed. Then the Neighbor Cache is looked up - since you said, the
Neighbor Cache entry is not nuked, the lookup succeeds and the packet is
sent out and also a Destination Cache entry is created."

Hemant

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Hemant Singh (shemant)
Sent: Wednesday, January 06, 2010 3:33 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)

Fred,

For any further discussion, may I suggest using terminology from RFC
4861, otherwise we spend more time to understand each other.  I keep
saying the problem is temporary (yes, that is a pause in traffic flow)
and the problem will be fixed automatically but you send a reply back
saying "no the problem is not fixed automatically".  Also, my statements
are based on what I have been able to understand thus far from your
emails - this understanding may not be correct.  If you use the team
FIB, please define in terms of conceptual data structs defined in RFC
4861.  Wes tells me what you refer to as FIB is the Destination Cache.
But to me, the FIB is a collection of the Destination Cache, the Prefix
List, and the Default Router List.  Now we both think that what you call
as FIB is the routing table on the SP rtr.  Further, I believe what I
call as the Neighbor Cache, you refer to it as nbr. 

Now if a routing table entry is deleted from the SP Rtr, then it is
indeed a problem for which routing protocols are required.  However,
note that the SPs do not want any routing protocols between the CE Rtr
and the SP Rtr.  So then, really, it's a question of the SP Rtr be
designed properly as per SP Rtr quality standards and have its routing
table cache be sized appropriately. 

Please also note, if it's a routing table entry that got nuked, the
Conceptual Sending Algorithm of RFC 4861 does not apply to routing of
packets by the SP Rtr - the algorithm is applicable only to a host.
However, if the SP Rtr sources a packet destined to, say, a host behind
the CE Rtr, then the Conceptual Sending Algorithm is legal to use and
here is how it would work in your situation.  Let's say the Destination
Cache has the destination nuked. The Conceptual Sending Algorithm looks
up the destination in the Prefix List.  The Prefix List returns the
destination for the host behind the CE Rtr as off-link.  Then the
Neighbor Cache is looked up - since you said, the Neighbor Cache entry
is not nuked, the lookup succeeds and the packet is sent out and also a
Destination Cache entry is created. 

So again, as per Wes's email, the summary is still that this problem you
describe just needs a properly designed SP Rtr. Your problem does not
need any changes be made to the CE Rtr draft nor any changes to the ND
RFC nor any other RFC.

Thanks,

Hemant & Wes