The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199601291824.KAA06231@hubbub.cisco.com>, Yakov Rekhter writes:
> Curtis,
> 
> > 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).
> 
> I question the relevance of these examples. Truncating AS_PATH
> in BGP, or dropping metric in DV is *well-known* to produce
> forwarding loops by itself, with neither NHRP nor ATM involved. 
> 
> So, why the examples that illustrate how truncating AS_PATH
> in BGP or dropping metric in DV could result in forwarding loops
> should be included in the IP ATM Framework in the section that
> talks about NHRP ? 
> 
> Yakov.


Yakov,

This example is relevant to NHRP because it details the consequences
of the misuse of NHRP.  Such misuse has been discussed and advocated
by numerous people in the ROLC and IPATM WGs in the past, and
indications are NHRP continues to be misrepresented by industry
marketing and sales people who are not closely following the IPATM WG.

I think this is sufficient reason to 1) leave the example in the
document, 2) continue to reference the possibility of routing loops in
the context of misuse of NHRP.

Thanks you for helping provide text clarifying the applicability of
this problem to NHRP.

Curtis


In summary - you appear to have no further technical objection now that you
have been provided IP addresses, AS numbers, routing protocols, and
other details for the examples, using the figures exactly as they
appear in the current draft, and following the more consice (but more
vague, not assigned addresses etc) wording in the current text
describing the route loop scenarios.  You have agreed to the
following text:

   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.

Your comment on this was "These two paragraphs are fine by me. And I
think this is all what the document should say".

You have questioned the relevance, but not the technical validity of
the following paragraph and the example (as quoted in your response
above in the main body of this message):

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

As I previously stated "This wording acknowledges that NHRP works if
correctly used.  It also acknowledges that NHRP will not work in some
topologies if it is not properly used and briefly explains what to
avoid.  The example of what to avoid follows".

You have been the only person objecting.  Ross Callon, Eric W. Gray,
Dimitry Haskin, and Grenville Armitage have made comments.  None of
them indicated a desire to drop the example or indicated that it may
not be relevant to NHRP, and all four made comment supporting the
technical validity of the example.  Joel Halpern made some requests
for clarification, cited the loop free operation of NHRP when it is
not misued.  No one opposed my comments that the proper use of NHRP is
not clearly documented in any ROLC draft up to the present, and some
statements tend to suggest use of NHRP in ways that would form loops
with no warning.

Since you have no remaining technical objection, I think it is time
for you to accept rough consensus on the issue of whether this is
relevant.  I will remind you that you have asked others to accept
rough consensus in other WGs.  For example, there remain two people
objecting on to the advancement of a draft of yours in CIDRD, yet
advancement is being recommended.

Interestingly enough, the section entitled "Extensions to IP Routing"
had not not previously mentioned NHRP at all by name.  NHRP was not
mentioned anywhere in the section or the figure or the description of
the looping example.  The prior text only spoke in general of
"[proposals for cut-through routing] 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".  You have in numerous
email messages agreed that the above is true as stated.

Since this still holds to true in general for proposals for
cut-through routing, and your prior objections have been satisfied by
the additional detail on the routing loop provided to the IP/ATM list,
I have left that text intact.  I have added the text that you have
just agreed to which clarifies the situation with regard to NHRP and
the usage of NHRP.  I have added the text that explains why the
following example is relevant to NHRP in addition to "[proposals for
cut-through routing in general] 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", as previously stated.

I also added to the Acknowledgments "Yakov Rekhter of Cisco provided
valuable comments leading to the clarification of normal loop free
NHRP operation and the potential for routing loop problems only with
the improper use of NHRP".