Subject: RE: [NSIS] question for clarification

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 6 Aug 2002 09:01:05 +0100

hi dan, all,

some points:

firstly, i've long had a background assumption that it was not the role of NSIS as a transport protocol to influence/force/modify packet paths. Resource messages carried by NSIS might do this as a side effect, but NSIS itself has to be able to work in arbitrary environments (possibly taking advantage of special characteristics of those environments, of course).

on the other hand, i've been involved in enough conversations to realise that this assumption is not universally held (maybe i'm even in the minority). in any case, we should probably state something more concrete.

so, my take on dan's questions:
a) no, NSIS shouldn't do things to force/prefer symmetric routing
b) if there are good low-overhead ways to discover topological constraints i don't see why we shouldn't exploit them. the most important constraint would be that a host knew it was connected to the network over a point to point link.
c) i doubt that a bidirectional reservation would be simpler than individual unidirectional ones, rather you could do grouping to get the same effect with very little extra complexity. (i think this is essentially what packetcable does.) i think the current requirements encourage this as a possibility to the right extent already, however.

cheers,

robert h.

> -----Original Message-----
> From: Dan Grossman [mailto:[email-masked]]
> Sent: 05 August 2002 16:59
> To: [email-masked]
> Cc: jkchoi; Shahrier, Sharif M.; [email-masked]
> Subject: Re: [NSIS] question for clarification
> 
> 
> PacketCable 
> http://www.packetcable.com/specs/PKT-SP-DQOS-I03-020116.pdf has also
> specified RSVP extensions for bi-directional reservations, in 
> the context of IP
> telephony over cable.  They're taking advantage of some 
> unique topological
> limitations that constrain flows in opposite directions to 
> follow the same
> path.   I don't think you want to preclude this case any more 
> than you want to
> require that flows always be constrained to follow the same 
> path (or, actually,
> reverse paths).   Questions:
>   should we  do anything special in the signalling protocol 
> to force or prefer
> the same path?
>   would it be desirable to discover those kinds of 
> topological constraints and
> take advantage of them in the signalling protocol where they exist?
>   would  a style of bidirectional reservation that takes 
> advantage of reverse
> paths would be so much simpler than one that assumes 
> non-reverse paths that it's
> worth being a special case in the signalling protocol?
> 
> Marcus Brunner wrote:
> 
> > Concerning bi-directional,
> >
> > In the requirements draft we currently have
> > --------------
> > 5.7.4 Uni / bi-directional reservation
> >
> > Both unidirectional as well as bi-direction reservations 
> must be possible.
> > With bi-directional reservations we mean here reservations 
> having the same
> > end-points. But the path in the two directions does not 
> need to be the same.
> >
> > The goal of a bi-directional reservation is mainly an 
> optimization in terms
> > of setup delay. There is no requirements on constrains such 
> as use the same
> > data path etc.
> > -------------
> >
> > It is important to note that we explicity mention that 
> bi-directional is
> > meant to have only the same end-points, but does not need 
> to follow the
> > same path. This is follwing the Internet Routing ARchitecture.
> >
> > Any constraint to force bi-directional reservations on the 
> same path are
> > very complex and not workable in many cases.
> >
> > Marcus
> >
> > --On Montag, 5. August 2002 01:43 +0900 jkchoi 
> <[email-masked]> wrote:
> >
> > > I just read this mail. It is me to raise a question for 
> bi-directional
> > > QoS signaling at nsis WG.
> > >
> > > For the further development of "A Framework for Bi-Directional QoS
> > > Signaling" presented at Yokohama meeting, it needs to 
> check the existing
> > > activities at mpls WG and ccamp WG to their signaling 
> protocols  (If time
> > > is available, check the signaling protocols developed by 
> ITU-T SG13 and
> > > ISO/OSI etc. even though it is not for IP network. You 
> can find some
> > > helpful mechanism to use for IP network.)
> > >
> > > It notes that
> > >
> > >  - uni-directional signaling on LDP/CR-LDP and 
> RSVP/RSVP-TE for MPLS
> > > network  - on-going for bi-directional signaling on 
> RSVP-TE and CR-LDP
> > > extension for GMPLS network.
> > >
> > > It also notes that most of the ATM network and most of 
> data network use
> > > the bi-directional signaling in general.
> > >
> > > The author of draft-shahrier-nsis-framework-00.txt may 
> first hear some
> > > backgrounds why the mpls WG choose uni-directional 
> signaling. It was
> > > taken with some considerations of physical media type, end user
> > > applications, network provider operation and maintenance, 
> and system
> > > implementation, etc.  In addition, routing algorithm and 
> forwarding logic
> > > of IP router are another factors for decision. In order to make a
> > > decision for bi-directional signaling at nsis WG, it may 
> be needed to
> > > check the related technical issues including end user 
> requirements,
> > > network operator requirements and system designer 
> requirements. It may
> > > help to clarify the needs and the work scopes of that draft.
> > > Specifically, it may need to find target signaling 
> objectives according
> > > to layered concept, service provisioning rule, gegographical view,
> > > network dimensioning and physical coverage, etc.
> > >
> > > In my personal views (since I am much oriented on telco- 
> viewpoints), I
> > > don't clearly understand what is the real objectives of 
> this draft ? What
> > > is the target application ? Is that only for a specific 
> end appllication,
> > > otherwise is it generally both for end user and network 
> provider ? I
> > > think that the author may find some critical problems on 
> the existing
> > > activities of bi-directional signaling at other group or 
> other body. Why
> > > new bi-directional signaling protocol is needed ?
> > > It may be reasonable to wait until the nsis WG finish the 
> requirements
> > > even though I don't follow what is going on in detail yet.
> > >
> > > In general, different and individual signaling protocols 
> are needed when
> > > end applications and intermediate network elements are 
> different on
> > > operational rule, service provisioning, and control 
> mechanism including
> > > resource reservation, etc. If a number of signaling 
> requirements merge
> > > into one set of signaling protocol, some trade-offs among 
> benefits, cost,
> > > and performance must be analyzed. It notes that the 
> trade-off analyses
> > > are not just focusing on technical matters.
> > >
> > > Jun Kyun Choi
> > >
> > > ----- Original Message -----
> > > From: "Marcus Brunner" <[email-masked]>
> > > To: "Shahrier, Sharif M." <[email-masked]>
> > > Cc: <[email-masked]>
> > > Sent: Tuesday, July 30, 2002 4:50 PM
> > > Subject: RE: [NSIS] question for clarification
> > >
> > >
> > >> Whach the ccamp WG
> > >> MArcus
> > >>
> > >> --On Montag, 29. Juli 2002 14:49 -0400 "Shahrier, Sharif M."
> > >> <[email-masked]> wrote:
> > >>
> > >> > Marcus,
> > >> >
> > >> > Thanks for the information. Would you have the link to 
> this draft
> > >> > that you can send to us? Thanks.
> > >> >
> > >> > Sharif.
> > >> >
> > >> >
> > >> >  -----Original Message-----
> > >> > From: Marcus Brunner [mailto:[email-masked]]
> > >> > Sent: Thursday, July 25, 2002 6:36 AM
> > >> > To: Shahrier, Sharif M.
> > >> > Cc: [email-masked]'
> > >> > Subject: Re: [NSIS] question for clarification
> > >> >
> > >> > Sharif,
> > >> >
> > >> > RSVP-TE with GMPLS extension is a signaling protocol 
> for setting up
> > >> > GMPLS pathes, which might be optical or what ever. 
> There one of the
> > >> > extension is  that they allow for bi-directional path setup.
> > >> >
> > >> > Marcus
> > >> >
> > >> > --On Dienstag, 23. Juli 2002 15:16 -0400 "Shahrier, Sharif M."
> > >> > <[email-masked]> wrote:
> > >> >
> > >> >> Following my presentation of the framework draft at 
> Yokohama, a person
> > >> >> had asked me whether our approach was the same as the 
> "bi-directional
> > >> >> GMPLS" that the MPLS WG had worked on.
> > >> >>
> > >> >> I am not sure what this is, and would appreciate if 
> that person can
> > >> >> provide us with more information.
> > >> >> Thanks.
> > >> >>
> > >> >> Sharif.
> > >> >>
> > >
> >
> > --------------------------------------
> > Dr. Marcus Brunner
> > Network Laboratories
> > NEC Europe Ltd.
> >
> > E-Mail: [email-masked]
> > WWW:    http://www.ccrle.nec.de/
> > Phone: +49 (0) 6221 905 11 29
> > personal home page: http://www.brubers.org/marcus
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Dan Grossman <[email-masked]>
Date: Tue, 06 Aug 2002 10:31:06 -0400

> firstly, i've long had a background assumption that it was not the role of NSIS as a transport protocol to influence/force/modify packet paths. Resource messages carried by NSIS might do this as a…

Why not?  There are cases where the originator of a flow has a (small 'p') policy objective,  like "I'd rather use service provider 'x' than service provider 'y'", or "Please constrain this bidirectional flow to use reverse paths" or "Please route these two flows as diversely as possible".  I don't think that there are very many of these cases, but I don't see any
architectural reason to preclude them.

> a) no, NSIS shouldn't do things to force/prefer symmetric routing

The more we discuss this, the more inclined I am to believe that the mechanisms to do so should be put in place, as long as the network has the right of refusal.  You could do it with preference ("I prefer reverse paths") and/or you can do it with source directed blocking ("If you can't or won't give me reverse paths, please reject the flow, I don't want it").

> b) if there are good low-overhead ways to discover topological constraints i don't see why we shouldn't exploit them. the most important constraint would be that a host knew it was connected to the…

Actually, that's "connected to a stub network".

> c) i doubt that a bidirectional reservation would be simpler than individual unidirectional ones, rather you could do grouping to get the same effect with very little extra complexity. (i think thi…

I believe that the point in PacketCable was to reduce signalling latency and message overhead by exploiting the fact that the cable subnet is a stub network.   It also simplifies recovery from cases where the flow in one direction can't be set up,  making having a flow in the other direction not useful.  If bi-directional flows are dominant, deadlocks can occur
unless there is some atomic way reserve resources for both directions.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 06 Aug 2002 12:09:55 -0400

> Why not?  There are cases where the originator of a flow
> has a (small 'p') policy objective, like "I'd rather use
> service provider 'x' than service provider 'y'", or
> "Please constrain this bidirectional flow to use reverse
> paths" or "Please route these two flows as diversely as
> possible".  I don't think that there are very many of
> these cases, but I don't see any architectural reason to
> preclude them.

My stock response to this sort of thing is "I understand why
you want to do this, but I don't understand why you'd want
to do it over IP."  I tend to be uncomfortable with
mechanisms that are inconsistent with how IP was designed to
be used, since they remove the advantages it brings.  I'm
also not clear on why we'd want to overlap with MPLS to such
an extent.  

These examples concern me more than others we've seen.  NSIS
isn't here to add another routing protocol into the soup -
it's here to provide a way to make requests of NSIS-capable
devices along a path.  Those are two completely orthogonal
things.  There's a strong case to be made for upper-layer
routing protocols (regard TRIP, for example), and perhaps
once the NSIS protocol machinery is specified an upper-layer
routing protocol can be created as an NSIS application, but
I don't believe there's a strong case for upper-layer
routing protocols as an NSIS primitive.

Melinda

---

From: Dan Grossman <[email-masked]>
Date: Tue, 06 Aug 2002 13:59:19 -0400

> also not clear on why we'd want to overlap with MPLS to such

It sounds like you're trying to articulate an architectural principle,
but I don't understand what it is or how you justify it.  If somebody
has written down "how IP is supposed to be used", I'm not aware of it,
much less why you claim that this is inconsistent..  You claim that some
advantages of IP are removed, but you don't say which ones.

As far as MPLS is concerned, I consider this to be complementrary rather
than overlapping capabilities.

> isn't here to add another routing protocol into the soup -

Nobody's talking about adding a routing protocol:  we've got too many of
them already.  And certainly there are precedents in IP for requesting
particular routing treatments (source routing and the security field
come immediately to mind).

> devices along a path.

That's my point.  Just that I'd like to be able to make  particular
requests to NSIS-capable devices that influence their next-hop
forwarding decisions for a particular flow or set of flows.  Nobody's
been able to articulate why that is a Bad Thing.

> Those are two completely orthogonal

I don't understand why you'd need an upper layer routing protocol for
this or why there's so much of a separation of concerns that would
warrant creating a new layer.  Or are you talking about discovery rather
than communicating policy requests?

---

From: Melinda Shore <[email-masked]>
Date: Tue, 06 Aug 2002 15:20:47 -0400

> but I don't understand what it is or how you justify it. 

Put a packet into the network with a valid destination
address and allow IP-layer routing to determine how it gets
from here to there.  If applications start determining
routes for traffic, you run into problems like suboptimal
routes, tromboning, and so forth, and you can only avoid
those by pushing routing state into the applications
themselves.  That starts to interfere with network
robustness (recovery from outages, convergence after routing
changes, etc.)  and greatly increases the complexity of both
the network and the application.

> them already. 

Sure you are.  If you're telling the IP layer how to route
packets, you're a routing protocol.

> And certainly there are precedents in IP for requesting

You'll note that source routed packets are usually dropped.
I'm not sure what you mean by "security field" - are you
referring to the DS byte?  That's an in-band signaling
mechanism, not a routing mechanism.

> warrant creating a new layer.

It's generally appropriate to route among entities at the
same layer.  So, for VoIP the signaling problem is how to
route to appropriate gateways, not how to choose the routers
the traffic will traverse en route.  For content networking
it's how to find the appropriate cache.  And so on.  That's
one aspect of "layer."  The other layering question is
related to the NSIS protocol itself.  There appears to be
widespread agreement that the NSIS protocol will be split
into two layers; one providing the NSIS transport and
protocol machinery and the other providing the data
representing the NSIS request (see Bob Braden's two-layer
draft).  This provides greater generality/power in the base
protocol and resolves some of the weaknesses that prevent
RSVP from being a more general-purpose signaling protocol.
It seems clear to me that to the extent that routing should
be treated as an NSIS function, and I'm not convinced that
it should, it belongs in the upper layer, not the transport,
and we're not working on the upper layer yet.

Melinda

---

From: Dan Grossman <[email-masked]>
Date: Tue, 06 Aug 2002 16:51:46 -0400

Melinda Shore wrote:

> from here to there.

But IP violates this principle at a much lower level of abstraction (strict
source route, loose source route, security options).  Do you propose to move
those things to 'historic'?

Besides, that still doesn't address the point that the applications (or human
end users) may have policy objectives that they need the routing system to
take into account in making next hop forwarding decisions for the flow.  Or,
rather, changing one or more next-hop forwarding decisions from the default.
The IP routing layer **is** determining how it gets from here to there, just
doing so consistent with policy requests.

>  If applications start determining
> themselves.

This is true if you're doing (loose) source route.  If the NSIS protocol just
provides policy-type requests that the network can either act upon or reject,
then I don't see a need.   Or if you did need that kind of information, it
would probably be very aggregated and very static.

> That starts to interfere with network

Maybe your definitions of  "routing protocol" and "signalling protocol" are
different from mine.  I understand a routing protocol to distribute
information related to network topology.  I understand a signalling protocol
to allow hosts and routers to establish, maintain and release state
information and resources associated with flows (and groups of flows).
Mechanisms in a signalling protocol that request establishment of a flow whose
path has particular characteristics  do not make it a routing protocol.

> You'll note that source routed packets are usually dropped.

From RFC 1812:
"A router MUST implement support for source route options in forwarded
packets. A router MAY implement a configuration option that, when
enabled, causes all source-routed packets to be discarded. However,
such an option MUST NOT be enabled by default."

So either folks are building routers that aren't compliant with RFC1812, or
operators are turning on an optional configuration option.  That doesn't
remove the architectural principle that packets can influence their own path
through an IP network.

> mechanism, not a routing mechanism.

Oops, I meant the US DOD Security Option (RFC1108)...  I'd been looking at the
Security Option in RFC791 and had forgotten that it was obsoleted a few times.

> and we're not working on the upper layer yet.

Oh.  In which case I  disagree.  This is a discussion about signalling to
influence the IP layer path across IP networks.  While it's true that higher
layers would request these kinds of things from the IP layer, there's no
reason to incorporate them in the higher layer signalling protocol, since the
higher layer signalling protocol is not in any way acted upon by the IP
network.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 06 Aug 2002 17:10:33 -0400

> But IP violates this principle at a much lower level of
> abstraction (strict source route, loose source route,
> security options).  Do you propose to move those things to
> 'historic'?

Again, source routing is 1) rarely used, and 2) frequently
dropped.  I certainly wouldn't use its existence to argue
much of anything.  If you try to inject source routed
packets into the network you'll see that they probably won't
be delivered.  But aside from that, source routing scales
badly and is both unmanageable and unstable.  IP was
designed around different fundamental assumptions from the
phone network, and if you don't respect the basic underlying
design you start to have problems - consider the
consequences of NAT, for example.  

> Besides, that still doesn't address the point that the
> applications (or human end users) may have policy
> objectives that they need the routing system to take into
> account in making next hop forwarding decisions for the
> flow.

Of course they do.  But telling the network what services
you need (QoS, etc.) and leaving how (and whether) to do it
up to the devices in the network is fundamentally different
from telling the network how to route the packets.  Probably
the biggest lesson from midcom is that layer violation leads
to topology problems, and having applications tell routers
where to forward packets is a layer violation.

> This is true if you're doing (loose) source route.  If the
> NSIS protocol just provides policy-type requests that the
> network can either act upon or reject, then I don't see a
> need.

Policy requests are good, and I hope that we can remain
focused on them rather than on the specifics of telling
routers how to forward.  Still, the policy belongs to an
NSIS application, not NSIS transport.  That is to say, what
needs to be considered in this discussion is how using NSIS
to carry the policy requests you're interested in might
affect the NSIS protocol machinery.  The policy application
itself is not embedded in the protocol machinery (or at
least it shouldn't be) - it's not part of the protocol
itself.

> Maybe your definitions of "routing protocol" and
> "signalling protocol" are different from mine.  I
> understand a routing protocol to distribute information
> related to network topology.  I understand a signalling
> protocol to allow hosts and routers to establish, maintain
> and release state information and resources associated
> with flows (and groups of flows).

By that description, a routing protocol is an instance of a
signaling protocol, right?

Melinda

---

From: Dan Grossman <[email-masked]>
Date: Wed, 07 Aug 2002 10:29:28 -0400

Melinda Shore wrote:

> badly and is both unmanageable and unstable.

I stipulate that source routing is the wrong level of abstraction given
some of the other architectural decisions in IP (it was the right
decision in PNNI given PNNI's objectives).  I do not wish to encourage
its use.   That doesn't invalidate the architectural principle that IP
packets can and do have the means to affect their own path through the
network.

> IP was

I stipulate that NAT is a gross violation of several basic architectural
principles.  You realize that you just invalidated your argument that
relates usage of some feature to its validity?

Ah, the phone network shibboleth.  I stipulate that IP was designed
around different assumptions from the phone network.  In some cases,
this was prescient, and in other cases it was short sighted.    We are
trying to retrofit network awareness of flows into the nominally
stateless IP forwarding path.  Flows have paths.  The question we're
trying to answer is whether the path originator should have any
influence on the path of the flow.  This has nothing to do with the
telephone network, and in fact many of the capabilities needed here are
not an issue in the telephone network because the design of the
telephone network *is* different that the design of the Internet..

> where to forward packets is a layer violation.

Nobody is proposing to put source routing into NSIS.  I am proposing to
put policy requests into NSIS that affect path calculations.

Maybe we're arguing about an appropriate level of abstraction.  I
stipulate that putting a list of next-hop routers (or next hop networks)
into NSIS messages is not the right thing to do.  I suggest an option to
request that a set of related flows follow the same (or reversed) paths,
and probably others will think of options at the same level of
abstraction.  You suggest that there is something at a higher level of
abstraction that will have the net result I'm looking for.   What is it,
please?

> least it shouldn't be) - it's not part of the protocol

There's message syntax and coding rules, there's message semantics and
there's protocol procedures and abstract state machines.   I stipulate
that this is not a syntax/coding rules issue.  We need to add semantics,
procedures and state machines in order to do this.  If you think that
should be a different document, that's fine.

> signaling protocol, right?

Wrong.  Let me try again:
Routing protocol:  distributes network topology information
                            represents global state of a network
Signalling protocol: establishes/maintains/releases flows
                              negotiates and reserves resources along a
path
                              establishes state only in those systems
along the path of the flow(s) established

Explain how a routing protocol is an instance of a signalling protocol?

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Aug 2002 11:09:32 -0400

> decision in PNNI given PNNI's objectives).  

I think it has a lot less to do with PNNI's objectives than
it does to do with the design of ATM, which is
label-switched and doesn't contain destination addresses in
each cell.  Because of that there's a need to temporarily
wire routes for each flow into every switch along the path
for the duration of the flow.

> relates usage of some feature to its validity?

Not really, unless you think that choosing to use something
that's bad is the same thing as not choosing to use
something that's not good for general-purpose use.  The
reason that I raised the NAT issue is that it's a very good
example of something that's not idiomatic to the underlying
technology and that as a consequence of doing something that
conflicts with basic design decisions, it's causing severe
and fundamentally insoluble problems with both routing and
security.  I would not like to see NSIS make the same
mistake.

> Explain how a routing protocol is an instance of a signalling protocol?

I don't agree with your definitions - for example, a
signaling protocol needn't (and, in fact, doesn't) represent
the global state of a network.  And a signaling protocol
needn't limit itself to on-path state manipulation, although
NSIS does.  

Melinda

---

From: Dan Grossman <[email-masked]>
Date: Wed, 07 Aug 2002 12:06:37 -0400

I think we've strayed from the original topic, but I'll respond anyway.

> for the duration of the flow.

No, it could have done next hop path computations on a distributed basis like
OSPF or IS/IS, differing only that it configured VPI/VCI mappings for the next
hop rather than forwarding a single packet.  In fact, some folks initially
thought we could pretty much reuse OSPF, until we looked a bit deeper at the
requirements.    The reason for the designated transit list was to allow QoS
objectives and QoS and policy metrics to be used in path calculation
(difficult to do in a distributed algorithm in bounded time), and to make
crankback not keep retrying paths that don't work.  It is true that hard state
and labels (VPI/VCI) make the cost of getting a path wrong a lot greater, and
reduce the computational and overhead cost of path calculation and DTL
transport per user data packet (at least for long-lived virtual connections).
So what was a good decision for PNNI was not a good decision for IP.  I
suspect you could argue that it might be a good decision if you were doing
NSIS and a new routing protocol on a clean sheet of paper.  But since we don't
have a clean sheet of paper, it's a moot point.

In any event, this is off topic.

> security.  I would not like to see NSIS make the same

You still haven't made a convincing case why putting policy requests for paths
into NSIS is bad.

> the global state of a network.

I assume you mean routing protocol here.

And if a map of link state doesn't define a relevant portion of the global
state of the network, I'm not sure what does.

> And a signaling protocol

Well, ok, there are some cases where entities not along the path of the flow
might need to be manipulated.  I think that those are higher layer signalling
cases rather than happening at the NSIS level, which is why I wasn't thinking
about them.  The point is that signalling protocols generally don't distribute
information across entire (non-trivial) networks.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 07 Aug 2002 17:33:42 -0400

> From: Dan Grossman <[email-masked]>

> You still haven't made a convincing case why putting
> policy requests for paths into NSIS is bad.

"Convincing" is almost entirely subjective, of course.  It's
not that I think that putting policy requests for paths into
nsis is bad but that I don't think it's universally good.
That is to say, it depends on the policy being requested.

A lot of this depends on your base assumptions, as well.  My
starting point is that nsis's job is to figure out what went
wrong with RSVP and to try to fix that, if necessary.  From
my perspective RSVP is very, very good for situations in
which you'd like to request services from the network but
you don't know where network entities are.  It is less good
for situations in which you either already know where
entities are or in which you want to affect routing.  Part
of it is the question of where knowledge of current routing
state is retained, which affects the ability of
participating entities to be able to respond to network
events like outages and routing changes.

A related problem is bootstrapping and the ability to tie
the signaling path to the data path.  In the default case,
where you simply send a packet into the network and let IP
routing take care of figuring out which routers must be
traversed, you can predict with a high degree of reliability
that the signaling data and the data flow will follow the
same path.  When there's policy in there that creates
differentials between packet treatment based not on the
destination address but on some other piece of information,
you need to ensure that the signaling messages will flow
along the same path that the data will take.  Using the
signaling messages to install the differential policy along
the appropriate path is going to be difficult.  It also
assumes that you've already got some knowledge of network
topology, which I continue to believe creates more problems
than it solves.

Part of the reason that I'm particularly hinky about this is
that an unimplementable QoS architecture is coming out of
some of the VoIP standards bodies that shares some features
with what you're proposing.  

At any rate, as I said I understand why you want to do that
but I don't understand why you want to do it that way.  MPLS
will solve the same problem cleaner and more reliably, as
will using tunnels or relays.  I'd really rather see nsis
remain focused on the case where network topology is
initially opaque to applications.

Melinda

---

From: Dan Grossman <[email-masked]>
Date: Thu, 08 Aug 2002 10:34:50 -0400

Melinda,
Thank you for the clarifying your position.  Now that I understand where
you're coming from, we can at least agree to narrow the scope of our
disagreement, maybe even agree.

> That is to say, it depends on the policy being requested.

I think we're close here.  I would expect policy requests to be
exceptional or restricted to certain environments (as in PacketCable).
I also agree that we would need to set some architectural guidelines for
what represents 'good' types of policy requests and what represents
architectural abominations.

> wrong with RSVP and to try to fix that, if necessary.

This sounds like a whole 'nother thread.  Perhaps it played out on the
list while I was procrastinating about joining.  Needless to say, I have
my own ideas about what went wrong, and would write them down if
prompted to do so.

>  From

That sounds like the beginnings of an architectural principle, to the
effect that any policy that can safely be invoked only with knowledge of
current routing state can only be invoked by an entity that posesses
current routing state.

> where you simply send a packet into the network and let IP

By "simply send a packet", do you mean a signalling packet or a user
data packet?  I assume the former for now...

> differentials between packet treatment based not on the

I assume you mean "flow treatment' rather than 'packet treatment" here.
That is, the router makes a next hop forwarding decision based on the
signalling message's destination IP address (and possibly some policy
requests), binds it to a flowspec and then forwards the signalling
packet to that next hop.

> along the same path that the data will take.

Agreed.

>  Using the
> the appropriate path is going to be difficult.

Can you explain?

>  It also

Which 'you'?

> with what you're proposing.

I've tried with considerable success to keep clear of deep involvement
in VoIP signalling, so don't know the issues that you're raising.  On
the other hand, I've had deep involvement over many years with ISDN,
Frame Relay, and ATM signalling and think that there are lessons to be
learned there.   As an aside, I think that some of what went wrong with
RSVP stems in part from failure to learn lessons from ISDN and SS7
protocols and their progeny.

> will using tunnels or relays.

Well, yes, but I don't think that anybody is talking about
MPLS-to-the-desktop (or to the MTA).  In fact, in the context of this
discussion, doing so would require far more knowledge of routing state
(and thus heavyweight routing implementation) than would be desirable in
the ends or even in the edges.

>  I'd really rather see nsis

I think we might be able to agree with an architectural principle that
says that we quantify how much network topology knowlege is required for
a particular policy option, and that we forbid any entity from using
that option unless it has at least that much topology knowledge.   I'm
sure we could agree that mechanisms for topology discovery (other than
as side-effects like "no, you can't do that, destination unreachable")
are out of scope for NSIS.

Dan