The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] draft-ietf-mpls-lmp-01.txt
neil, 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. > 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. > 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. > 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. >> > 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". Alex.
|
|