hi yoshihiko, see in-line... Yoshihiko SUEMURA wrote:
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).
yes, you're right in shared mesh this is the case.
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.
yes, thanks for the pointer clarification is needed (suggestion be to remove the the word "working" here) consistently with the reversion mechanism described in section 12. thanks, - dimitri.
Thank you, Yoshihikob. 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 commentc. 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
-- 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