Re: Final rolc minutes

["Eric W. Gray" <[e-mail]>]

Jim,

You wrote:
> 
> > >
> > > I was just re-reading the NHRP draft, and thinking about some routing issues.
> > > I am concerned about the use of the Source NBMA and Source Protocol Address
> > > fields in the request.
> > >
> > > Two cases come to mind:
> > > 1) The routing protocol is BGP.  The outward path does not have a policy
> > >    restriction on shortcuts, but the assymettric reverse path does.
> > >    (Someone is being very "careful" about what paths they advertise.)  As
> > >    currently defined, the destination can learn the sources ATM address,
> > >    and attempt to establish the VC to him anyway, avoiding the fact that
> > >    an NHRP request in the reverse direction would hit a policy terminator
> > >    who would respond with his own address.
> >
> >
> > I believe that the concept of a logical NBMA subnetwork prevents the first
> > problem.  The second paragraph from the top of page 7 states that NHRP query
> > and response messages cannot cross logical NBMA subnet boundaries and - from
> > my reading - NBMA logical subnets are defined in suchg a way that an extant
> > policy terminator IS the NBMA logical subnet boundary.
> 
> NBMA logical subnets are a gross form of policy.  They are not intended to
> prevent policy which says, "you cannot setup a cuthrough to this ATM address"
> even though you may be in the same logical NBMA.  Clearly if your switch is
> implementing some policy (e.g., sniffing source address IEs) then you will just
> reject the call anyway even though you are in the same NBMA logical subnet.
> The real answer to "1" above is that you should not cache the source address
> information as a rule and if you do then caveat emptor!
> 
> The following is from nhrp spec:
> :[Note: An Next Hop Resolution Reply can be returned directly to the
> :Next Hop Resolution Request initiator, i.e., without traversing the list of NHSs
> :that forwarded the Next Hop Resolution Request, if all of the following criteria
> :are satisfied:
> :
> :(a) Direct communication is available via datagram transfer
> :    (e.g., SMDS) or the NHS has an existing virtual circuit
> :    connection to the Next Hop Resolution Request initiator or is
> :    permitted to open one.
> :(b) The Next Hop Resolution Request initiator has not included the
> :    NHRP Reverse NHS record Extension (see Section 5.3.5).
> :(c) The authentication policy in force permits direct
> :    communication between the NHS and the Next Hop Resolution
> :    Request initiator.
> This implies (yes... not explicit) that setting up a VC to merely do a resolution reply
> is permitted.  So Joel's concern is valid.  I complained about this in Danvers
> and noone seemed to care (my concern was VC usage but the MPOA example is another
> reason).
>

Look, I read the spec.  Part of the confusion might be that I was referring to
line, paragraph and page numbers based on draft 7 (which is the most recent
official draft since, as far as I know, you have not yet posted draft 8).  I
think that saying that the text above implies that setting up a VC to make a
reply assumes that the "originator" is determined by NBMA address - which is
specifically countered a few paragraphs later - and this is reaching just a
little.

If you change the above text by changing (a) to read as follows:

"(a) Direct communication is available via datagram transfer
     (e.g., SMDS) or the NHS has an existing virtual circuit
     connection to the Next Hop Resolution Request initiator
     (as determined based on source protocol address) or is
     permitted to open one."


> 
> WRT the second point Joel raised,
> > > 2) The station issuing the query is doing so on behalf of a bridge-like
> > >    device which is the actual ingress to the ATM.  (Yes, there is some
> > >    clever layering here.  Come to MPOA for fun and confusion.)  As such,
> > >    the internetwork source address is the routing entity issuing the
> > >    query request.  However, in order to cause VCs to match up properly,
> > >    the ATM level source address is that of the bridge-like device which
> > >    will make use of this information.  Therefore,
> > >    A) caching this pairing will not produce good information
> > >    B) sending the response over an existing short-cut will be problematic.
> > The first paragraph at the top of the same page implies that a response must
> > be sent back to its originator based on source protocol address which should
> > eliminate 2B.
> Note the exception I already pointed out from the NHRP spec so 2B problem is not
> really eliminated at all.
>

The paragraph I am referring to says:

  "NHRP Registration Requests, NHRP Registration Replies, NHRP Purge
   Requests, NHRP Purge Replies, and NHRP Error Indications follow the
   routed path from sender to receiver in the same fashion that Next Hop
   Resolution Requests and Next Hop Resolution Replies do.  That is,
   "requests" and "indications" follow the routed path from Source
   Protocol Address (which is the address of the station initiating the
   communication) to the Destination Protocol Address.  "Replies", on
   the other hand, follow the routed path from the Destination Protocol
   Address back to the Source Protocol Address with the exceptions
   mentioned above where a direct VC may be created."

Also, the last sentence of the first paragraph in section 3 (draft 7) says:

  "The responding station generates a Next Hop Resolution Reply using the
   source address from within the NHRP packet todetermine where the Next
   Hop Resolution Reply should be sent."

If this sentence were further clarified to say "Source Protocol Address"
verses "source address", this should be sufficient.

> 
> > Perhaps wording should be inserted in section 2 to the effect that an NHS may
> > have multiple NBMA addresses (may be deployed as a distributed implementation)
> > and not all of these addresses may be appropriate when communicating with the
> > NHS entity identified by the source protocol address - consequently, caching
> > of source protocol and NBMA address pairs in Next Hop Resolution Requests is
> > not permitted.  This should address the concerns you have with 2A above.
> This is a good idea.  I am also in favor of saying that you should never set
> up a cut-through to merely send a reply and that you should never listen
> promiscuously to the source address information.  Listening to the source
> information is at best an optimaztion and at worst a bug with potentially
> "interesting" side effects.
>

Rather than say you should never listen promiscuously (hard to enforce), it
might be better to say assumptions made on the basis of promiscuous listening
to source address information may be invalid for shortcut VC establishment,
NHRP message forwarding and routing.  Otherwise, I agree to what you say above.

> 
> Regards,
> --Jim Luciani
> __________________________________________________________________________
> James V. Luciani                                   [e-mail]
> Bay Networks, Inc.                                  voice: [phone]
> 3 Federal St., BL3-04                               fax:   [phone]
> Billerica, MA 01821

--
Eric Gray