[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Moving right along ... generalized-signaling-06
I would also strongly support this modularization approach.
We design our GMPLS software in this manner - would be great if
the drafts also matched that architecture.
-Bill Breck
GMPLS Architect
DeriveIt
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
Behalf Of Zhi-Wei Lin
Sent: Wednesday, December 12, 2001 9:36 AM
To: Ben Mack-Crane
Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
Subject: Re: Moving right along ... generalized-signaling-06
Hi Ben,
Yes I agree. Maybe given the status of protection and complexities that
it would introduce, can we treat it as a separate "function" of GMPLS
and pull it out of the current document and into a new document that
deals exclusively with protection?
It would be a (relatively) simple task:
(1) Remove section 7 of gmpls-sig doc
(2) Remove section 6 of gmpls-rsvpte doc
(3) Remove section 6 of gmpls-crldp doc
and put these sections under a new document called gmpls-recovery (or
gmpls-protection) and then start work on this separately.
Zhi
Ben Mack-Crane wrote:
> Zhi,
>
> A while ago there was a draft proposing a fairly comprehensive
> signaling solution for protection. At the time, there was not
> as much support for working on protection as there is now.
>
> There are several attributes that could be signaled in setting up
> a protection mechanism, including
>
> - whether the path is a working or recovery path
> - what notification mechanism is used to trigger the protection mechanism
> - hold-off time
> - wait-to-restore time, and
> - revertive operation
>
> This was an early draft, so there may be other attributes needed, or some
> simplification might be possible. In any case, the working group must
> decide how to progress the protection work. I don't think it is a good
> idea to take an ill-defined (and perhaps incomplete) solution to RFC.
>
> Regards,
> Ben
>
> Zhi-Wei Lin wrote:
>
>>Hi,
>>
>>To further the discussion, would it be possible to add a new flag for
>>purpose of identifying whether or not a connection (secondary
>>connection) can support extra traffic. A 1:1 connection should be able
>>to support extra traffic (if secondary is not used) while a 1+1 would
>>not support extra traffic.
>>
>>Also, we may want to add a flag for whether or not a protection is
>>revertive.
>>
>>Also, current "link flags" is assumed to provide link protection. Maybe
>>we can add a new flag for either "link" or "path" protection.
>>
>>So the total is three new flags using 3 bits, out of the current 25
>>reserved bits.
>>
>>What do you think?
>>Zhi
>>
>>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.
>>>
>>>
>>>