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

["Adrian Farrel" <adrian@olddog.co.uk>]

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?