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: Wednesday, January 06, 2010 12: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.

Yes; I am referring to the routing table on the SP rtr;
the linux kernel calls this the FIB.

> Further, I believe what I
> call as the Neighbor Cache, you refer to it as nbr.

Almost - in the terminology I have used:

  nbr cache == Neighbor Cache
  nbr = Neighbor Cache Entry

I will try to stick as close as possible to RFC4861
terminology from now on.

> 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.

Yes, I understand that there are to be no routing
protocols between the CE and SP routers.

> So then, really, it's a question of the SP Rtr be
> designed properly as per SP Rtr quality standards

Where are those standards specified? And, do they say
that the SP router should ignore the IsRouter flag?

> and have its routing
> table cache be sized appropriately.

Size is not the issue; policy is the issue.

> 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.

I'm not concerned about the Conceptual Sending Algorithm of a
host. I am concerned about what happens when the SP router
needs to forward a packet to a host behind a CE router, but
there is no route because the route was removed due to the
SP router thinking the CE router is 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.

I saw your correction for this section, but this is not
the issue that concerns me. The issue that concerns me
is what happens if the SP router needs to forward a packet
to a host behind a CE router, but it doesn't have a route
because it mistakenly believes the CE router is a host.

> 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.

Somewhere it needs to be said that what you are calling
a "properly designed SP Rtr" needs to ignore the IsRouter
flag and not garbage-collect routes if IsRouter is FALSE.

Fred
fred.l.templin@boeing.com

> Thanks,
> 
> Hemant & Wes
>