Re: draft-lang-ccamp-gmpls-recovery-e2e-signaling-01.txt

[Yoshihiko SUEMURA <y-suemura@bp.jp.nec.com>]

Dimitri,

I have a question. Please see inline.

On Wed, 25 Jun 2003 18:10:42 +0200,
Dimitri.Papadimitriou@alcatel.be wrote:

> hi adrian,
> 
> thanks for these comments... see in-line
> 
> Adrian Farrel wrote:
> > Hi,
> > 
> > I've been re-reading this draft.
> > 
> > a. Could you make a text clarifiaction around 'primary' and 'secondary'?
> >     The concepts you cover are useful, but there is some overlap in
> >     terminology since "primary" is ususally used in protection as a
> >     synonym for "working" as "secondary" is a synonym for "backup" or
> >     "protection". I think a text clarification should address my concern.
> 
> we will address this in the next release, please let us know
> if have any specific text to be considered

Does a protecting LSP become a working LSP after a switchover?

In 10.3, the draft says;

   "Activation of a secondary LSP is done using a Path
   refresh message with the S bit set to 0 in the PROTECTION object. At
   this point, the link and node resources must to be allocated for the
   LSP that becomes a primary working LSP (ready to carry normal
   traffic)".
   
There is no description about P bit, but the last sentence implies that
the former protecting LSP become a new working LSP (P bit also set to 0).
If so, the end nodes must manage information of "which LSP was the
INITIAL working", so that they can perform reversion after the initial
working LSP is repaired (I think reversion is mandatory in shared mesh
restoration).

If it is not the case (the initial working LSP is still a "working" LSP
even after a switchover), the end nodes don't have to manage which is
the initial working LSP. Instead, the end nodes must manage which LSP is
in use now.

I think both are possible. So, this is just requesting clarification.

Thank you,

Yoshihiko

> 
> > b. Can you add some explanation of why the PPRO is added and how
> >     it is used. (Hint: each time I read this section I ask the same
> >     question and have to have it patiently explained by the authors!)
> > 
> >     Something to cover...
> >     - Why is the secondary path interested in the primary paths it is
> >        protecting?
> >     - How does this knowledge enable it to share resources?
> >     Answer, it enables a secondary LSP to share resources WITH
> >     ANOTHER secondary LSP if the protected primary paths are diverse.
> 
> we will add text on the why, also more details on processing of
> this object would be appropriate (thus the how) i think a dedicated
> "processing rules" section would address your comment
> 
> > c. Need to explicitly state that the use of the "Associated LSP Id"
> >     field limits the protection schemes supported to 1:1 and 1+1.
> >     That is no 1:n or m:n support is covered in this draft.
> 
> yes it is true that the current end-to-end scope does not cover
> m:n protection (here, 1:n/n:1 could be covered but has not been
> considered since so far in the protocol extensions due to the
> operational feedback if things changes we will adapt the text)
> 
> thanks,
> - dimitri.
> 
> > Cheers,
> > Adrian
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : dimitri.papadimitriou@alcatel.be
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : dpapadimitriou@psg.com
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491
> 
> 


-----------------------------------------------------------------
Yoshihiko SUEMURA 

Networking Research Laboratories, 
NEC Corporation
E-mail: y-suemura@bp.jp.nec.com
Phone: +81 44 856 8109, FAX: +81 44 856 8071