Subject: RE: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]

From: "David Allan" <[email-masked]>
Date: Wed, 15 Aug 2001 11:21:11 -0400

Ping:

I don't see control and data planes as tightly coupled in your proposal.
You're clearly operationally divorcing the two (which is the trend you refer
to for BGP, IGP and now RSVP restart mechanisms). Not that this is a bad
thing, it just cannot be done in isolation. You (and others, my point is not
specific to this I-D) are eliminating all forms of fate sharing between the
control and data planes, despite (in the MPLS case vs. GMPLS) the use of
common resources in the control and data plane adjacencies. 

This may suggest that control plane failure is today significantly more
frequent than data plane or link failure and there is a real problem to
solve, but adding restart mechanisms to everything in the control plane is
not the complete answer. Every divorce in the fate-sharing world adds a new
failure detection requirement and more maintenance messaging.

cheers
Dave

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: Wednesday, August 15, 2001 10:33 AM
To: Allan, David [CAR:NS00:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: [Fwd: I-D ACTION:draft-pan-rsvp-te-restart-01.txt]

> David Allan wrote:
> 
> Ping:
> 
> I'm having trouble correlating route flap instability data with your
> problem statement. Similarly I have trouble with the analogy between
> graceful restart for routing (which has a fair chasm between it and
> forwarding) and a soft state signalling protocol which would appear to
> require a much tighter coupling.
> 

Dave,

The point was that in the network, there could be cases where the
control engine is crashed while the data forwarding engine is fine. To
reduce the side-effects, control protocols (routing and signaling)
should use various graceful restart mechanisms. In our draft, I think
the control and forwarding are tightly coupled. Please let me know why
you think otherwise.

> Is this really more applicable to GMPLS and should be tagged as such?
> 

Both GMPLS and MPLS can benefit from this. In case of GMPLS, graceful
restart can be used to recover from control channel failure.

Regards,

- Ping

---

From: Ping Pan <[email-masked]>
Date: Wed, 15 Aug 2001 10:12:34 -0700

David Allan wrote:

> You (and others, my 
> point is not specific to this I-D) are eliminating all forms of fate 
> sharing between the control and data planes, despite (in the MPLS case 
> vs. GMPLS) the use of common resources in the control and data plane 
> adjacencies.
> 

David,

What has been proposed in all forms of graceful restart is the message 
format on the wire. How you implement the routers to support these 
messages is totally up to the developers.

> solve, but adding restart mechanisms to everything in the control plane 
> is not the complete answer.

You are right. There are several solutions to help routers/networks in 
case of failure condition. Graceful restart is to solve the problem when 
control plane dies, but data forwarding is up. Fast reroute is to solve 
the problem when data forwarding is in trouble. LSP-ping (please don't 
start all those architectural beatification argument again) is to detect 
data plane black-hole problem....

Regards,

- Ping

---

From: "Hongwei" <[email-masked]>
Date: Wed, 15 Aug 2001 19:02:28 +0100

Hi,

ATM network uses VPI and VCI to route cells. But how are the VP and VC set
up first? and what should the network operator
should do when a new ATM router is added to the network? is there any
address in ATM network like IP address in IP network?

This question seems irrelevant to the topic of the discussion group, but ATM
works very similarly to MPLS, and there is no ATM group
at uu.net, so I beg your forgive that I put the question here, and I will
appreciate every help.

Cheers,

--Henry

---

From: Steve Nash <[email-masked]>
Date: Wed, 15 Aug 2001 14:03:22 -0400

Henry,

The VPI and VCI are assigned by the administrator through his/her configuration on the particular ATM switch(es) they
are configuring.  That then is handed off to the customer as the PVC (vpi/vci).  The ATM switch usually
has an IP address so you can manage it (oob, side-band, whatnot management).  When a new ATM switch is
added to the network, it is usually meshed into the existing ATM infrastructure, and if it is added between switches, you have
to make sure it contains all the PVC information for all your customers/internal PVCs...etc

HTH,

/s

---

From: David Charlap <[email-masked]>
Date: Wed, 15 Aug 2001 14:41:44 -0400

Steve Nash wrote:
> 
> The VPI and VCI are assigned by the administrator through his/her
> configuration on the particular ATM switch(es) they are configuring.
> That then is handed off to the customer as the PVC (vpi/vci).  The
> ATM switch usually has an IP address so you can manage it (oob,
> side-band, whatnot management).  When a new ATM switch is added to
> the network, it is usually meshed into the existing ATM
> infrastructure, and if it is added between switches, you have to
> make sure it contains all the PVC information for all your
> customers/internal PVCs...etc

This is massively off topic for this list.  ATM information is available
from the ATM Forum: http://www.atmforum.com/.

As for your particular description, that is but one method.  ATM
switches have not required manual configuration of PVCs for quite a long
time, even though many sites still prefer it over the automatic VC setup
mechanisms.

ATM switches have per-port NSAP addresses.  They are not IP addresses.

ATM switches run routing protocols (like PNNI), which are used to
compute paths through the network.

There are signaling protocols (like UNI) which are used to set up
virtual circuits without manual specifying the VPI/VCI at every hop.

There are a great many other protocols in ATM that do other useful
things, but this is not the place to get into a discussion of them. 
Specifications are available from the ATM Forum's web site.  There are
also many books on the subject.

-- David

---

From: Yangguang Xu <[email-masked]>
Date: Wed, 15 Aug 2001 15:41:19 -0400

Ping,

The restart procedure you described virtually turns the RSVP from a soft state
protocol to a hard state protocol.

Are we adding/changing too much to the RSVP and turning it into a totally
different thing?

Thanks,

Yangguang

---

From: Ping Pan <[email-masked]>
Date: Wed, 15 Aug 2001 14:02:41 -0700

> protocol to a hard state protocol.

How? Please explain.

> Are we adding/changing too much to the RSVP and turning it into a totally

I am interested in solving the problems, not interested in defining names.

- Ping

---

From: Yangguang Xu <[email-masked]>
Date: Wed, 15 Aug 2001 17:49:38 -0400

See my reply below,

> > protocol to a hard state protocol.

From RFC 2205 "RSVP takes a "soft state" approach to managing the reservation
state in routers and hosts. RSVP soft state is created and periodically
refreshed by Path and Resv messages.  The state is deleted if no matching
refresh messages arrive before the expiration of a "cleanup timeout" interval."

The "state" here is data plane state. If you separate the control and transport
plane, you can't depend on the periodically refreshing of Path and Resv message
to maintain the data plane state any more. Indeed, you can't even associate the
health of control and data plane any more.

Thanks,

Yangguang

---

From: Ping Pan <[email-masked]>
Date: Wed, 15 Aug 2001 15:10:33 -0700

Yangguang Xu wrote:
> The "state" here is data plane state.

No. The "state" here is the control information such as RSVP source,
destination, flowspec, etc. Data plane states are filter entries, FIB,
etc.

---

From: Yangguang Xu <[email-masked]>
Date: Wed, 15 Aug 2001 18:31:10 -0400

> destination, flowspec, etc. Data plane states are filter entries, FIB,

There was no distinction about these two states in RFC 2205. So I guess it then
can be interpreted differently to serve different purposes. 

Yangguang