Subject: (ION) re: NHRP flow extension draft

From: [email-masked]
Date: Thu, 02 Jul 98 16:17:46 -0400

Lou, Robb, 

Some thoughts on your draft on the NHRP flow extension ...

a. Since policy rules administered at NHSs are typically quite static, 
could a possibly simpler approach be to have a ``one-time download'' of 
policy rules from NHSs to their registered NHCs (instead of the proposed 
approach of including flow definitions in each resolution request/reply) ?
(this would require a consistent or identical configuration of rules at
different NHSs though since each NHS only downloads rules to its served NHCs.
However that may not be too restrictive specially in an MPOA type campus 
environment. Also NHSs would have to send new downloads every time policy 
rules were re-administered).

As you can imagine, there will be several advantages (and some 
disadvantages) of that approach over your proposed approach. That approach
would arguably also be nice in an MPOA type environment. Any 
thoughts ? Would it be useful to have some sort of appendix comparing 
that sort of approach to this one ? 

b. The proposed approach does not allow for NHSs to insert additional 
flow extensions into resolution request/reply messages. So they have to 
decrease the scope of the only available flow extension in a sufficiently 
conservative manner. Greater shortcutting could have been achieved
with multiple flow extensions ... (even with approach a.,  multiple 
policy rules can easily be downloaded in order to maximize shortcutting). 

c. It would probably be quite useful to have a section with some 
examples to illustrate the modification of the policy scope as a request
passes from NHS to NHS ... 

d. Maybe an appendix on the relevance of this extension to MPOA networks 
would be useful ?

Thanks.
Sanjeev.

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Lou Berger <[email-masked]>
Date: Mon, 06 Jul 1998 12:20:17 -0400

Sanjeev, 
	Thanks for the comments.  My responses are included below.

At 04:17 PM 7/2/98 -0400, [email-masked] wrote:
> approach of including flow definitions in each resolution
request/reply)?
> (this would require a consistent or identical configuration of rules
> at different NHSs though since each NHS only downloads rules to its
> served NHCs.  However that may not be too restrictive specially in an
> MPOA type campus environment. Also NHSs would have to send new
downloads
> every time policy rules were re-administered).
> 
> disadvantages) of that approach over your proposed approach. That
> approach would arguably also be nice in an MPOA type environment. Any

We briefly discussed such an approach.  There were two main reasons we
didn't follow this approach.  One issue is that this would be a radical
change from current NHRP processing. While the protocol formats would
mostly be reused, actions taken to generate and process messages would
have little similarity to current NHRP implementations.  With the
resulting changes it's not clear if we really end up with the same
protocol. 

The second issue is policy control/enforcement.  By maintaining the
refresh and transit NHS processing model we preserve the ability for
any router/NHS to enforce policy barriers and to update those barriers
during operations. 

There certainly are some advantages to the "one-time" model you
mention.  If the WG feels that this is an alternative approach is not
too radical and that it should be discussed in detail, then we should
do so.

> decrease the scope of the only available flow extension in a
> sufficiently conservative manner. Greater shortcutting could have
been
> achieved with multiple flow extensions ... (even with approach a.,
> multiple policy rules can easily be downloaded in order to maximize
> shortcutting).

By allowing only more conservative policies we presume that
routers/NHSs "closer" to the source have better policy information.
The described approach also preserves the policy control/enforcement
models provided by today's routers.  (Downstream routers can't generate
traffic filtered upstream even when they have liberal/no policies.)

> examples to illustrate the modification of the policy scope as a 
> request passes from NHS to NHS ...
> 

good point.

> d. Maybe an appendix on the relevance of this extension to MPOA 
> networks would be useful ?
> 

Our feeling was that this is work that belonged in the ATM Forum and
that we'd pursue it there.  

Lou