Re: [Teas] Gen-art LC review of draft-ietf-teas-rsvp-te-srlg-collect-02

["Matt Hartley (mhartley)" <[e-mail]>]

Elwyn,

Thanks for the review, and apologies for the delay in replying. Responses to your concerns inline.

> I am the assigned Gen-ART reviewer for this draft. The General Area 
> Review Team (Gen-ART) reviews all IETF documents being processed by 
> the IESG for the IETF Chair.  Please treat these comments just like 
> any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-teas-rsvp-te-srlg-collect-02.txt
> Reviewer: Elwyn Davies
> Review Date: 2015/09/13
> IETF LC End Date: 2015/09/24
> IESG Telechat date: (if known) -
> 
> Summary:
> Not ready for publication.  The main problem appears to be that the 
> use of SRLG ID RRO sub-objects in Resv messages seems to be an 
> afterthought.  It needs to be covered in the introduction. It is also 
> not clear how nodes are informed that SRLG information needs to be added to Resv messages.

OK. More on this later.

> I
> am also concerned that the ordering constraints imposed on RRO 
> sub-objects by various different standards (at least this one and RFC 
> 7571 - there may be others that I am not aware of) may become overly 
> complex and potentially mutually incompatible.  When I reviewed the 
> draft that subsequently became RFC 7571 earlier this year there were 
> already internal issues with sub-object ordering that had to be sorted 
> out - checking that ordering constraints do not result in a deadly 
> embrace could get quite complicated if more specifications add to the RRO stack.

I take your point... but do you consider this something that has to be addressed by this document? This seems to me to be a more general problem with RSVP-TE that the WG may wish to address separately.

> Major issues:
> What is an SRLG ID?  OK, it is a 4 octet (opaque) data item. However, 
> the specification says nothing about how it might be used to convey 
> the SRLG information.

No, we don't. Do you think that an explanation over and above that provided by RFC 4202 is necessary?

> I *guess* that this may be because this is just a handy facility that 
> can be used in whatever way an implementation chooses - but if so it 
> would good to say this.  Maybe an example of how the authors envisage 
> it might be used, maybe in the context of the use case in s1.1 would 
> be helpful.

We can add an example if you think it'd be helpful, but I'm reluctant to (re)define what SRLGs are or mean in this document.

> s4.1:
> >     The SRLG Collection flag is meaningful on a Path message.  If the
> >     SRLG Collection flag is set to 1, it means that the SRLG information
> >     SHOULD be reported to the ingress and egress node along the setup of
> >     the LSP.
> I am unclear how the Path message is going to impart SRLG information 
> to both ends of the LSP as my understanding of RSVP is that the Path 
> message travels only in one direction along the path of the LSP.  ...
> 
> Ah, when I read down towards the end of s5.1, it appears that the SRLG 
> info may be in Resv messages as well, and might be collected during 
> the processing of the Resv message along the (reverse) path. According 
> to RFC 3209, the presence of an RRO in the Path message will trigger 
> the addition of an RRO to the Resv message, but this does not tell the 
> nodes that SRLG information ought to be added. Presumably the SRLG 
> Collection flag should be set somewhere in a suitable place in the 
> Resv message also.  But where?  The text above says the flag is only 
> meaningful on Path messages!!  Maybe the RRO Attributes sub-object 
> might be relevant [RFC5420].

The idea is that the processing node knows that SRLG information is required for the LSP from its processing of the Path message, and will apply this to the Resv too when it arrives. But, yeah... this is never explicitly stated, and it should be.

> 
> The draft needs to talk about both directions and uni-/bidirectional 
> LSPs from an earlier point in the document.

So perhaps add a short overview of how the collection works at, say, the beginning of s3? I think that would make the document easier to understand at first reading.

> 
> Minor Issues:
> 
> s5: RRO Sub-object ordering constraints.  In s4.2, a number of 
> ordering constraints are specified indicating where the SRLG info 
> objects should be placed in the stack of RRO sub-objects.  Section 5 
> does not discuss what should happen if the receiving node detects that 
> the sub-objects don't match the specified ordering constraints.

Yes, we should address this. Given the principle of "be strict in what you send, and liberal in what you accept", I'll add some text to say that the processing node MAY reject the Path or Resv and generate a PathErr/ResvErr if the ordering is wrong. Sound reasonable?

> A more general issue is
> whether there are interactions with ordering constraints from other 
> specifications that use RRO sub-objects - for example, RFC 7571 has 
> some quite complex ordering constraints.

Yes. But as I said earlier, I think this is an issue that would probably be best addressed separately.

> There is also the following text in
> s5.1:
> >     o  For Path and Resv messages for a bidirectional LSP, a node SHOULD
> >        include SRLG sub-objects in the RRO for both the upstream data
> >        link and the downstream data link from the local node.  In this
> >        case, the node MUST include the information in the same order for
> >        both Path messages and Resv messages.  That is, the SRLG sub-
> >        object for the upstream link is added to the RRO before the SRLG
> >        sub-object for the downstream link.
> It strikes me that using one of the reserved bits in the SRLG 
> sub-object to explicitly identify whether a sub-object applies to the 
> upstream or downstream direction would make things less error prone 
> and reduce the ordering constraint which might get quite complicated 
> as time goes on if new RRO sub-objects continue to be added.

Yes, this seems reasonable.

> Nits/editorial comments:
> General: Just checking: does this specification apply to basic MPLS or 
> only to the extended Generalized MPLS?  It would be good to be clear 
> about the scope up front.

By "basic MPLS", do you mean packet-TE? If so, that's a sub-set of GMPLS, and so this specification applies there too.

> 
> General: Bringing out the IANA temporary allocations at every point 
> where they apply in Sections 4.1, 4.2, 5.1  and 8 is undesirable as it 
> will have to be edited out by the RFC Editor increasing the scope for 
> error.  OK this is not a big risk but it would simplify things if the 
> body text had the expected final form and the temporary allocation 
> text notes were confined to a special section that was marked for 
> removal by the RFC Editor.

OK

> General: s/byte/octet/g
> 
> Abstract: Probably ought to mention (G)MPLS explicitly and expand TE.
> 
> s1, para 1:  It would be good to expand TE explicitly (as Generalized 
> MPLS Traffic Engineering) again.

Looking at the RFC Editor's list at https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt, GMPLS seems to be considered well enough known to not require expansion. TE, apparently, isn't :)

> 
> s3: Using RFC 2119 language here is inappropriate - they are 
> design/usage issues not testable protocol features.

OK - will re-work this

> 
> s4.1, para 1: s/indicate nodes/indicate to nodes/
> 
> s4.1 and s4.2, last para in each case: s/The rules of the/The rules 
> for the/ (2 places)
> 
> s5.1, paras 2 and 3: s/and the SRLG Collection Flag set/with the SRLG 
> Collection Flag set/ (2 places)
> 
> s5.1, last para: Need to expand FA acronym.

OK on these four

> 
> s6.1: It would be useful to repeat the policy configurations mentioned 
> in s5 in this section.

I'm not quite sure which bits of s5 you're getting at here?

> 
> s6.2, para 1: s/SRLG ids/SRLG IDs/  [please check that there aren't 
> any other cases].

Yep.

One other thing (from Deborah) for completeness and so I don't forget it - we need to update the IANA section to reflect the recent update to the temporary allocation.

Cheers

Matt