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

From: Lou Berger <[email-masked]>
Date: Tue, 27 Oct 2015 21:40:58 -0400

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

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 28 Oct 2015 02:41:01 +0000

Dear Lou- 

Thanks for the comments.

I agree, we will resolve your comments before the LC starts. More later.

Thanks

Regards Š Zafar