Subject: RE: RSVP Hello

From: "Martin, Christian" <[email-masked]>
Date: Mon, 27 Aug 2001 11:38:24 -0400

Neil,

Thanks for the well-thought response.  I am not quite sure if you have
chosen a side in this debate, so forgive me if I misunderstand your
position.  Comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 12:58 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: RSVP Hello
> 
> 
> Bill/Martin,
> 
> Noting your comment (Bill) on cringing when you hear "It will 
> be easy to add
> this fuctionality" or "how hard can this be?", I cringe 
> myself when I see
> architectural kludges, and this thread has more than a whiff 
> of these.....so
> let me add my 2 cents (with a slightly different slant...so 
> please bear with
> me):

It could be said that RSVP-TE is an architectural kludge in that, RSVP was
specifically designed for signalling reservation state with any applicable
QoS parameters, congruent to the data plane that was built using control
plane protocols (routing), and not to act as a control plane protocol that
set up forwarding state.  Yet its usefulness is still clear and RSVP was the
best choice under the circumstances (time and monetary constraints and a
desperate need (perceived at least)).

> Each protocol provides specific functionality (otherwise why 
> have it?).
> Hence, by inference, each protocol will have it own specific 
> failure modes,
> and thus require its own specific OAM mechanism.  So whether 
> we are talking
> about RSVP, LDP, OSPF, BGP4, etc this applies, and the RFCs 
> that specify
> these protocols do indeed have such OAM functionality defined in them.

However, they are not independednt of other control and management planes.
They all rely on an IP control plane.  In fact BGP relies on three layered
control planes in many network designs (IGP and TCP/IP), which in fact
relies on some set of independent control planes as well (ATM VCs or PPP
over STS-nc/DS3).  The management planes in the protocols do not function
without the ones beneath them. 

<-snip->

> This mail thread is mixing different signalling protocol 
> functionality as
> proxies for data-plane failures, and a previous discussion on the
> draft-pan-lsp-ping-01.txt broke the layer/plane protocol independence
> principle by binding specific client/server layer OAM 
> functionality to a
> specific control-plane signalling protocol.

But, Neil, this isn't the PSTN/SS7N we are talking about.  We are talking
about the public Internet, where there is little separation between planes.
RSVP is useless without an IGP.  BGP is (in practice) useless without an
IGP.  IGP's are useless without an IP infrastructure.  The management planes
of these protocols are all interdependent.  We cannot decouple them now.

Each of these protocols has their own OAM functionality built in to some
degree.  BGP is not fully independent of its substrate, as in some cases, it
relies on TCP operations to detect failures.  This is the nature of TCP/IP
and sockets and cleint/server computing.  The point is, that, regardless of
the interdependence, there is an OAM capability that allows us (those
building networks) to determine the cause of a failure.  This is because
they are hard-state protocols.  Now we all agree that RSVP as a signalling
protocol is not scalable wrt thousands or millions of microflows in a
hard-state environment.  Neither is any protocol on that scale.  An internet
core router cannot support millions of BGP prefixes, IGPs cannot support
millions of links, etc.  Thus, the routing information they convey is
soft-state, but the framework they use to distribute this information is
hard-state (or firm-state) and hieracrhical.  This is the crux of my
problem.  RSVP is soft-state in both its distribution mechanism and its
framework for distribution.  So, although there is reservation state OAM,
there is no way to determine of the reservation messages are being delivered
properly in the first place, at least in the current vendor implementations.
We only ass-u-me that because there is IP connectivity that there is nodal
RSVP awareness end-to-end.

Using BGP as an example, which philosphically is in some ways like RSVP
(from a very abstract point of view), let us consider the following:

Two BGP peers are separated by n hops across an AS of arbitrary complexity.
A BGP session is being built, but it cannot be established.  Hrm.  We use
techniques to diagnose the problem - are the peers reachable via IP?  We use
pings and traceroutes to determine that.  OK, is there a configuration
issue?  We inspect the two configurations, troubleshoot the root cause, and
move on.  The distribution framework is built and now we can move on to the
distribution mechanism.  At this point, the BGP OAM functionality becomes
independent, and everyone is happy.

Back to RSVP-TE, let us do something similar.  Again, we have two RSVP-TE
endpoints that we wish to build an LSP between.  During the reservation
setup step, we discover that we are not receiving RESV or RESVERR messages
back.  Hrm.  Where is the problem?  We can do pings and traces, but that
does not inform us whether or not there is a nodal RSVP handling issue on
one or more processing devices in the path.  But what device?!  This is
where I see a problem.

What I am proposing is that we build some OAM into the RSVP-TE framework,
such that an operator can detect misconfigurations and nodal failures of the
RSVP processing subroutines.  The OAM mechanisms can be straightforward (by
building adjacency state and maintaining it), or can be more tool oriented,
like RSVP traceroute and RSVP ping.  We shouldn't have to break anything to
do this.  Hello's, the topic of this thread, are optional anyway.  

Of course this isn't a silver bullet.  All failure modes cannot be resolved
via OAM, but they can in most cases be _detected_ and thus, they can be
isolated.

I am by no means an RSVP expert.  That is for you guys!  I'm just an
ordinary plumber looking for a leak without the right tools.  
 
> During the discussion of the Ping draft, I know Yakov 
> described what I have
> discussed above as 'working on LTSFGTC' (long-term solutions 
> for generations
> to come)...or something like that......but if we want MPLS 
> itself to be a
> LTSFGTC (and hopefully also give some solid foundation for 
> those working in
> the PWE3 and PPVPNs WGs) then we really have to get some of 
> the basic OAM
> architectural tenets right at the outset.  Proper data-plane 
> OAM, and its
> decoupling from other client/server layer data-planes and/or specific
> control (or management) plane protocols is not a 'luxury 
> item', its just
> plain common sense to avoid problems down the road.

Unfortunately, we have already built and deployed a solution that has little
functional independence.  GMPLS attempts to do this, but this is because the
underlying network technology is new (like OXCs), and thus, can be designed
with GMPLS in mind.  As far as today's MPLS infrastructure, and the Internet
protocols as a whole, RSVP is the only state-building protocol without
robust OAM on the delivery mechanism itself.  It is akin to BGP without
nailed up neighbors.

Best Regards,
-chris

> 
> regards, Neil
> > -----Original Message-----
> > From: Sanford, Bill [mailto:[email-masked]]
> > Sent: 24 August 2001 14:27
> > To: 'Martin, Christian'; Sanford, Bill; [email-masked]'
> > Subject: RE: RSVP Hello
> > 
> > 
> > 
> > > Of course, this example discusses authenticated RSVP 
> > > messages, but other
> > > types of issues can impair RSVP without easy detection.  As 
> > > it is today, you
> > > can either send a test PATH message across the network to 
> > > build state, or
> > > you can hope it works when you need it.  Neither is operationally
> > > acceptable, IMHO.
> > 
> > You can always submit a draft. ;-)
> > 
> > Regards,
> > Bill
> > 
>

---

From: David Charlap <[email-masked]>
Date: Mon, 27 Aug 2001 12:07:09 -0400

"Martin, Christian" wrote:
> 
> RSVP is soft-state in both its distribution mechanism and its
> framework for distribution.  So, although there is reservation
> state OAM, there is no way to determine of the reservation messages
> are being delivered properly in the first place, at least in the
> current vendor implementations.

Implementation is the big deal.  There is the concept of a Resv Confirm
message in RSVP - part of RFC 2205.

When used, the end-to-end handshaking changes from two way (Path-Resv)
to three-way (Path-Resv-Confirm).  If there is a need for the egress to
know that the LSP has been set up, apart from simply receiving labeled
packets, it can use this mechanism.

But, as you say, not all implementations support this.

> Back to RSVP-TE, let us do something similar.  Again, we have two
> RSVP-TE endpoints that we wish to build an LSP between.  During the
> reservation setup step, we discover that we are not receiving RESV
> or RESVERR messages back.  Hrm.  Where is the problem?  We can do
> pings and traces, but that does not inform us whether or not there
> is a nodal RSVP handling issue on one or more processing devices in
> the path.  But what device?!  This is where I see a problem.

This is actually covered in the draft.  Admission control errors, which
in RFC 2205 cause the generation of ResvErr, in the RSVP-TE draft cause
the generation of PathErr.  See section 4.7.3 of the RSVP-TE draft.

In the case of a failure that takes place after the LSP is set up, RSVP
Hello will detect the failure and appropriate PathErr/ResvErr messages
should be sent to the endpoints of the LSP.  I don't know about GMPLS
(where data- and control-planes are separate) but I would assume that a
similar mechanism exists there.

In other words, the ingress node will be told about the failure.  It can
then try again with different parameters or report the failure to
management.

-- David