Subject: Last call review of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Mar 2005 00:30:42 -0000

Hi,
I've got a couple of comments in what seems like quite a long draft.
Adrian

Abstract:
   This document describes protocol specific procedures and extensions 
   for Generalized Multi-Protocol Label Switching (GMPLS) Resource 
   ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to 
   support end-to-end Label Switched Path (LSP) recovery that denotes 
   protection and restoration.
Not sure what is meant by "denotes" in this context.
Perhaps "is used to provide" ?
===
Section 2
OLD
   In addition, the reader is assumed to be familiar with the 
   terminology used in [RFC3945], [RFC3471], [RFC3473] and referenced 
   as well as [TERM] and [FUNCT]. 
NEW
   In addition, the reader is assumed to be familiar with the 
   terminology used in [RFC3945], [RFC3471], [RFC3473],
   as well as in [TERM] and [FUNCT]. 
===
Section 2
   Checklog List from revision v01.txt:  
Please either remove this text or mark it so that the RFC editor will remove it.
===
Section 3
Although the second paragraph defines "end-to-end protection" I would like to see this pulled out into its own paragraph for emphasis, and also a little more clarity added to the definition. For example, it would appear that your four types of e2e protection are all have the protecting and protected LSPs disjoint in some way - this makes it appear that this is a property of e2e protection in general and you should state this if it is true.
===
Section 3 para 5
   In 1:N (N =< 1) protection with extra-traffic,
Hopefully you mean N >= 1  
===
Section 3 para 5
I note that you do not distinguish between 1:N and 1:N-with-extra-traffic.
If there is a reason for this perhaps you could add a note to the text.
===
Section 3
OLD
   working one. Here, the recovery resources for the protecting LSP are 
   pre-reserved and explicit action is required to activate (i.e. 
NEW
   working one. Here, the recovery resources for the protecting LSP are 
   pre-reserved but explicit action is required to activate (i.e. 
                ^^^
===
Section 3
OLD
   requirements by allowing multiple protecting LSPs to share common 
   link and node resources. The recovery resources are pre-reserved and 
NEW
   requirements by allowing multiple protecting LSPs to share common 
   link and node resources. The recovery resources are pre-reserved but
                                                                    ^^^ 
===
Section 3
   Note that in both 
   cases, any lower priority LSP that would use the pre-reserved 
   resources for the protecting LSP(s) MUST be preempted during the 
   activation of the protecting LSP. 
This sentence comes out of the blue. The whole of the paragraph up to then has not even mentioned extra traffic. I suggest you insert a paragraph break and a sentence explaining how the pre-reserved resources may be used to support an extra-traffic LSP...
Also, delete "would".
===
Section 3
   Full LSP re-routing (or restoration) switches normal traffic to an 
   alternate LSP that is fully established only after working LSP 
   failure occurs.
This text does not read well in English. In fact, the same is true of pre-planned. What you mean is, I think, as follows...
   Full LSP re-routing (or restoration) switches normal traffic to an 
   alternate LSP that is not even partially established until after 
   the working LSP failure occurs. 
===
Section 3
   Note that crankback signaling (see [CRANK]) and LSP segment recovery 
   are further detailed in dedicated companion documents. Also, there 
Need to add a citation for LSP segment recovery.
===
Section 4.2
OLD
   The recovery attributes includes all the parameters that determine 
NEW
   The recovery attributes include all the parameters that determine 
===
Section 4.2.1
   - S (Secondary) bit: enables distinction between primary and  
     secondary LSPs. A primary LSP is a fully established LSP for  
     which the resource allocation has been committed at the data plane  
     (i.e. full cross-connection has been performed). Both working and  
     protecting LSPs can be primary LSPs. A secondary LSP is an LSP  
I am uneasy about this definition of "primary". In [TERM] the only mention of "primary" is in section 2...
   Recovery typically involves the activation of a recovery (or
   alternate) LSP when a failure is encountered in the working (or
   primary) LSP.
This implies that "primary" is a synonym for "working".
Further, RFC3471 has a subtly different meaning for "secondary" in section 7.
   Protection Information also indicates if the LSP is a primary or
   secondary LSP.  A secondary LSP is a backup to a primary LSP.  The
   resources of a secondary LSP are not used until the primary LSP
   fails.  The resources allocated for a secondary LSP MAY be used by
   other LSPs until the primary LSP fails over to the secondary LSP.  At
   that point, any LSP that is using the resources for the secondary LSP
   MUST be preempted.
Can we please not modify the interpretation of the S-bit.
If you need to flag a new piece of information (to distinguish between resource allocated and not) then please introduce a new flag.
Note that the P-bit appears to be slightly orthogonal because the text seems to describe the *current* role of the LSP. (The S-bit in RFC3471 describes the role at the time the LSP is set up, I think).
===
Section 4.3
OLD
   When used for the working LSP signaling, the Association ID of the 
NEW
   When used for signaling the working LSP, the Association ID of the 
===
Section 4.3
OLD
   When used for the protecting LSP signaling, this field identifies 
NEW
   When used for signaling the protecting LSP, this field identifies 
===
Section 5
   When a failure occurs (say at node B) and is detected at end-node D, 
   the receiver at D selects the normal traffic from the other LSP. 
   From this perspective, 1+1 unidirectional protection can be seen as 
   an uncoordinated protection switching mechanism acting independently 
   at both end-points. Also, for the protected LSP under failure 
   condition, the Path_State_Removed Flag of the ERROR_SPEC object (see 
   [RFC3473]) SHOULD NOT be set upon PathErr message generation. 
So, what you are saying is that in 1+1 protection the network may *never* know that the error is so bad that the LSP is dead, but MUST leave that choice to the ingress. While this is the operational practice in many transport networks, I don't see why you make this as strong as a SHOULD NOT.
===
Section 5
   Note: one should assume that both paths are SRLG disjoint otherwise, 
   a failure would impact both working and protecting LSPs. 
What is this supposed to tell the reader? That he should make the assumption or that he should ensure SRLG diversity? ;-)
Actually, I think you want to say that the quality of 1+1 protection may vary. Allowing link diverse, node diverse or SRLG diverse 1+1 protection.
(ditto section 6 and 7)
===
Section 5.1
   Since both LSPs belong to the same session, the SESSION object MUST 
   be the same for both LSPs. 
An undisputable conclusion drawn from an unproven premise.
Why must both LSPs belong to the same session? A one line explanation would start the section off nicely.
===
Section 5.1
   A new PROTECTION object is included in the Path message. This object 
What is the implication of "new"? I guess you mean the new type defined in this draft.
===
Section 5.1
   A new PROTECTION object is included in the Path message. This object 
   carries the desired end-to-end LSP Protection Type (in this case, 
   "1+1 Unidirectional"). This LSP Protection Type value is applicable 
   to both uni- and bi-directional LSPs. 
This is unclear. In section 14.1 you have 
                0x08    1+1 Unidirectional Protection  
                0x10    1+1 Bi-directional Protection 
===
Section 5.1
Your description of the use of the P-bit for 1+1 protection isn't clear. You mean to say that the P-bit indicates which LSP the ingress would *prefer* to be the protecting LSP if all other things are equal, but your text (and the description of the P-bit in sections 4.2.1 and 14) don't make this clear.
===
Section 6.2
   directions. This is done using the Notify message with a new Error 
   Code indicating "Working LSP Failure (Switchover Request)". The 
I don't see this in the IANA section, and I wonder if you also mean Error Value?
===
Section 6.2
   directions. This is done using the Notify message with a new Error 
   Code indicating "Working LSP Failure (Switchover Request)". The 
   Notify Ack message MUST be sent to confirm the reception of the 
   Notify message (see [RFC3473], Section 4.3).    
I see no definition of a "Notify Ack message" in RFC3473 (in any section).
I am worried that you are confusing the Ack message with a new procedure requiring a handshake of Notify messages.
===
Section 6.2
        1. If an end-node (A or D) detects the failure of the working  
           LSP (or a degradation of signal quality over the working  
           LSP) or receives a Notify message including its SESSION  
           object within the <upstream/downstream session list> (see  
           [RFC3473]), it MUST begin receiving on the protecting LSP  
Note that the sender descriptor or flow descriptor is also present in the Notify and this will considerably help resolve ambiguities and race conditions since it identifies the LSP.
===
Section 6.2
        1. If an end-node (A or D) detects the failure of the working  
           LSP (or a degradation of signal quality over the working  
           LSP) or receives a Notify message including its SESSION  
           object within the <upstream/downstream session list> (see  
           [RFC3473]), it MUST begin receiving on the protecting LSP  
I don't think the receipt of a Notify message is sufficient, per se. I think the error code and value need to indicate a problem with the LSP.
===
Section 6.2
        1. If an end-node (A or D) detects the failure of the working  
           LSP (or a degradation of signal quality over the working  
           LSP) or receives a Notify message including its SESSION  
           object within the <upstream/downstream session list> (see  
           [RFC3473]), it MUST begin receiving on the protecting LSP  
           and send a Notify message reliably to the other end-node (D  
           or A, respectively).
"...send a Notify message reliably" will certainly be misunderstood.
You presumably mean "...send a Notify message including the Message_ID object".
===
Section 6.2
        2. Upon receipt of the switchover message, the end-node  
           (D or A, respectively) MUST begin receiving from the  
           protection LSP and send a (Notify) Ack message to the other  
           end-node (A or D, respectively) using reliable message  
           delivery (see [RFC2961]). 
While this clarifies the use of Ack rather than Notify Ack (not sure why you need to include "(Notify)") it is now confused about the delivery of the Ack message. How do we achieve reliable delivery of an Ack message?!
===
Section 7
   Although the resources for the protecting LSP are pre-allocated, 
   preemptable traffic may be carried end-to-end using this LSP (i.e. 
   the protecting LSP is capable of carrying extra-traffic) with the 
   caveat that this traffic will be preempted if the working LSP fails. 
Do you mean that the extra traffic is carried "using this LSP" or "using some or all of the resources assigned to this LSP"?
===
Section 7
   Also, if extra-traffic is carried over the protecting LSP, the 
   corresponding end-nodes may be notified of the failure in order to 
   complete the switchover.  
I think this is "end-nodes may need to be notified"
===
Section 7.2
   To co-ordinate the switchover between end-points, an end-to-end 
   switchover request is needed such that the affected LSP(s) are moved 
   to the protecting LSP.
In what way may there be more than one affected LSP moved to a single protecting LSP?
===
Section 7.2
   This operation may be done using a Notify message exchange with a 
   new Error Code indicating "(Working) LSP Failure (Switchover 
   Request)". The Notify Ack message MUST be sent to confirm the 
   reception of the Notify message.  
All of the same comments as for section 6.2.
Also:
- Why do you say "may be done"?
- Is this the same error code as in 6.2? (the text is slightly different)
=== 
Section 7.3
OLD
   provisioned protecting LSP is resource-disjoint LSP from the N 
NEW
   provisioned protecting LSP is resource-disjoint from the N 
===
Section 7.3
Can you highlight that the N working LSPs are all between the same pair of end points.
===
Section 8
OLD
   this does not mean that the corresponding resources can not used by 
NEW
   this does not mean that the corresponding resources can not be used by 
===
Section 8
   To make bandwidth pre-reserved for a protecting (but not activated) 
   LSP, available for extra traffic this bandwidth could be included in 
   the advertised Unreserved Bandwidth at priority lower (means 
   numerically higher) than the Setup Priority of the protecting LSP. 
This feels like it should be the Holding Priority. That is, the Setup Priority was only important for how it could displace pre-existing LSPs.
===
Section 8.3
OLD
   From [GMPLS-ARCH], the secondary LSP is setup with resource pre-
NEW
   From [RFC3945], the secondary LSP is setup with resource pre-
===
Section 9
OLD
   plane) a specific protecting LSP instantiated during the (pre-
   )provisioning phase. This requires restoration signaling along the 
NEW
   plane) a specific protecting LSP instantiated during the (pre-)
   provisioning phase. This requires restoration signaling along the 
===
Section 9
   resource sharing), the LSPs must have the same Session Ids, but the 
   Session Id includes the target (egress) IP address. These addresses 
2xs/Id/ID/
Suggest a search for "id"
===
Section 9.3
OLD
   From [GMPLS-ARCH], the secondary LSP is setup with resource pre-
NEW
   From [RFC3945], the secondary LSP is setup with resource pre-
===
Section 10
OLD
   activated. Additional condition raises from mis-connection avoidance 
NEW
   activated. An additional condition arises from mis-connection avoidance 
===
Section 10
OLD
   Note that step 1 may cause alarms to be raised for the pre-empted 
   LSP. If alarm suppression is desired the pre-empting node MAY expand 
   before applying step 1 act as follows. 
NEW
   Note that step 1 may cause alarms to be raised for the pre-empted 
   LSP. If alarm suppression is desired the pre-empting node MAY insert
   the following steps before step 1. 
===
Section 10
   At the downstream node (with respect to the pre-empting LSP) the 
   processing is RECOMMENDED to be as follows: 
    
   1. Receive PathTear (and/or PathErr) message for the pre-empted  
      LSP(s). 
    
   2a.Release the resources associated with the LSP on the interface 
      to the pre-empting LSP, remove any cross-connection and release  
      all other resources associated with the pre-empted LSP. 
   2b.Forward the PathTear (and/or PathErr) message per [RFC 3473]. 
    
   C. Receive the Path message for the pre-empting LSP and process as  
      normal, forwarding it to the downstream node. 
    
   D. Receive the Resv for the pre-empting LSP and process as normal, 
      forwarding it to the upstream node. 
Cool numbering scheme :-)
Any chance of settling on something more conventional?
===
Section 11.2
   Note: when the end-to-end LSP Protection Type is set to 
   "Unprotected", both S and P bit MUST be set to 0 and the LSP SHOULD 
   NOT be re-routed at the head-end node after failure occurrence. The 
   Association_ID value MUST be set to the LSP_ID value of the signaled 
   LSP. 
Please explain the difference between an attempt to "re-route" and an attempt to "re-establish". presumably it could involve:
- a time difference
- the use of make-before-break for failed LSPs.
- the use of the ASSOCIATION object.
I would like to make sure that you are not applying "SHOULD NOT" to LSP re-establishment.
===
Section 12
OLD
   allocated to the LSP that was originally routed over it even after a 
NEW
   allocated to the LSP that was originally routed over them even after a 
===
Section 12
   - then, apply the reverse 1-phase APS switchover request/response  
     (or 2-phase APS) described in Section 6.2 (or Section 7.2,  
This is the first mention of APS
===
Section 13
I think this section is going to give us grief during IESG review :-(
Why do we need to tie this so closely with NMS etc. And why describe it as external?
Can't we simply describe the function by:
- dropping the first para
- in C, D and E drop "externally"
- in D and E replace "manual" with "requested"
===
Section 13 TWICE
OLD
   Recovery signaling operation is initiated externally that switches 
NEW
   Recovery signaling is initiated externally that switches 
===
Section 13 (A and B)
   is set to either 0x04, or 0x08 or 0x10. 
I would prefer you to use the meanings rather than the values.
===
Section 13 (D and E)
   This, unless a fault condition exists on 
? "This is allowed"? "This is possible"? "This is successful"?
===
Section 14
OLD
   use so that the object can be included in the Notify message to act 
   a switchover request for 1+1 bi-directional and 1:1 protection.  
NEW
   use so that the object can be included in the Notify message to act 
   as a switchover request for 1+1 bi-directional and 1:1 protection.  
===
Section 14.1
I believe we have had this discussion before.
We don't introduce reserved fields for future extensibility. We only do it for padding.
If you are certain that we need to extend in the future then please use sub-objects or TLVs.
This means that you can:
a. Remove the last four bytes of the Protection object.
b. Retain the C-Type from RFC3473
===
Section 15
   This object MUST be 
   present in the Path message (for the pre-provisioning of the 
   secondary protecting LSP) if and only if the LSP Protection Type 
   value is set to "0x02".
"MUST if and only if" is not really in RFC2119.
Can we two statements. One with "MUST" and one with "MUST NOT".
===
Section 15
In the case where my protecting LSP protects only one working LSP and where the full path of the protecting LSP is known by the ingress (strict and explicit) and there is no resource sharing between the protected and protecting LSP, I can't see why I must include a PPRO.
In other words, PPRO is an enabler of function (as stated in section 15.4 "The PPRO enables of sharing recovery resources between a given secondary protecting LSP and one or more secondary protecting LSPs if their corresponding primary working LSPs have mutually (link/node/SRLG)disjoint paths."), but that does not make its presence mandatory.
===
Section 15.1
   The contents of a PRIMARY_PATH_ROUTE object are a series of 
   variable-length data items called subobjects. The subobjects are 
   identical to those that can constitute an EXPLICIT/RECORD ROUTE 
   object as defined in [RFC3209], [RFC3473] and [RFC3477]. 
This seems in contradiction with section 15.3
===
Section 15.4
OLD
   The PPRO enables of sharing recovery resources between a given 
NEW
   The PPRO enables sharing of recovery resources between a given 
===
Section 16
   The ASSOCIATION object is used to associate LSPs with each other. In 
   the context of end-to-end LSP recovery, the association MUST only 
   identify LSPs that support the same Tunnel ID.
Hmmm. presumably same source and destination is relatively important too.
===
Section 16
   The ASSOCIATION object is used to associate LSPs with each other.   
You already said this.
===
Section 16.1
      Association ID: 16 bits 
    
        A value that when combined with Association Type and  
        Association Source uniquely identifies an association.  
It would be helpful to state who assigns this value.
===
Section 16.1
      Association Source: 4 or 16 bytes 
    
        The IP address of the node that originated the association. 
"The IP address"?
Question. Are two associations with the same Association ID equivalent if the Association Source addresses are different but identify the same node?
Answer (it transpires) is "no". 
You need to make this much clearer here.
===
Section 17
Isn't Notify modified as well?
And I thought Resv was, but I may have been sleeping.
===
Section 18
This is a bit poor.
If you don't modify the "external commands" section, you'll certainly have to discuss security for them. After all, a forced failover can be pretty disruptive.
But I think you need to discuss misconnection here. In particular when there is mesh protection going on.
===
Section 19
The IANA section needs some gardening to make it really easy for IANA to implement.
- Break it up into clearer subsections.
- Make sure you have included all of the information needed in the registry
- Point back at the defining sections of the draft
- Only have suggested values in one place in the document
- Be consistend in using TBD or TBA in the document
===
Section 19
Should the IANA section also cover the bits in the ADMIN STATUS object?
===
Section 21
Missing references [CRANK], [RFC2205]. Suspect you need to check them all.
Will need to add a reference for LSP segment recovery.
===
Section 21.1
This seems a very long list of normative references. I hope you can split this so that most of the references are informational.
===
Section 22
You might change this to "Editors' Addresses"

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Mar 2005 15:35:34 +0100

hi adrian

thanks for commenting - in-line responses to your question

> Perhaps "is used to provide" ?

-> was meant to say "that means..." - so any better wording ?

>    as well as in [TERM] and [FUNCT]. 

-> ok

> Please either remove this text or mark it so that the RFC editor will remove it.

-> ok

> Although the second paragraph defines "end-to-end protection" I would like to see this pulled out into its own paragraph for emphasis, and also a little more clarity added to the definition. For ex…

-> so you would like to see as part of the introduction a statement 
about end-to-end protection concept - i don't think there is any 
specific issue in adding this

> Hopefully you mean N >= 1  

-> yes

> If there is a reason for this perhaps you could add a note to the text.

-> indeed

>    pre-reserved but explicit action is required to activate (i.e. 

-> ok

>    link and node resources. The recovery resources are pre-reserved but

-> ok

> This sentence comes out of the blue. The whole of the paragraph up to then has not even mentioned extra traffic. 

-> don't understand your comment as it is mentioned at the beginning of 
the paragraph

> I suggest you insert a paragraph break and a sentence explaining how the pre-reserved resources may be used to support an extra-traffic LSP...
> Also, delete "would".

-> ok - this could indeed ease reading

>    the working LSP failure occurs. 

-> indeed as none pre-provisioning actions are performed for the alternate

> Need to add a citation for LSP segment recovery.

-> ok

>    The recovery attributes include all the parameters that determine 

-> ok

>    alternate) LSP when a failure is encountered in the working (or

-> this definition needs to be updated as - by removing primary in the 
second parenthesis - it comes from a initial phase where no solution 
where yet started

> Can we please not modify the interpretation of the S-bit.

-> this is what the draft does as also explained in

"   In this document, the PROTECTION object uses as a basis the
    PROTECTION object defined in [RFC3471] and [RFC3473] and defines
    additional fields within it. The fields defined in [RFC3471] and
    [RFC3473] are unchanged by this memo. "

> Note that the P-bit appears to be slightly orthogonal because the text seems to describe the *current* role of the LSP. (The S-bit in RFC3471 describes the role at the time the LSP is set up, I thi…

-> note this has already been explained to you - where we came to the 
conclusion for clarity to add the above mentioned paragraph

>    When used for signaling the working LSP, the Association ID of the 

-> ok

>    When used for signaling the protecting LSP, this field identifies 

-> ok

> So, what you are saying is that in 1+1 protection the network may *never* know that the error is so bad that the LSP is dead, but MUST leave that choice to the ingress. While this is the operationa…

-> what i mean is that this LSP in a 1+1 mode should not be released 
after failure (which is the common usage of such a scheme)

> Actually, I think you want to say that the quality of 1+1 protection may vary. Allowing link diverse, node diverse or SRLG diverse 1+1 protection.

-> indeed i can phrase this in a more prescriptive way (rather than the 
descriptive currently proposed)

> Why must both LSPs belong to the same session? A one line explanation would start the section off nicely.

-> ok

> What is the implication of "new"? I guess you mean the new type defined in this draft.

-> yes

>                 0x10    1+1 Bi-directional Protection 

-> in 5.1 "This LSP Protection Type value is applicable
    to both uni- and bi-directional LSPs. "

-> in 6.1 "This LSP Protection Type
    value is only applicable to bi-directional LSPs.

> Your description of the use of the P-bit for 1+1 protection isn't clear. You mean to say that the P-bit indicates which LSP the ingress would *prefer* to be the protecting LSP if all other things a…

-> ok instead of stating it is desirable i will provide a more 
deterministic statement

> I don't see this in the IANA section, and I wonder if you also mean Error Value?

-> it corresponds to the entry "Notify Error/LSP Failure" 
(suggested value = 6)" error value is thus appropriate

> I am worried that you are confusing the Ack message with a new procedure requiring a handshake of Notify messages.

-> ok i will rephrase that one

> Note that the sender descriptor or flow descriptor is also present in the Notify and this will considerably help resolve ambiguities and race conditions since it identifies the LSP.

-> ok i will add a statement along these lines

> I don't think the receipt of a Notify message is sufficient, per se. I think the error code and value need to indicate a problem with the LSP.

-> this is explained in the next paragraph, but i will add a statement 
with respect to this error code/value processing

"           Note: in this case, the IF_ID ERROR_SPEC replaces the
            ERROR_SPEC in the Notify message, otherwise the
            corresponding (data plane) information SHOULD be received
            in the PathErr/ResvErr message. "

> You presumably mean "...send a Notify message including the Message_ID object".

-> yes

> While this clarifies the use of Ack rather than Notify Ack (not sure why you need to include "(Notify)") it is now confused about the delivery of the Ack message. How do we achieve reliable deliver…

-> needs to be rephrased as the only to achieve reliable bi-directional 
exchange is by ensuring three way handshake (Notify ->, Notify + Ack <-, 
Ack ->)

> Do you mean that the extra traffic is carried "using this LSP" or "using some or all of the resources assigned to this LSP"?

-> the first "using this LSP"

> I think this is "end-nodes may need to be notified"

-> ok

> In what way may there be more than one affected LSP moved to a single protecting LSP?

-> if someone uses the multiplier field of the SONET/SDH TSPEC, but 
there is a typo in the last LSP (missed a "s")

> - Why do you say "may be done"?

-> "initiated" or "performed"

> - Is this the same error code as in 6.2? (the text is slightly different)

-> i will adapt error value per IANA section - the same for the error 
codes as part of section 6.2

>    provisioned protecting LSP is resource-disjoint from the N 

-> ok

> Can you highlight that the N working LSPs are all between the same pair of end points.

-> ok

>    this does not mean that the corresponding resources can not be used by 

-> ok

> This feels like it should be the Holding Priority. That is, the Setup Priority was only important for how it could displace pre-existing LSPs.

-> ok (it will clarify) - but there was an implicit statement here that 
both are actually equal

>    From [RFC3945], the secondary LSP is setup with resource pre-

-> ok

>    provisioning phase. This requires restoration signaling along the 

-> ok

> Suggest a search for "id"

-> will use "ID"

>    From [RFC3945], the secondary LSP is setup with resource pre-

-> ok

>    activated. An additional condition arises from mis-connection avoidance 

-> ok

>    the following steps before step 1. 

-> ok

> Any chance of settling on something more conventional?

-> ok - will use 1, 2a, 2b, 3, 4

> I would like to make sure that you are not applying "SHOULD NOT" to LSP re-establishment.

-> it means do not apply re-routing as specified in this document, i 
will add a paragraph around these lines

>    allocated to the LSP that was originally routed over them even after a 

-> ok

> This is the first mention of APS

-> see section 7.2 in this section 12 i will use the term "protection 
switching signaling" instead

> - in D and E replace "manual" with "requested"

-> ok

>    Recovery signaling is initiated externally that switches 

-> ok
> I would prefer you to use the meanings rather than the values.

-> ok will add the description

> ? "This is allowed"? "This is possible"? "This is successful"?

-> would you clarify what you mean here

>    as a switchover request for 1+1 bi-directional and 1:1 protection.  

-> ok

> b. Retain the C-Type from RFC3473

-> will add a reference to segment recovery (that does not make use of 
TLVs) - see section 6.1 of SEG-REC

> Can we two statements. One with "MUST" and one with "MUST NOT".

-> ok (but i don't understand why this logical statement is not allowed)

> This seems in contradiction with section 15.3

-> identical in terms of content definition

>    The PPRO enables sharing of recovery resources between a given 

-> ok

> Hmmm. presumably same source and destination is relatively important too.

-> ok i will add a statement here even if it is already part of the next 
sentence

>    The ASSOCIATION object is used to associate LSPs with each other.   

-> i will remove it

> It would be helpful to state who assigns this value.

-> it is the sender (i will add this)

> You need to make this much clearer here.

-> ok i will add a statement along these lines, note this statement will 
be added such that relationship between values is clearer

> And I thought Resv was, but I may have been sleeping.

-> Resv needs to be added (Notify is not modified)

> But I think you need to discuss misconnection here. In particular when there is mesh protection going on.

-> i will include specifics inlight with the text provided in the 
functional specification

> - Be consistend in using TBD or TBA in the document

-> ok (do think put the proposed value as part of the text and the IANA 
section ease reading)

> Should the IANA section also cover the bits in the ADMIN STATUS object?

-> we did not register these bits since if you think we need to register 
them as part of this section just let me know

> Will need to add a reference for LSP segment recovery.

-> ok

> This seems a very long list of normative references. I hope you can split this so that most of the references are informational.

-> ok
> You might change this to "Editors' Addresses"

-> ok

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Mar 2005 17:26:46 -0000

Hi Dimitri,

> -> was meant to say "that means..." - so any better wording ?

OK...
"...to support end-to-end Label Switched Path (LSP) recovery, that is
protection and restoration of end-to-end LSPs."

> > ===
> > Section 3
> > Although the second paragraph defines "end-to-end protection" I would
like to see this pulled out into its own paragraph for emphasis, and also
a little more clarity added to the definition. For example, it would
appear that your four types of e2e protection are all have the protecting
and protected LSPs disjoint in some way - this makes it appear that this
is a property of e2e protection in general and you should state this if it
is true.
> specific issue in adding this

OK. Thanks. I don't need a whole essay; just a short paragraph.

> > This sentence comes out of the blue. The whole of the paragraph up to
then has not even mentioned extra traffic.
> -> don't understand your comment as it is mentioned at the beginning of

OK. It's a long paragraph with a page throw in the middle. I guess I fell
asleep by the time I got to the end of the paragraph!

> second parenthesis - it comes from a initial phase where no solution

OK. So please make sure that this happens during RFC Ed or authors 48
hours on [TERM].

> > If you need to flag a new piece of information (to distinguish between
resource allocated and not) then please introduce a new flag.
> > Note that the P-bit appears to be slightly orthogonal because the text
seems to describe the *current* role of the LSP. (The S-bit in RFC3471
describes the role at the time the LSP is set up, I think).
> conclusion for clarity to add the above mentioned paragraph

Well, then I guess I find RFC3471 poorly drafted.

> > So, what you are saying is that in 1+1 protection the network may
*never* know that the error is so bad that the LSP is dead, but MUST leave
that choice to the ingress. While this is the operational practice in many
transport networks, I don't see why you make this as strong as a SHOULD
NOT.
> after failure (which is the common usage of such a scheme)

Agree about comon usage.
Think SHOULD NOT is too strong.
Would accept RECOMMENDED.

>     value is only applicable to bi-directional LSPs.

Ah!

Very sorry. I wonder if my stupidity is also present in others.
That is (of course), the protection type uni/bi is not the same as the LSP
direction uni/bi.
And that bi protection is meaningless for a uni LSP.

Any hope of a couple of lines to avoid this confusion?

> (suggested value = 6)" error value is thus appropriate

Ah. OK, then just update the text in section 6.2.

> -> "initiated" or "performed"

It is the "may be" that I question. It implies there is a choice of ways
to do it.
Section 6.2 uses "this is done".

> -> would you clarify what you mean here

I am suggesting meaning (and therefore replacement text) for the phrase
"This, unless a fault condition exists"

> TLVs) - see section 6.1 of SEG-REC

Suppose this is OK.
But, notwithstanding the fact that I am an author of SEG-REC, it appears
that the additional info that is defined in SEG-REC would fit within the
existing 64 bit structure. (Appologies for not reviewing that draft
first.)

> > ===
> > Section 15
> > In the case where my protecting LSP protects only one working LSP and
where the full path of the protecting LSP is known by the ingress (strict
and explicit) and there is no resource sharing between the protected and
protecting LSP, I can't see why I must include a PPRO.
> > In other words, PPRO is an enabler of function (as stated in section
15.4 "The PPRO enables of sharing recovery resources between a given
secondary protecting LSP and one or more secondary protecting LSPs if
their corresponding primary working LSPs have mutually
(link/node/SRLG)disjoint paths."), but that does not make its presence
mandatory.

No comment?

> -> identical in terms of content definition

15.3 says
   The following subobjects are currently defined for the PRIMARY PATH
   ROUTE object:
   - Sub-Type 1: IPv4 Address (see [RFC3209])
   - Sub-Type 2: IPv6 Address (see [RFC3209])
   - Sub-Type 3: Label (see [RFC3473])
   - Sub-Type 4: Unnumbered Interface (see [RFC3477])
but RFC3209 defines
    32   Autonomous system number

Hence a contradiction. If you are prepared to accept type 32 in the PPRO I
suggest that you remove the list of accepted values and simply state that
anything that can go in an ERO *or* an RRO is acceptable in a PPRO.

> -> Resv needs to be added (Notify is not modified)

   This section describes the extensions to the PROTECTION object to
   broaden its applicability to end-to-end LSP recovery. In addition to
   modifications to the format of the PROTECTION object, we extend its
   use so that the object can be included in the Notify message to act
   a switchover request for 1+1 bi-directional and 1:1 protection.

Looks like a modification to me.

> -> ok (do think put the proposed value as part of the text and the IANA

Don't feel strongly.
Have seen too many drafts go to RFC with mixed values or TBD still in
place.

> them as part of this section just let me know

Asking your opinion, really.
Question is, what is the risk of losing track of Admin Status bits?
Note, I keep an informal registry on the alternate CCAMP pages.

Thanks for the hard work.
Adrian