Re: FW: Comments on "Network Hierarchy and Multilayer Survivability"draft

[Jim Boyle <jimpb@nc.rr.com>]

On Mon, 17 Sep 2001, Dave McDysan wrote:

> Additional off-line comments received.

off-line comments commented on in-line.
Tell Yong thanks for the review and comments.

Jim

>
> Dave
>
> -----Original Message-----
> From: Yong Xue [mailto:yong.xue@wcom.com]
> Sent: Wednesday, September 12, 2001 12:46 AM
> To: dave.mcdysan@wcom.com; wlai@att.com
> Cc: Yong Xue
> Subject: Comments on "Network Hierarchy and Multilayer Survivability"
> draft
>
>
>
> Hi, Dave and Wai,
>
> Here are some of my comments on the draft. At least two of them I have
> expressed at the last TE meeting in London.
>
> 1) I would suggest to change the word "Hierarchy to "Partition" in the
> document. It's true that the vertical partition will generate hierarchy,
> but horizontal partition based on technology, administration domain,
> network architecture, usually generates domains/areas of sub-networks which
> could either bear an implied hierarchical relationship (e.g.
> metro-core-metro) or a peer relationship (e.g. two ISP networks)

This has been brought up a few times.  I understand this conceptually,
PNNI allowed for multiple layers of regions, BGP obviously does too.
But we are only talking intra-domain here (at least now), and for that
when one breaks these up, you actually create some hierarchy.  OSPF
areas are hierarchical.  RSVP within RSVP is hierarchical.  Let's wait
and see what some of the technical proposals are before worrying too
much on what exact word we should use to call it.  But from the
application specifications (e.g. large VPNS edge to edge w/ tunnels,
perhaps through OSPF areas) - I think we'd be wrong to call this
partition.

>
> I have attached a page of write-up on the network partition cut and pasted
> from one of my writing before. Please feel free to use it if you think they
> are useful.
>
> 2) In section 4.2, the document has described different "operation modes"
> (detection, protection, etc.), but it did not give the description of the
> order of sequence in terms of mode changes. This is needed to give reader a
> sense of how the network failure will be monitored, detected and mitigated
> and how to identify different phases for the failure handling, which will
> impose the requirements on the signaling control.

For that, we could refer to draft-ietf-mpls-recovery-frmwrk-03 - right?

>
> 3) The document has focused on the P&R requirement at the network layer,
> but ignored the drop-side interface failure (e.g. between customer and
> network border node, or a router to an OXC). This is a very important type
> of network failure. This may be either inter-layer or inter-domain cases
> depending on the actual network configuration.

For one, we are talking about intra-domain, which I don't think
includes the handoff to customers, so in optical sense, we are talking
network, not trib.  As for failures between routers and OXCs, and even
between routers, these are often viewed in IP world as losses of long
distance capacity (it's both loss of 0+1 capacity).  There may be
something interesting in looking at APS, and even optical/router
integrations going forward, but for now I think we should keep a tight
scope and see if we get anything out of that.  We (or someone) could
always expand the requirements after we get some technical, standard
solutions to some pressing needs.  I think the general approaches
spelled out do work for optical networks too, though Yong has a better
understanding of this, so if he'd like to point out some practical
applications and problems Worldcom expects it might see in the near
term that can be aided here, ask if he'd like to rewrite another
email, or maybe we could accomodate another call with a few of us and
him. (Wed am?).

>
> 4) In many places, the document has claim the difficulty of edge-to-edge
> signaling under multi-domain (e.g. 6.2, 6.3). It's not clear to me if it is
> the LSP path calculation problem due to topology information aggregation
> across the domain boundary or actually the signaling problem. You need to
> define exactly what the problem is with example.

One difficulty is just that most router vendors won't allow you to
signal across areas, though there is no specification reason why one
couldn't.  Another is the potential for lots of edge to edge signalling
to create lots of signalling state in the core, and even on the edges
themselves.  In the VPN context, I think one would have to be very
careful about how extensively one uses tunnels.  In the UUNet case, for
instance, I would guess that meshing every edge router, or even
offering VPN on every edge router (with a partial mesh) would be
challenging.  Having market-by-market VPN routers might work (ie.
address scalability by reducing scale :).  Something with LDP might
work too.

As for "topology abstraction", I'm interested in what Yong thinks the
practical difference would be (for OSPF case, at least) of conveying
abstracted topologies across areas, as opposed to just letting plain old
OSPF select where you cross area boundaries.

>
> 5) In section 5.5, do you allow the lower layer to trigger the upper layer?
> If the lower layer does not have rerouting capability (say unprotected
> SONET circuit), then it should allow the SONET layer to trigger (LOS) the
> IP layer and let IP to reroute immediately.

yep, as we've discussed, this is allowed on all high end routers and
atm switches.  Dave - as you were the main contributer on this section
(I think) can you maybe add something to the effect that in practice,
most equipment does allow this type of configuation (tailoring).  It
might head this off, as we've heard this comment a few times.

>
> Hope these comment are useful.
>
> I am very interested in the P&R, let me know if you need any help.
>
> Thanks.
>
> /Yong
>
> Distinguished Engineer
> Optical and Data Network Technology Development
> WolrdCom, Inc.
> email: yong.xue@wcom.com
> Tel: 703-886-5358
>