Subject: Re: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-rsvp-te-srlg-collect-06: (with COMMENT)

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 15 Jun 2016 23:39:16 +0000

Alvaro,

Thanks for the comments!

> My comments are relatively minor but I would like to see them addressed
> before publication.
>
> 1. Section 4.1. (SRLG Collection Flag): "…this document defines a new flag
> in the Attribute Flags TLV…which MAY be carried…"  I think a clearer
> description would be something worded more along the lines of "…which MUST
> be set in…to indicate that SRLG information SHOULD be reported…"

I see what you're getting at, but I don't want to give the impression that an implementation is obliged to request SRLG recording.

How about:

This document defines a new SRLG collection flag in the Attribute Flags TLV (see RFC 5420 [RFC5420]). A node that wishes to indicate that SRLG collection is desired MUST set this flag in an Attribute Flags TLV in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Object to indicate that SRLG information SHOULD be reported.

> It would also be good if in this section the difference between
> LSP_REQUIRED_ATTRIBUTES  and LSP_ATTRIBUTES is also explained.

Given that RFC 5420 (where these are defined) is a normative reference, can we not assume that the reader has read it? If not, would it be better to add this here in 4.1, or in 3.1?

> 2. Section 4.2. (RRO SRLG sub-object): "…The SRLG sub-object SHOULD be
> pushed…before the node IP address…SHOULD be pushed after the Attribute
> sub-object, if present, and after the LABEL sub-object, if requested."
> Knowing that it is a stack, does it really make a difference where the
> SRLG sub-object is pushed?  Put another way, why are you using "SHOULD"
> and not "MUST"?

First one should be a MUST. As for the others... IIRC this was semi-plagiarized from RFC 5420, which also uses SHOULD in a similar context. 

> 3. Section 5.1. (SRLG Collection)  "A node SHOULD NOT add SRLG information
> without an explicit request…"  What happens if a node does?
> Should the "SHOULD NOT" be "MUST NOT"?

From a protocol perspective, it wouldn't break anything; from the point of view of a network operator they could be a little upset if their SRLGs escaped from their own domain when they didn't want that :) I'll change this.

> 
> 4. Section 5.2. (SRLG Update): "If local policy is that the SRLG change
> SHOULD be suppressed…"  s/SHOULD/should   The policy is being described,
> so a normative keyword is not appropriate.

Mirja made the comment that separating policy for adding SRLG information in the first place and reporting changes didn’t make much sense, so as part of merging them I'll simply remove this.

> 
> 5. Section 5.3 (Domain Boundaries)  "If mandated by local policy, a
> node…MAY add a summary of the removed SRLGs or map them to other SRLG
> values."  How is this (summary or mapping) done?  If specified somewhere
> else, please add a reference.

That's up to the policy that mandates it. I'll make that clear.

> 6. Section 6.2. (Coherent SRLG IDs): "…SRLG IDs SHOULD be unique."  Why is
> this not a MUST?

I'm now wondering if using normative language here is the right thing to do at all, given that we're describing the scenarios under which SRLG-collection works.

Cheers

Matt

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 15 Jun 2016 23:54:44 +0000

On 6/15/16, 6:39 PM, "Matt Hartley (mhartley)" <[email-masked]> wrote:

Matt:

Hi!

>> 1. Section 4.1. (SRLG Collection Flag): "Šthis document defines a new
>>flag
>> in the Attribute Flags TLVŠwhich MAY be carriedŠ"  I think a clearer
>> description would be something worded more along the lines of "Šwhich
>>MUST
>> be set inŠto indicate that SRLG information SHOULD be reportedŠ"
>
>I see what you're getting at, but I don't want to give the impression
>that an implementation is obliged to request SRLG recording.
>
>How about:
>
>This document defines a new SRLG collection flag in the Attribute Flags
>TLV (see RFC 5420 [RFC5420]). A node that wishes to indicate that SRLG
>collection is desired MUST set this flag in an Attribute Flags TLV in an
>LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES Object to indicate that SRLG
>information SHOULD be reported.

That looks fine.

>Given that RFC 5420 (where these are defined) is a normative reference,
>can we not assume that the reader has read it? If not, would it be better
>to add this here in 4.1, or in 3.1?

There's some text already in 5.1: "...carried either in an
LSP_REQUIRED_ATTRIBUTES Object when the collection is mandatory, or in an
LSP_ATTRIBUTES Object when the collection is desired, but not mandatory."

Moving/copying something like that towards the front would help.  I would
prefer 4.1 simply because that's where the flag is defined..

>
>> 2. Section 4.2. (RRO SRLG sub-object): "ŠThe SRLG sub-object SHOULD be
>> pushedŠbefore the node IP addressŠSHOULD be pushed after the Attribute
>First one should be a MUST. As for the others... IIRC this was
>semi-plagiarized from RFC 5420, which also uses SHOULD in a similar
>context.

My point was that "MUST" makes it so that the sub-object has to be put in
a specific place...but "SHOULD" doesn't absolutely mandate it.  If
"SHOULD" is used then the ordering doesn't matter, so we should get rid of
the normative language...

Thanks!!

Alvaro.