The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Alex......my apologies even more so wrt late response....see comments
in-line.  Neil
	<snipped>
> Didn't really have time to read all e-mails, so sorry for
> a later response.
> 
> See my answers below.
> 
> >> > 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.
> 
> 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.
	NH=> Not at all.  I am not considering whether the signalling
traffic is associated with any user-plane traffic or not (so forget
in/out-band for the moment....though to deliver what is needed OOB is
required in the core of the network).  What Andy and I were trying to point
out is that the signalling network is a network in its own right.  So it has
its own 'user-plane' and 'control-plane' that are completely decoupled (as
abstract entites) from whatever we are doing regarding *external* customer
traffic.  The signalling network control-plane is very critical.  Indeed,
the one thing it does *not* need is reliance on something like an IGP for
normal operation. I like to think of this aspect as a 'bootstrap' mechanism
to make it ultra reliable and not dependent on an IGP say.  For example, in
OSPF this bootstrap mechanism is flooding.  In the PSTN SS7 it is a fixed
set of parallel diversely routed links (>=2) over which signalling traffic
is dished-out a bit like dealing cards....so if one link fails the rest just
carry on.  But the key issue is that the signalling network must have its
own topological design.  The fact that it will share (usually) links which
are common with the external user-plane traffic is incidental.  It is truly
bottom-of-the-stack and must takes its survivability cues *only* form the
disjoint connectivity that the duct network can (or maybe cannot) provide.

> >   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).
> 
> This is exactly what happens in the OF/OB case.
	NH=> Well that is true only if some survivability mechanism is still
built into the signalling network to make it logically disjoint from for the
external user-plane.  If so then you are OK.  

> >   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....
> 
> 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.
	NH=> If we run an OTN IGP (and I am not convinced this is
necessary...esp if we get the *right* hierarchical design and close coupling
of addressing/routing from the outset) then the OTN IGP would be disjoint
from any client layer IGP.  This is the only way to scale these
networks.....they are quite different for many reasons.

> > 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.
> 
> Neil, I do not see where the disagreement is.
	NH=> OK maybe we agree but its not clear...maybe its simply a
language barrier?

> >> > 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.
> 
> 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".
	NH=> Yes maybe.  I am referring to the latter.
> Alex.
>