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

[Lou Berger <lberger@movaz.com>]

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
>
> ===
> 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?