[RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt

[Thomas Heide Clausen <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: 			draft-ietf-pim-mtid-08.txt 
Reviewer: 			Thomas Heide Clausen
Review Date: 		2011-06-27
IETF LC End Date:	2011-06-27
Intended Status: 		Proposed Standard

Summary:

	I have some minor concerns about this document that I think should be resolved before publication.

Comments:

	This is the first PIM document I have reviewed, so I went back and read some of the previous 
	RFCs. It may mean that my review is not sufficiently in-depth.

	The document is relatively difficult to read. Specifically the introduction reads more like a 
	problem statement (e.g. "if PIM was able to access .... it would be ...") than it does a specification. 
	I would much prefer to have perhaps a very short motivational subsection to the introduction,
	then introduce that which this document actually introduces (and how). Currently, that is difficult
	to extract.

	I feel that RFC2119 language is not used consistently, and that terminology in general is 
	used somewhat inconsistently. Is "MT-ID" and "PIM MT-ID" the same or different things, for example?
	I would suggest that this is in part due to the absence of the by now traditional "Terminology" section,
	which (in my opinion) has as its primary role to ensure that spec-authors are conscious and consistent
	in their choice of words inside a spec.

	I find that there are some internal inconsistencies in the document, i.e. where it is stating different
	things in different sections (e.g. that one MUST NOT include a MT-ID Join Attribute with value 0 -- 
	yet that when performing a validity check, a Join packet with an MT-ID=0 is still considered valid). 

	One concern that I do have with the document is, that there are no references to any kind of
	previous work (typically, I would expect  this to have been well studied in academia) suggesting
	the usefulness and justifying the validity of the proposed approach. Note: I am not saying that
	the approach isn't useful and valid - I am saying that I do not know, and would feel comforted by
	some supporting references to this effect.

Major Issues:

	o	I have actually not found any single "major issues", however I feel that the document is
		hard to read and that the collection of the "minor issues" below would constitute a single
		"major issue".

Minor Issues:

	o	The RFC2119 language is typically seen in a terminology section; something which
		I feel that this document should have, if for no reason other than to help new readers
		to PIM family of documents. It could be as simple as importing (pointing to) relevant 
		terminology from RFC5496/5384/4601

	o	Also, the RFC2119 paragraph does not reflect the errata ("NOT RECOMMENDED" 
		is missing)

	o	Penultimate paragraph of section 2 "It might further need to perform the function
		of splitting and merging. But the detailed processing is beyond the scope of the 
		document". It would be beneficial with elaboration of under which conditions 
		"splitting and merging" is required, as well as some guidance - for example, in form
		of a pointer to where these conditions are detailed.

	o	Ultimate paragraph of section 2: "the MT-ID Join Attribute may be simply referred to as MT-ID"
		-- suggest "the MT-ID Join Attribute will be referred to as MT-ID
	
	o	This may be a matter of individual style, but I do not like empty section introductions, 
		such as 3. 

	o	3rd paragraph in 3.1, suggest removing "please"

	o	Suggest that the figure in 3.1 be given a proper figure environment and number, and
		that references (especially later in the document) be given to that figure number.

	o	As a relatively newcomer to PIM, examples are appreciated. Alas, the example in 
		section 3.1 actually didn't help my understanding much. Also, that example is
		filled with details, whose importance I am not sure I capture: is the choice of 
		"OSPF 1000" and "OSPF 2000" (etc.) important, or are they simply illustrative.

	o	First paragraph on page 5 states "The above example shows that the naming spaces of 
		MT-ID are not required to be the same between PIM and IGPs". That appears reasonable 
		-- however the last bullet point in section 3.2 on the same page goes on to say that 
		"...the PIM MT-ID is RECOMMENDED to be assigned using the same value as the IGP 
		topology identifier".

		Citing RFC2119:

			3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
			   may exist valid reasons in particular circumstances to ignore a
			   particular item, but the full implications must be understood and
			   carefully weighed before choosing a different course.

		It appears to me that if this RFC2119 meaning is intended, then it would be important
		to (i) explain why and (ii) give guidance as to understand what the implications are of
		not following the recommendation.

	o	Also, the document contains many uses of "must", "may" and "should" in lowercase - I am
		wondering if some (all?) of these should be capitalized to RFC2119 terms. I am trying to
		point out those I catch, but I would recommend that the authors review the document to
		ensure that they capitalize those where they mean RFC2119 terminology.

	o	On the same first paragraph on page 5, when I read " .... shows that ....", then I actually
		expect a bit more rigor - tainted by having spent too much time in academia, perhaps,
		but I read "...shows that ..." to entail (close to) a formal proof. Maybe "....illustrates that..."
		is a better choice of words?

		Same holds for the last bullet point on page 5.

	o	Same paragraph, what exactly is meant by "...the prefix covering S...."? I assume that
		it has something to do with that routing state for S is not maintained by the two routing
		topologies?

	o	Generally to section 3.1, it is somewhat unclear what this specification does, vs. what
		PIM already does, which caused me to chase off reading PIM RFCs.
	
		Reading through the specification, would it be correct to say that:

			-	This I-D introduces a new name-space, the "PIM MT-ID"
			-	A given topology is provisioned with that "PIM MT-ID" by way of a
				"MT-ID PIM Join Attribute", defined by this specification?

		If yes, then I would suggest calling that out explicitly.

	o	Section 3.2, second bullet-point talks about "...a value is not required to be the same as 
		the MT-ID used by the unicast routing protocol ...." However the ultimate paragraph in
		section 2 defines MT-ID to be a "Join Attribute", which is a PIM-entity (RFC5384). Do
		you mean to say that this MT-ID should be used also in an unicast routing protocol, or
		is it a terminology issue?

	o	Page 6, second bullet "This value must be unique and consistent within the network domain...."

			-	must or MUST?
			-	"network domain" is a wonderfully vague term. A quick google leads to the
				first many results relating to either "LAN-style domain controllers" or DNS.
				Suggest that his might be a good candidate term for replacement, or for
				definition in a terminology section.

	o	Section 4.2.1, "...it may chose" - may or MAY? Also, can guideline be given as to when
		a PIM router would chose to, or not, encode the PIM MT-ID? Finally, "PIM MT-ID", is that
		the same as what the ultimate paragraph of section 2 calls "MT-ID".

	o	Section 4.2.1: missing colon before bullet points

	o	Section 4.2.1 first bullet point: why MUST NOT? What are the consequences of
		including a Join Attribute when the MT-ID=0?
		Specifically, in 4.2.3, the ultimate bullet, the validation rules simply state that if
		the value is 0, then the Join Attribute "...is ignored" (there is a SHOULD or MUST 
		needed here?) and that the rest of the message is processed as if that Join
		Attribute was not included.

	o	Section 4.2.1 2nd and 3rd bullet points, why "SHOULD NOT"? Can any guidance
		be provided with respect to the consequences of ignoring such recommendation
		(or, if there are no negative consequences, then the benefits of following them)?

	o	Section 4.2.2 first bullet - prefer section references (if using xml2rfc <xref targe="...."/> tags)
		rather than "next section" or "in section Conflict Resolution". This is a general comment,
		but this seemed like a good point to mention this.

	o	Section 4.2.3, first bullet: as t his is about "Validating a PIM MT-ID Join Attribute", I find it
		curious that it suggests to check that there is at most 1 PIM MT-ID Join Attribute included - 
		then goes on to say that it's OK if there are more, just ignore all but the last. I would suggest
		that either this is a validation check and so if more than 1 PIM MT-ID Join Attribute then
		the packet is malformed and should be discarded - or, that this be specified somewhere
		other than a section specifying how to determine if an attribute is valid or not.

	o	Same section & bullet: the title is "Validating a PIM MT-ID Join Attribute", i.e. validating _a_ single
		such. Yet, the bullet talks about having possibly multiple PIM MT-ID Join Attributes encoded.
		Encoded where? Should this section be retitled "Validating a Join Packet with a PIM MT-ID 
		Join Attribute" instead?

	o	Section 5: Suggest that encoding, byte-order, ..., be called out (NBO, unsigned integer, ....) for
		newly defined fields.

	o	Section 5: Suggest calling out that reserved bits SHOULD be cleared on transmission and 
		MUST  be ignored on reception.

	o	Section 5: Suggest citing the spec defining the format used (RFC5384?), least it appears
		odd to have an 8 bit "Length" field, and yet defining its value to always be 2.

	o	Section 6, IANA considerations.

			-	Suggest that "The IANA" be replaced by simply "IANA"

			-	2nd paragraph, should it be "IANA has assigned the PIM HELLO Option Type ...."

			-	I do not understand what the IANA action for the ultimate paragraph in 6.1 is about?

Respectfully Yours,

Thomas