Subject: RE: draft-ietf-mpls-lmp-01.txt

From: [email-masked]
Date: Wed, 6 Dec 2000 09:53:02 -0000

Hi Alex......just catching up with mail.  
<snip>
> I'll take the liberty to answer your questions below.
> 
> > Jonathan,
> 
> > Good work.  I have no major concerns on other issues except the control
> channel
> > management.
> 
> > First, it's not only control "channels", it's control "NETWORK". The
> control
> > network has many strong requirement regarding reliability, security,
> performance
> > and scalability. It has to be managed and operated as a "network" not a
> > collection of individual control channels.
> 
> The notion of the control channel does not substitute the notion
> of the control network. In fact, the control channel between two NEs
> uses the control network for transport services, i.e. LMP messages
> associated with control channels and bundles are delivered in IP
> packets.
	NH=> Yangguang is dead right here.  Recall the chat you/I/Andy Reid
had on Tuesday this week in the UK on this subject?  The signalling-network
is 'bottom-of-stack' wrt layered networks.  It lives or dies in accordance
with the connectivity of the duct network and the ' survivability mechanism'
used to create redundancy.  In typical IP networks (where
control/user-planes are congruent wrt routing) the 'survivability mechanism'
is effectively flooding, which boot-straps the system.  In the PSTN, SS7
uses the concept of link sets.....several diversely routed 'bottom-of-stack'
transport links between signalling transfer points......where if one link
dies, the remainder simply carry on load sharing the signalling messages
(this is their boot-strap mechanism).  So the signalling (or control-plane)
network is a network in its own right and must not use a the same
transport/survivability network mechanisms as the user-plane....think of it
as a super-resilient VPN if you like, whose design has nothing to do with
any other traffic/networks, and requires special attention.
	 
> > Control channel "management" (as mechanisms used by BGP, LDP, etc.)
> actually
> > only provide health check of the control "session" between neighbors.
> It's not
> > as fast as low layer protocols. Again, the control "network" should take
> care of
> > all requirements and can do much better. Control channel(session)
> "management"
> > only serves as an add-on checking.
> 
> In cases where the control channel spans more than one link,
> the health check and survival of the control network is insured by
> IGP protocols (OSPF/ISIS).
	NH=> Sorry, not good enough.  The signalling network must be
designed as a seperate entity for the OTN.  See above and refer to our chat
earlier this week.
>  In cases where LMP CC is between directly
> connected nodes, LMP Hello process helps faster detection of
> unreachable neighbors.
> 
> > Regarding your statement "Each bundled link is identified as described
> in
> > [KRB00] and each bundled link MUST have an associated control channel".
> Is this
> > a product specific requirement?
> 
> Which part are you referring to?
> 
> > In order for LMP to be a generic protocol, as I
> > have said many times, control network should be considered independent
> of
> > transport network. There should be no assumption of any correlation
> between
> > these two networks.
	NH=> Here we see Yangguang making the same point again.

---

From: Alex Zinin <[email-masked]>
Date: Sun, 10 Dec 2000 18:34:13 -0800

neil,

Didn't really have time to read all e-mails, so sorry for
a later response.

See my answers below.

> is 'bottom-of-stack' wrt layered networks.

I feel you're actually looking at the signaling network as the one
that works in-band in the data links. Note that it does not have to be
like this. It is absolutely possible to have an out-of-band control
network. I thought we agreed on this.

>   It lives or dies in accordance
> (this is their boot-strap mechanism).

This is exactly what happens in the OF/OB case.

>   So the signalling (or control-plane)
> transport/survivability network mechanisms as the user-plane....

As I explained, the IGP domain is not expanded beyond OTN borders,
and OTN clients are free to run any type of routing protos and feed
any type of traffic into the provisioned light-paths.

> think of it

Neil, I do not see where the disagreement is.

> designed as a seperate entity for the OTN.  See above and refer to our chat

Again, what I said above does not mean we have the same instance of
IGP running on the control network links and through signaled
lighpaths.

Maybe misunderstanding comes from the fact that an "LMP Control Channel"
is not equal to a "link in the control network".

Alex.