[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... generalized-signaling-06
See in-line.
Regards,
Ben
John Drake wrote:
>
> -----Original Message-----
> From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> Sent: Wednesday, December 12, 2001 10:10 AM
> To: Jonathan Lang
> Cc: John Drake; Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
> Subject: Re: Moving right along ... generalized-signaling-06
>
> Jonathan,
>
> I agree that both the working and recovery paths must be connected
> and carrying traffic (except at the egress). It is a problem that
> the term "primary" is being overloaded to indicate both "working"
> and "connected in transit nodes".
>
> JD: The fact that you don't understand the semantics of the
> Primary/Secondary
> bit doesn't necessarily mean that they're incorrect
The fact that the semantics are unclear, and in fact misleading,
is a problem.
>
> If it is an endpoint decision as to which is the working and which
> is the recovery path, this seems to add more complexity to the
> operator's job in setting up protected paths.
>
> JD: Assertion
What do operator's think about having provision the signaled path
AND separately configure the protection in the endpoints? What if
only a part of the path needs protection?
>
> It would seem quite
> reasonable to signal which path is which.
>
> JD: And why would the intermediate nodes care?
The same could be said for G-PID!
>
> Regards,
> Ben
>
> Jonathan Lang wrote:
> >
> > 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.