RE: Three GMPLS related IDs

[Sivakumar Sankaranarayanan <ssnarayanan@lucent.com>]

Neil,
  I generally agree with your observations, please see below for some
specific
comments...

Regards,
Shiva.

neil.2.harrison@bt.com wrote:

> Hi Yangguang, you wrote 05 March 2001 14:29:
> > FYI, three GMPLS related IDs have been submitted.
> >
> > Architecture:
> >
> http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-arch-intra-domain-0
> 0.txt
> >
> >Signaling:
> >http://www.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-reques
> t-01.txt
> >http://www.ietf.org/internet-drafts/draft-xu-ccamp-gmpls-sig-reorg-00.txt
> >
> >Comments are welcomed.
>
> Here are my observations on the sig-reorg and arch-intra-domain IDs (I could
> not open the label-request one):
>
> sig-reorg ID:
>
> 1       I noticed that NSAPs are mentioned in 6.2.  Yes, I think this form
> of global addressing will be of considerable interest and importance to
> several carriers and should be included.  It is something we are currently
> looking closely at and almost certainly will require to be supported.

>
> 2       The 'connection ID' noted in para 7.2.2 seems to be the same
> (similar?) to a trail termination identifier and, as noted, requires global
> uniqueness.  I noted that you have this 'TBD' wrt size/format.....this seems
> a sensible decision since something larger that 32 bits will surely be
> required here.
>

[Siva] Agreed.  I think there are some issues with respect to whether
the
connetion ID is global or locally unique that needs to be addressed. For
global
uniqueness, there must be coordination amongst the providers and vendor
on the
format and range of values for the ID. For local uniqueness, there must
be some translation function that maps the locally unique connection IDs
to provide an end-to-end view of the ID.


>
> 3        I was a little unclear regarding the requirement given in the 1st
> bullet in para 9.1.  Agree that user and control plane *networks* can (and
> will usually) be disjoint....indeed the control-plane network *must* only
> take its survivability design cues from the duct network, since only that
> layer can define the inherited real disjoint connectivity.  Further, both
> the control plane and user plane network need their own OAM....and in the
> control plane not only is this for the 'physical transport' aspects, but
> also on a per protocol-type, ie the signalling protocol will have different
> failure modes to the routing protocol.  One feature that is required
> however, is that user-plane failures can map to control-plane actions for
> invoking restoration (the reverse of this is clearly not true)...for example
> to restore S-PVC-like user-plane trails (see also point 5 below).   So I
> would like to see these types of relationship made more clear.
>

[Siva] I think the document needs to have an expanded discussion on the
implications of the user plane and control plane.

>
> 4       A further observation wrt the above is that it seems you are
> advocating that all failures be conveyed by control-plane message 'events'.
> Are you suggesting that (at least) the 3 distinct areas of (i) user-plane
> failures, (ii) signalling protocol failures and (iii) routing protocol
> failures all get 'merged' into some generic form of event notification?  I
> would have thought that one would need notification (and general defect
> handling) per protocol type, and that this would be a function of that
> protocol only since the failure modes of each would be different (and if one
> changes one protocol one would not want to create backwards compatibility
> issues with another).
>

[Siva]  Yes, currently there is no clear separation of the events
generated from

different sources. Maybe we need to discuss further on the rationales
for this separation. For example, a user plane failure that impacts
traffic would definitely need to be signaled to the control plane. 
However,
when you say signaling "protocol" failures and routing "protocol"
failures, what are you referring to, is it the failure of the "box" that
is
implementing the signaling and routing software? Is it the failure of
the link
in
the SCN?  Is it a wrong routing decision?  If it is failure of the
DCN/SCN, then
it should be protected by theDCN/SCN failure recovery methods, e.g.,
protected
signaling channels.  If it is a
box failure, then it is a bigger problem and not only is restoration
mechanisms
supposed to kick in, but some maintenance action is needed and so the
management

system would have to be informed as well.

>
> Further, if some aspects of the control-plane fail I would still expect the
> user-plane defect handling to carry on as an autonomous function....for
> example, the sending of a FDI into client layers to suppress alarm storms
> and protect user-plane traffic, eg squelch traffic on misrouting if trail ID
> mismatch.  I am not sure we would want to make this low-level action
> dependent on a 'healthy control-plane'....and this seems quite important
> when one has a server->client adaptation function between 2 different
> technologies, eg OTN layer->SDH layer, and where a 'common control-plane'
> might not be appropriate across such a (different operator domain)
> boundary....a point you indeed make in para 4 in the Arch-intra-domain ID.
> Can you please explain the intent of this section more clearly and comment
> on the above points, including the network management of the control-plane
> ....maybe you have some new ideas here that are worth exploring further?
>

[Siva] Yes, I completely agree with your statements. I dont think we
should
reinvent what is already a global standard, i.e., existing transport
network
defect handling
 capabilities. For example, the equipment functional blocks described in
 G.783 (for SDH) and G.798 (for OTN) and the various defects and
 consequent actions described are still valid.

Regards
Siva.