Subject: [CCAMP] comments to draft-gandhi-ccamp-gmpls-restoration-lsp-01

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 8 Nov 2013 02:22:57 +0000

Hi, All, 

    Due to short of time, I post my questions to this draft here (based on the slides).  

1) what is the scope of this document? From the examples given, it seems to me only to end to end case. If it is not the intention, it would be good to clarify. 

2) Page 3 of the slides, last sentence. 
I do not think it is accurate. A restoration LSP can be established before failure as specified in RFC4872, unless you are targeting fully dynamic rerouting. So i think the following text in the draft need modification:

"Restoration LSP differs from a secondary LSP
   in the way that secondary LSP does not reserve resources in the data
   plane and is not able to carry any traffic until it is refreshed
   whereas restoration LSP does reserve resources and is able to carry
   traffic."

3) Page 8, the note. 
Could you point the exact piece of text saying this in RFC6689? At the moment, i cannot find it, thus cannot judge the need of this draft. 

4) Page 9: 
4.1: It seems to me the draft are using the bit P different from what it is defined in  RFC4872. Since it is a BCP draft, i do not expect this. Please clarify. 

4.2: not sure why assign a restoration LSP for a protection LSP? If the intention is to protection two failures, assign one protection and one restoration LSP for the working LSP is probably a better way to do. Since the failure of protection LSP does not won't trigger any update in RSVP-TE. 

Regards,
Xian

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 15 Nov 2013 00:29:59 +0000

Thanks Xian for your review comments.

Please see inline.. <RG>..

On 2013-11-07 9:22 PM, "Zhangxian (Xian)" <[email-masked]> wrote:

>1) what is the scope of this document? From the examples given, it seems
>to me only to end to end case. If it is not the intention, it would be
>good to clarify. 

<RG> This is for end to end recovery case.

>I do not think it is accurate. A restoration LSP can be established
>before failure as specified in RFC4872, unless you are targeting fully
>dynamic rerouting. So i think the following text in the draft need
>modification:
>

<RG> We are targeting the fully dynamic rerouting case described in RFC
4872 and copied below.

"4) Full LSP rerouting (or restoration) switches normal traffic to an
      alternate LSP that is not even partially established until after
      the working LSP failure occurs.  The new alternate route is
      selected at the LSP head-end node, it may reuse resources of the
      failed LSP at intermediate nodes and may include additional
intermediate nodes and/or links."

>
>3) Page 8, the note.
>Could you point the exact piece of text saying this in RFC6689? At the
>moment, i cannot find it, thus cannot judge the need of this draft.

Slide should have said "Inferred from RFC6689" instead of "RFC6689 states".

RFC 6689 doesn't explicitly cover the case for "full rerouting" case (so
you will not find it and hence need for this clarification draft).

RFC 6689, Section 2.2 has following text which we used to infer that
restoration LSP may carry LSP-ID of itself.

"The Association ID carries one of three values:
      -  The LSP ID of the LSP being protected.
      -  The LSP ID of the protection LSP.
      -  In the case where the matching LSP is not yet known (i.e.,
initiated), the LSP ID value of the LSP itself."

>
>4) Page 9: 
>4.1: It seems to me the draft are using the bit P different from what it
>is defined in  RFC4872. Since it is a BCP draft, i do not expect this.
>Please clarify. 

<RG> There is no change proposed for the existing PROTECTION object (and P
bit) usage in this draft. I think it should be Informational draft and not
BCP.

>
>4.2: not sure why assign a restoration LSP for a protection LSP? If the
>intention is to protection two failures, assign one protection and one
>restoration LSP for the working LSP is probably a better way to do. Since
>the failure of protection LSP does not won't trigger any update in
>RSVP-TE. 

<RG> If protection LSP fails, in full rerouting case, one would signal
restoration for the protection LSP to share/claim resources of the
protection LSP, no?

Thanks,
Rakesh

>
>
>Regards,
>Xian 
>_______________________________________________
>CCAMP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ccamp