Subject: Comments on draft-ietf-ccamp-gmpls-segment-recovery-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 29 Mar 2005 13:35:03 +0100

Hi,

Working group last call has ended for this draft. As a co-author I held off making comments during WG last call, but as WG chair I wanted to raise a couple of points.

Thanks,
Adrian

===
Need to run idnits and fix all errors and warnings
===
Opening boilerplate.
Replace first paragraph with...
   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.
===
Abstract
Expand "LSP"
===
Abstract
OLD
   intended to be compliment and be consistent with the Extensions for
NEW
   intended to compliment and be consistent with the Extensions for
===
Abstract
Don't use square brace citations in the abstract.
===
Section 1
OLD
   The extensions defined in this document allow for support of the full
   set of recovery types supported by [E2E-RECOVERY] on a segment, or
   portion of the LSP, basis. 
NEW
   The extensions defined in this document allow for support of the full
   set of recovery types supported by [E2E-RECOVERY], but applied to any 
   segment, or to any portion of the LSP.
===
Section 2
OLD
   failure, or failure over a particularly portion of a network used by
NEW
   failure, or failure over a particular portion of a network used by
                                        ^ 
===
Section 2.1
OLD
   Three approaches of end-to-end protection are defined in [E2E-
NEW
   Three approaches for end-to-end protection are defined in [E2E-
===
Section 2.1
OLD
   counterparts.  Each behaves just like there end-to-end counterparts,
NEW
   counterparts.  Each behaves just like its end-to-end counterpart,
                                         ^^^                       ^
===
Section 2.1 and section 2.2
Cross-references are all (presumably) to [E2E-RECOVERY]. This is not clear.
===
Section 3
OLD
   [E2E-RECOVERY].  In this document we define a new type to support
NEW
   [E2E-RECOVERY].  In this document we define a new value for the Association Type field to support
===
Section 4
OLD
   When upstream control of branch and merge nodes are not desired,
NEW
   When upstream control of branch and merge nodes is not desired,
===
Section 4.1.1
The definition of the Type value for the Protection sub-object should not be here. It should be in the IANA section and under IANA control.
===
Section 4.1.1
Need to include a definition of the Length field. This can point to RFC3209.
===
Section 4.1.1
Need to state the rules for the Reserved bits.
===
Section 4.2.4.2
   Once the ingress receives all expected Resv messages MUST follow the
   tear down procedure described in the Section 4.2.4.
Assume this means 4.2.4.1?
===
Section 5.1
   The protection subobject defined in [E2E-RECOVERY] can also be used
   in SECONDARY_RECORD_ROUTE objects.
No. It is defined in section 4.1.1 of this document.
===
Section 6.1
OLD
   LSP Segment Recovery Flags are carried in the Protection object C-
   Type defined in [E2E-RECOVERY].  The format of the flags are:
NEW
   LSP Segment Recovery Flags are carried in the Protection object of the same C-
   Type defined in [E2E-RECOVERY].  The format of the flags are:
===
Section 6.1
***
Same question as for E2E-RECOVERY. Why do we need to use a new C-Type (compared with the old definition of the Protection object)?
It is possible to carry all of the additional information within the old Protection object format.
***
===
Section 6.1
      (LSP) Segment (Recovery) Flags: 6 bits
Not _entirely_ clear which fields in the figure are referred to by this text.
===
Section 8
Is it true that there are _no_ additional security considerations?
Suppose that I am able to doctor a Path message by adding an SERO. This would cause the data to be duplicated to my chosen destination without impacting the real destination (i.e. without raising an alarm).
Doesn't segment protection actually improve the security of the network by making data delivery more robust?
===
Section 9 first para.
It is not clear what action (if any) IANA is expected to take for this information. If action is required, it would be helpful to point to the relevant text within the draft.
===
Section 9 second para.
There are some TBAs embedded in the text (section 4, section 5) that relate to this paragraph). Need either to include "IANA" with the TBA, or put a back pointer in this paragraph (or both).
===
Section 10
Obsoleted by section 14
===
Section 11.1
Does [FRR] need to be a normative reference?

---

From: Lou Berger <[email-masked]>
Date: Wed, 30 Mar 2005 18:29:57 -0500

Adrian,
         Thanks for the comments.  The editorial comments will be 
integrated into the next rev.  Will cover the 1 technical comment (on 
section 6.1) in a separate e-mail.

Lou

At 07:35 AM 3/29/2005, Adrian Farrel wrote:
>Hi,
>
>Working group last call has ended for this draft. As a co-author I held 
>off making comments during WG last call, but as WG chair I wanted to raise 
>a couple of points.
>
>Thanks,
>Adrian
>
>===
>The definition of the Type value for the Protection sub-object should not 
>be here. It should be in the IANA section and under IANA control.
>===
>Section 4.1.1
>Same question as for E2E-RECOVERY. Why do we need to use a new C-Type 
>(compared with the old definition of the Protection object)?
>Suppose that I am able to doctor a Path message by adding an SERO. This 
>would cause the data to be duplicated to my chosen destination without 
>impacting the real destination (i.e. without raising an alarm).
>It is not clear what action (if any) IANA is expected to take for this 
>information. If action is required, it would be helpful to point to the 
>relevant text within the draft.
>===
>Section 9 second para.
>There are some TBAs embedded in the text (section 4, section 5) that 
>relate to this paragraph). Need either to include "IANA" with the TBA, or 
>put a back pointer in this paragraph (or both).
>===
>Section 10
>Obsoleted by section 14
>===
>Section 11.1