Re: [Teas] Comments on draft-ietf-teas-lsp-diversity-02

[Lou Berger <[e-mail]>]

Hi,
    I was asked (off-list) to clarify one of my comments:

On 10/27/2015 9:40 PM, Lou Berger wrote:
> - Section 2.1.1., Section 2. PAS - as this document defines PAS there
> should be some guidance and/or guidelines for their creation and use.
> For example, one may conclude that PAS need to get propagated similar to
> SRLGs - but I'm sure this isn't the current intent.

how about this:
In section 2.1.1:
OLD
             The Path affinity Set (PAS) identifier is a single number
             that represents a summarized SRLG for the reference path
             against which diversity is desired. The PAS identifier is
             defined in this document.
NEW
    The Path affinity Set (PAS) identifier field is a 32-bit value that
is scoped by, i.e.,
    is only meaningful when used in combination with, the Diversity
Identifier
    source address field. There are no restrictions on how a node
selects a PAS
    identifier value.  Section 1.3 defines the PAS term and provides
context
    on how values may be selected.

Also in looking at the draft I see the following additional issues:

- in section 2.1.2
s/IPv4 Diversity Identifier source address /IPv6 Diversity Identifier
source address

- in section 2.2
I find the usage of "respect(s)" a bit vague and not aligned with the
rest of the section or 4874 (which doesn't use the term at all).  Either
there should a formal definition of what it means to "respect an XRO"
(e.g., is it full or partial exclusion required to "respect" an xro?) or
language should be aligned with 4874. My preference would be to replace
the 4 cases where the term is used in conformance related clauses and in
the one error code.  Here are suggested changes to be consistent with
the rest of the section -- not saying I love the "diverse from"
phrasing, just that it's consistent.

OLD
         path calculated for the signaled LSP respects the requested PAS
         exclusion.
NEW
    path calculated for the signaled LSP is diverse from the values
    contained in the PAS identifier and Diversity Identifier
    source address fields

OLD
         respects the requested Exclusion Flags.
NEW
         is diverse from the requested Exclusion Flags.

OLD
         signaled LSP respects the requested PAS exclusion.
NEW
         signaled LSP is diverse from the requested PAS exclusion.

OLD
      -  The processing node SHOULD respect the requested exclusion
         flags to the extent possible.
NEW
      - ???

3 places:
s/"Failed to respect Exclude Route"/"Failed to satisfy Exclude Route"

That's it.

Lou

On 10/27/2015 9:40 PM, Lou Berger wrote:
> Hello,
> 	As part of Shepherding draft-ietf-teas-lsp-diversity I have reviewed
> this document and have some comments/questions.  Most of my
> comments/questions are editorial/minor in nature.
>
> First some general questions:
>
> - You define a number of "Notify Error" subcodes, but only sometimes say
> what the upstream node should do.  I think this needs to be covered in
> all cases. You might find RFC5710 a helpful reference.
>
> - Separate DI type values are defined for V4 and V6. As DI type is
> defined with address family specific subobject, there appears to be no
> technical basis for this.  Am I missing something, i.e., is there any
> reason to have AF specific values rather than just defining 1-3 in an AF
> family agnostic values?
>
> - Assuming you make the previous change you can also combine the
> respective object/field definitions along the lines of what you have in
> section 2.3. This will have better consistency for the objects and the
> document.
>
> I have the following editorial/minor comments:
>
> - ID nits, see
> https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-teas-lsp-diversity-02.txt
> , has 3 warnings that need to be addressed.
>
> Line numbers are from the idnits URL
>
> - Section 2.1.1 and 2.1.2 contain definitions of fields defined in other
> documents.  These should be replaced with simple references to the
> original definition rather than being repeated.  Interestingly, Section
> 2.3 already does this.
>
> - Section 2.1.1, line 443.  Drop the word "border" as it applies to any
> node performing the expansion
>
> - Section 2.1.1.. lines 470/1.  Doesn't the "Note:" apply to all
>
> - Section 2.1.1., Section 2. PAS - as this document defines PAS there
> should be some guidance and/or guidelines for their creation and use.
> For example, one may conclude that PAS need to get propagated similar to
> SRLGs - but I'm sure this isn't the current intent.
>
> Section 2.2. What happens when a processing node encounters and unknown
> DI type?  This should be documented.
>
> Line 703: s/EN/a node/
>
> Lines 716,720.  As this is a procedures section shouldn't conformance
> language be used rather than "shall" and "do not need"?
>
> Line 821: S/PSR/Path_State_Removed flag (PSR) [RFC3473]
>
> Section 2.3.  Are the error subcodes the same for XRO and EXRS
> processing? I suspect not.
>
> I think that's it.  I think it makes sense to resolve these prior to
> last call so that folks can review a version that is slightly more ready
> for publication.
>
> Lou
>
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>
>