Re: Final rolc minutes

["James V. Luciani" <[e-mail]>]

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

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.

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

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