[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... generalized-signaling-06
Eric, all,
Yes of course, whatever you call it "working" and "protection"
/ "primary" and "secondary" / "apple" and "orange" the important
think is that the semantic of these words is interpreted in the
same way by the ingress and egress LSR.
Back to e-mails we have exchanged in May/June on this issue, we
had already determine that the semantic of the LSP we have provided
up to now in the current context is only "primary" and "secondary"
and that using a fast notification mechanism and Path activation
will cover basic needs today.
Back to previous meetings, we also discussed these issues and
concluded (i think it was in March) that protection and restoration
will be covered in details during the next GMPLS steps. More
complex one can be defined (standardized in further work i think
this is purpose of this charter item).
Hope this clarifies,
- dimitri.
"Mannie, Eric" wrote:
>
> Hello Stephen,
>
> John refers to fast restoration schemes that are being studied at the IETF.
> Such schemes are widely implemented in the new classes of optical/TDM
> equipments.
>
> The wording of the text just need to use the terms "working" LSP and
> "protecting" LSP, instead of primary and secondary. That's just an editing
> modification.
>
> The bit itself is useful to qualify the LSP being established.
>
> The mechanisms to be applied to this qualification will be detailed in other
> documents.
>
> In the mean time, I guess that this bit can be used by implementations for a
> simple restoration scheme (e.g. first establish working and protecting LSPs,
> resources of protecting LSP may be "soft reserved", i.e. for extra-traffic,
> when a fault occur send an RSVP-TE rapid failure notification to the source,
> send Path with bit set to "working" on protecting LSP, this kills all LSPs
> using these resources, when acked switch to this LSP).
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Tuesday, December 18, 2001 7:38 PM
> To: John Drake
> Cc: Maarten Vissers; ccamp@ops.ietf.org
> Subject: Re: Moving right along ... generalized-signaling-06
>
> John,
> The problem here is that this is not compatible with transport plane
> protection.
> Assume you do 1:n MSP protection according to ITU Rec. G.841. The operation
> of
> the protection group is controlled by exchange of the K1, K2 bytes in the
> MSOH of the PROTECTION MS. If the control plane reuses the protection MS at
> for a different LSP at a time when the state of the protection group is
> "No Request" (assuming no extra traffic carried on the protection section in
> the
> transport plane), this disables the protection since the endpoints of the
> protection group are no longer able to exchange K1, K2 over the protection
> channel. Even though the payload is unused and irrelevant to the transport
> plane at this point, the exchange of overhead is essential to proper
> operation
> of the protection group.
> Regards,
> Steve
>
> John Drake wrote:
> >
> > Steven,
> >
> > The basic idea is that if a connection is of type 'secondary', then other
> > LSPs of type 'primary' between the same or different source/destination
> > pairs MAY use its resources in intermediate nodes, until that LSP is
> > converted into a 'primary' with a subsequent Path/Resv flow. At this
> point,
> > other LSPs that were using its resources may get pre-empted. Think of the
> > primary/secondary mechanism as a way to ensure temporal priority while
> > allowing network resources to be re-used; i.e., an LSP of type 'secondary'
> > is carrying no data.
> >
> > So in the 1:1 case the protect LSP could be established either as a
> primary
> > or secondary LSP, while in the 1:N case the protect LSP would be
> established
> > as a secondary.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > Sent: Thursday, December 13, 2001 12:15 PM
> > To: John Drake
> > Cc: Maarten Vissers; ccamp@ops.ietf.org
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > It would seem from this standpoint, ANY transport plane protection
> > must use "primary" for all trails. You have already made this argument
> > for the 1+1 case to carry the permanently bridged copy of the payload.
> >
> > In 1:1 or 1:n, when protection is not being used to carry one/any of
> > the normal traffic signals, it may either carry a null signal (no bridge)
> > or transport plane extra traffic. Even if the transport plane has only
> > a null signal on protection, the control plane cannot itself place extra
> > traffic on any portion of the end-to-end protection channel as this is
> > where the APS protocol is carried to coordinate the 1:1 or 1:n protection.
> > The protection channel overhead is chosen to carry the APS since it is
> > necessary to exchange APS bytes to complete a switch when working channels
> > are failed. If the protection channel has failed and APS cannot be
> > exchanged,
> > normal traffic signals will not be selected from protection.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Maarten,
> > >
> > > That's fine, however it's beside the point. The semantics of
> > > Primary/Secondary refer to the control plane and whether the node
> > > establishing a given LSP is planning to use it at the time it's
> > established
> > > or at a later time. As I indicated in an earlier note, 1+1 transport
> > plane
> > > protection would be accomplished in the control plane by establishing
> two
> > > LSPs of type Primary. The control plane really doesn't care which LSP
> the
> > > transport plane is using as Working and which as Protect, although that
> > > information is available to the control plane at the LSP endpoints.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > > Sent: Thursday, December 13, 2001 12:15 AM
> > > To: ccamp@ops.ietf.org
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > 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.
> > > > >
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard