Re: Moving right along ... generalized-signaling-06
Maarten Vissers <mvissers@lucent.com> Wed, 19 December 2001 08:39 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Dec 2001 00:42:08 -0800
Cc: ccamp@ops.ietf.org
Message-ID: <3C20522B.622638F2@lucent.com>
Date: Wed, 19 Dec 2001 09:39:07 +0100
From: Maarten Vissers <mvissers@lucent.com>
Organization: Lucent Technologies
MIME-Version: 1.0
To: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>
Original-CC: ccamp@ops.ietf.org
Subject: Re: Moving right along ... generalized-signaling-06
Content-Type: multipart/mixed; boundary="------------F4686F4EFA632F5479589A26"
Ben, GMPLS is a control plane with the intention to perform a connection management role for the transport plane. Protection is a transport plane build in feature, and it would certainly be wise that GMPLS uses the same terminology as the transport plane. It will definitely reduce the amount of misunderstanding and thus interworking problems. A major difference between protection and restoration is that protection makes use of pre-assigned capacity between nodes, whereas restoration makes use of any capacity available between nodes. I.e. this latter capacity is not typically pre-assigned to a particular connection. Therefore, it is better to have terminology associated with those differences. I.e. for protection "working" and "protection" connections and "normal" and "extra traffic" signals are applicable and should be used. For restoration there is only one connection active at any time, so the working/protection doesn't apply here... I do not have terminology yet, I can only offer some suggestions... Before there is a signal fail condition in the network, all traffic is transported over one connection between ingress and egress points of the network. What is the terminology we use for such connections? E.g. "normal connection" or just "connection"? Some of the unused (G.805) link capacity and fabric capacity may be reserved for rerouting of the normal signals when their transport is interrupted. When a signal fail condition exists, alternate connections or connection segments are to be computed and set up after which the original connection or connection segment is released. At this point there is just one connection present... i.e. the normal connection or just the connection. So we need terminology to identify the alternate connection (segment), which exists as alternate connection (segment) for the period up to the release of the original connection (segment). I.e. it is a temporary indication, and thus more like a state. So perhaps "alternate" and "original" connection (segment) are the appropriate terms to use to indicate the temporary states assigned to existing interrupted connection (segment) and its replacement. Regards, Maarten PS. the term "path" is a reserved term in the transport plane. A "path" is a "trail in a path layer network". Restoration typically implies the replacement of one (serial compound) link connection by another (serial compound) link connection. Restoration doesn't replace trails. Ben Mack-Crane wrote: > > Maarten, > > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt) > we chose "working path" and "recovery path." We used "recovery" instead of "protection" > because it seemed a more neutral term given that we were including both protection > switching and reroute recovery mechanisms. > > We did not address the state (active/standby). We use the terms "extra traffic" and > "working traffic" (perhaps the latter could be changed to "normal traffic"). > > It would be useful in moving forward in CCAMP if we could try to adopt terms > that are consistent with those in current use elsewhere. > > Regards, > Ben > > Maarten Vissers wrote: > > > > There exist well defined protection terminology in ITU-T for the transport > > plane. "Working" and "Protection" are being used and not primary/secondary. E.g. > > a 1+1 architecture has one working connection, one protection connection and a > > permanent bridge. > > > > Besides working/protection indication for the transport entity, there is > > - "active" and "standby" to indicate if the signal is selected from the working > > or protection transport entity; i.e. if selector selects from working, the > > working is active and protection is standby, if the selector selects from > > protection the working is standby and the protection is active. > > - "normal" and "extra traffic" signal. The normal signal is protected. > > > > Regards, > > > > Maarten > > > > neil.2.harrison@bt.com wrote: > > > > > > Jonathan....review the text below....I think the problem is 1:1. > > > > > > neil > > > > > > > -----Original Message----- > > > > From: Jonathan Lang [mailto:jplang@calient.net] > > > > Sent: 12 December 2001 17:46 > > > > To: 'Ben Mack-Crane'; John Drake > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > Subject: RE: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > Ben, > > > > Please see inline. > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > > -----Original Message----- > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > Sent: Wednesday, December 12, 2001 8:56 AM > > > > > To: John Drake > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > See comment below. > > > > > > > > > > Regards, > > > > > Ben > > > > > > > > > > John Drake wrote: > > > > > > > > > > > > Snipped > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com] > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM > > > > > > To: Lou Berger > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org > > > > > > Subject: Re: Moving right along ... generalized-signaling-06 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >7) In Protection Information it states "The resources > > > > > allocated for a > > > > > > > > secondary LSP MAY be used by other LSPs until the > > > > > primary LSP fails > > > > > > > > over to the secondary LSP." This may not always be > > > > > the case. An > > > > > > > > explicit flag indicating whether or not extra > > > > > traffic may use the > > > > > > > > secondary path resources is needed. > > > > > > > > > > > > > > ??? This is the purpose of this bit. > > > > > > > > > > > > This is not clear from the definition. The bit is defined > > > > > as indicating > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1 > > > > protection the > > > > > > secondary LSP may not be used for extra traffic. > > > > > > > > > > > > Perhaps the problem here is that protection features are > > > > > being defined > > > > > > before the protection framework and requirements are > > > > done. Is this > > > > > > presupposing some particular outcome of the recovery work in CAMP? > > > > > > > > > > > > JD: I think the definition of the bit is fine. For both > > > > > 1+1 and 1:1 > > > > > > protection, there would be a pair of Primary LSPs between > > > > the source > > > > > > and destination, rather than a Primary and a Secondary. > > > > > > > > > > This is an unusual use of terms. I have never encountered a case > > > > > where both the working and recovery paths are call "primary." > > > > > > > > > > This is not consistent with either draft-mpls-recovery-framework > > > > > or with draft-lang-ccamp-recovery. I think this is a sign that the > > > > > protection work is immature and not ready for progressing to RFC. > > > > > > > > > For 1+1 path protection, both working/recovery paths are > > > > carrying user data > > > > traffic and it is an endpoint decision as to which path is > > > > actually the > > > > working/recovery path. At a transit node, both paths need to > > > > be treated as > > > > primary, as the resources are currently being used and > > > > obviously can't be > > > > used for Extra Traffic. > > > >
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Dimitri Papadimitriou
- Re: Moving right along ... generalized-signaling-… Dimitri Papadimitriou
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- RE: Moving right along ... generalized-signaling-… John Drake
- RE: Moving right along ... generalized-signaling-… Mannie, Eric
- Re: Moving right along ... generalized-signaling-… Stephen Trowbridge
- Re: Moving right along ... generalized-signaling-… Stephen Trowbridge
- Re: Moving right along ... generalized-signaling-… Zhi-Wei Lin
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- Re: Moving right along ... generalized-signaling-… Stephen Trowbridge
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- Re: Moving right along ... generalized-signaling-… Lou Berger
- RE: Moving right along ... generalized-signaling-… John Drake
- RE: Moving right along ... generalized-signaling-… neil.2.harrison
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- RE: Moving right along ... generalized-signaling-… Bill Breck
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- RE: Moving right along ... generalized-signaling-… Jonathan Lang
- RE: Moving right along ... generalized-signaling-… Jonathan Lang
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Zhi-Wei Lin
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Zhi-Wei Lin
- Re: Moving right along ... generalized-signaling-… Richard Douville
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Lou Berger