The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199601231544.HAA03092@hubbub.cisco.com>, Yakov Rekhter writes:
> Curtis,
> 
> > Lets compromise on the wording:
> > 
> >    NHRP assumes that routers do run routing protocols (intra and/or inter
> >    domain) and/or static routing.  NHRP further assumes that forwarding
> >    tables constructed by these protocols result in a steady state
> >    loop-free forwarding.  Note that these two assumptions do not impose
> >    any additional requirements on routers, beyond what is required in the
> >    absence of NHRP.
> > 
> >    NHRP runs *in addition* to routing protocols, and provides the
> >    information that allows to eliminate multiple IP hops (the multiple IP
> >    hops result from the forwarding tables constructed by the routing
> >    protocols) when traversing an NBMA network.  The IPATM and ROLC WGs
> >    have both expended considerable effort in discussing and coming to
> >    understand these limitations.
> 
> These two paragraphs are fine by me. And I think this is all what the
> document should say.

Good.  You agree then that "The IPATM and ROLC WGs have both expended
considerable effort in discussing and coming to understand these
limitations".  I do not want to see that understanding lost so I want
to document the limitations that we spent so much time gaining an
understanding of.

> >    The combination of NHRP and static routing alone cannot be used in
> >    some topologies where some of the destinations are served by multiple
> >    routers on the NBMA.  
> 
> If static routing does not result in a loop free forwarding, then
> I've yet to see an example how the combination of NHRP and static
> routing would cause forwarding loops. And if static routing does
> result in forwarding loops, then NHRP has nothing to do with it.
> 
> >    The combination of NHRP and an intra-AS routing
> >    protocol that does not carry inter-AS routing path attributes alone
> >    cannot be used in some topologies in which the NBMA will provide
> >    inter-AS transit connectivity to destinations from other AS served by
> >    multiple routers on the NBMA.  Figure 4 provides an example of the
> >    routing loops that may be formed in these circumstances.
> 
> Your example illustrates how persistent forwarding loops could be
> formed by either (a) truncating AS path information in BGP, or (b)
> dropping IGP metric (see below). These forwarding loops could be formed in th
> e
> absence of NHRP as well. So, what it has to do with NHRP ?

You are not questioning the technical accuracy of these examples at
all, here or below.  Below you are simply stating what the solution
is.  The solution in one case is to make sure the PV path information
is not lost (the currently favored solution is to run BGP in addition
to NHRP) and in the other two cases make sure DV metrics are not lost
(the currently favored solution is to run an IGP in addition to NHRP).

This does not contradict the statements as they now stand in
draft-ietf-ipatm-framework-doc-06.

   This problem occurs with proposals that attempt to carry reachability
   information, but do not carry full path attributes (for path vector
   routing) needed for inter-AS path suppression, or full metrics (for
   distance vector or link state routing even if path vector routing is
   not used) for intra-AS routing."

However, I have agreed to change the wording to reflect the current
thinking (which is not clearly stated in either the current NHRP or
rtr-to-rtr NHRP drafts).  I will not completely drop the examples
since they have been highly useful in illustrating and therefore
understanding the limitations of NHRP.

I do not think it is the consensus of this WG to drop the example.

Curtis


> > Here are the cases covered:
> > 
> > 	Case 1:  inter-AS
> 
> [ text deleted...]
>  
> > before L1 breaks:
> > 
> >   Route flow:
> > 	10.0.3.0/24 AS 65103
> > 		-> R3 (AS path 65033 65103)
> > 	path A:
> > 		-> R2 (AS path 65102 65033 65103)
> > 		-> R1 (truncate path to 65101)
> > 	path B:
> > 		-> R7 (AS path 65104 65033 65103)
> > 		-> R6 (AS path 65101 65104 65033 65103)
> > 	path C:
> > 		-> R9 (AS path 65099 65033 65103)
> > 		-> R8 (AS path 65088 65099 65033 65103)
> > 		-> R1 (truncate path to 65101 but R1 prefers R2)
> 
> It is well known that truncating AS path in BGP could result in
> persistent forwarding loops. Your examples provide an illustration of
> this issue with BGP. But what is has to do with NHRP ?
> 
> > 
> > Case 2:  intra-AS
> > 
> > No AS numbers.
> > DS0 links are cost 10
> > R8-R9 is cost 20
> > 
> > before L1 breaks:
> > 
> >   R3 (subnet3 is cost 0)
> > 	path A:
> > 		-> R2 (cost 1)
> > 		-> R1 (cost is lost - set to 5)
> 
> If R1 and R2 exchange RIP information, then why the cost is lost ?
> And if R1 and R2 do not exchange RIP information, then why would
> an NHRP Request originated by R1  go to R2 ?
> 
> > 	path B:
> > 		-> R5 (cost 1)
> > 		-> R4 (cost 11)
> > 	path C:
> > 		-> R7 (cost 1)
> > 		-> R6 (cost 11)
> > 	path D:
> > 		-> R9 (cost 1)
> > 		-> R8 (cost 21)
> > 		-> R1 (cost is lost - set to 5 or 25)
> 
> If R1 and R8 exchange RIP information, then why the cost is lost ?
> And if R1 and R8 do not exchange RIP information, then why would
> an NHRP Request originated by R1 go to R8 ?
> 
> Yakov.