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

[Yiqun Cai <[e-mail]>]

Thomas,

Thank you for taking the time to review the document. We too appreciate your
effort.  On the other hand, we do hope that at certain point we can converge
quickly and progress the draft forward.

Our reply is inline.  I removed sections that we obviously are in agreement
to reduce the context and the length of the email.  I also removed
"Executive symmary for ADs" in your previous email.

If you are ok with the proposal, I guess we can submit another rev if
AD/chairs are ok with it.

AD/Chairs,  the most significant request for change is to move it to
"Experimental".  Please advice. Thanks.

Thank you all.

On 8/30/11 12:47 AM, "Thomas Heide Clausen" <[e-mail]>
wrote:

> Dear Yiqun,
> 
> Thank you for your detailed reply to my review. As a reviewer, I appreciate
> when the authors engage  such as you have done, and I am pleased to continue
> in these iterations with you. Do accept my apologies for the delay in getting
> back to you - life had a way of interfering in an unpredictable manner these
> past two weeks, but I should be back now.
> 

> On Aug 9, 2011, at 23:12 , Yiqun Cai wrote:
> 
>> Thomas,
>> 
>> Thank you very much for the review.  Please see comments inline.
>> 
>> 
>> On 6/28/11 9:47 AM, "Thomas Heide Clausen" <[e-mail]> wrote:
>> 
>>> 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.
>> 
>> This was actually described in the 4th paragraph in the "Introduction".
>> 
>> "This document introduces a new type of PIM Join Attribute ...".
>> 
>> As Marshall pointed out in another review comment,  there are potentially
>> quite a few use cases that can benefit from this functionality.  We hoped to
>> capture at least one of them.
> 
> Marshall is quite right, and I think that you do well in capturing one in the
> text. 
> 
> My comment is one of clarity as to what the document provides:  "if PIM was
> able to Š it would beŠ.." and "This capability would  facilitateŠ" etc. reads
> as a problem statement. I would suggest that it would be clearer to the reader
> what this document provides by phrasing it akin to "Using the PIM Join
> Attribute, specified in this document, PIM can Š."  and "This capability
> enablesŠ."
> 
> I remember from my initial read-through of the document that I thought "Well,
> true, if PIM had this capability it would be nice, someone should go specify
> that". As this is the document "specifying that", I suggest affirming what
> this document provides, rather than suggesting what PIM lacks in the
> introduction.
> 

We can try to reword that if we submit another rev.

> 
> 
>>> 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.
>> 
>> We will add a section to clarify that.
> 
> Great, thanks! That will help. I note from the below that you intend to go
> through the document for 2119-terminology tightening, which I appreciate and
> which I think will help the document. Will you add a proper terminology
> section? As a relative newcomer to PIM, I know that such would have helped me
> understand the spec. A suggestion here would also be that this terminology
> section points to relevant RFCs from which terminology is imported (ala: "This
> document furthermore uses the terminology defined in RFCxxxx, RFCyyyy and
> RFCzzzz, specifically the terms foo, bar and foobar"). This, for readability
> purposes.
> 

A new section, "Terminologies", was indeed inserted to rev-09 of the draft.
I think you probably missed that.  The section does describe "RPF", "RPF
Topology", "MT", "PIM MT-ID" and "PIM MT-ID Join Attribute", which we
believe are the most fundamental terminologies in the document.

>>> 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).
>> 
>> Indeed.
>> 
>> However it was done on practical purpose,
>> 
>> 1.  we want to specify a valid range
>> 2.  we also want to specify what an implementation should behave if another
>> implementation includes a value that is outside of that range.
>> 
>> What we learned from our experience is that if we don't specify how to
>> handle error cases, we will consistently run into interop issues that can't
>> be solved easily.
> 
> Quite so, I agree that it is good to specify error cases.
> 
> My issue is, that you state that:
> 
> o  an implementation MUST NOT include a MT-ID Join Attribute with value 0
> o yet, when performing a validity check, join packet with MT-ID=0 is
> considered valid.
> 
> If you really mean "MUST NOT", then you must also consider a packet received
> that violates that "MUST NOT" as to be invalid.
> 
> Otherwise, the specification appears incoherent.
> 

I noticed another place you have the same comment.  We agree "SHOULD NOT" is
more appropriate here.

> 
>>> 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.
>> 
>> Actually,  this is the first attempt to integrate multi-topology routing
>> with multicast.
> 
> OhŠ..this raises a red flag with me, then, even more than before. My worry
> when I read through the document was, that I had no idea if, or how well, it
> would work in an operational setting, so I looked to the references for some
> evidence - be that a whitepaper documenting an operational deployment, or
> academic studies, or the like. Finding nothing of the kind did leave me
> concerned as to if we understood the validity of the proposal, which was why I
> raised this issue in my review.
> 
> You tell me that this is a first attempt at integrating multicast and
> multi-topology routing - and that is, indeed, both interesting and
> commendable. 
> 
> Alas, if you are right in the above (and I have no reason to doubt you), then
> I would suggest that this document is a candidate to be published as
> "Experimental", rather than as "Proposed Standard", until we have studied the
> matter and obtained a better understanding of behavior and performance
> characteristics? 
> 
> Were there any WG discussions regarding Exp-vs-PS that I should go look at?

The WG didn't have any debate on this.

I'm not sure how strong you feel it this way.  I didn't check but I would
guess there has been many "first time" drafts that started out as "proposed
standard". 

We, as co-authors, are fine with moving to Experimental.

AD/Chairs,  do you have any opinion here?


>>> 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.
>>> 
>> 
>> The text was added based on the comment from WG LC.  Some people do like to
>> see how MT-IDs are assigned numerically.
> 
> Alright, then. Would it be possible to simply add a sentence clarifying that
> these numbers are mere examples, without any other significance?

Section 3.1 does indicate the part of the description is an example.  For
example,  "consider the following example described by Figure 1", or "The
above example illustrates ..."

So I guess we are ok here.

> 
>>> 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".
>> 
>> Yes.  The text describes two different cases and provides two different
>> recommendations depending on how the topologies are built.
> 
> RECOMMENDED is a SHOULD - which I read to mean "If you do NOT follow this
> recommendation, you should know that there may be consequences - and these
> consequences are Š.." See below.
> 
>>> 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.
> 
> My issue with this text is that you say "RECOMMENDED" - but that I do not see
> any consequences of following (or not) the recommendation. In other words, the
> 2119-meaning of "RECOMMENDED" appears to be too strong. Maybe writing
> "suggested" (lower-case, non-2119) would suffice?
> 

OK, now we feel like stuck here.  The word "RECOMMENDED" was added from the
last call comments.  If you don't have a strong opinion on it, we would like
to keep it if possible.

> In either case, I would like to understand why you recommend or suggest this.
> Could you add an explanatory sentence/paragraph?

That was explained in the last sentence, "This is for the purpose of
reducing management overhead and simplifying troubleshooting".  There is
really nothing very glorious.

> 
>>> 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?
>>> 
>> 
>> In multicast jargons,  S usually refers to a /32 host address (assuming
>> IPv4).  But the routing table usually contains only a prefix that covers or
>> includes S, instead of S.
> 
> OK, let's ascribe that to me not knowing multicast jargon ;)
> 
> I suggest inserting a rephrasing of this paragraph into the terminology
> section, then?
> 

Seriously speaking, describing what "S" stands for would be hard. It has
been assumed by many, if not all the multicast related RFCs and internet
drafts.  And it is not essential for this draft.  So I would prefer not to
expand on "S", hope you can agree.


>>> 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.
>> 
>> No it is not a new name-space.
>> 
>> This document introduces a new type of Join Attribute which was introduced
>> by RFC5384.
> 
> Then I strongly suggest stating that, almost as you phrased it above, in
> section 3.

Yes.  The terminologies section we added to rev-09 hopefully captures that.

>
> 
>>> 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".
>> 
>> In this document, yes they are the same.
> 
> If they are the same, then I suggest picking one, defining in a terminology
> section - and sticking to that choice through the document. If both terms are
> used in literature, pick the most used term, and have the terminology section
> state "MT-ID - is <blah blah>. In some literature, this is also occasionally
> called PIM MT-ID"
> 

Please see the above.

>> 
>>> 
>>> 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.
>> 
>> In common practice (as with OSPF and IS-IS too),  0 is reserved for
>> "default" topology.  Including 0 will cause unnecessary interop issues that
>> brings no additional gain.  Thus we prevent the inclusion of it.
> 
> This actually links in with the IANA section of this document, which I find
> somewhat hard to read/parse. You mention that you will rework that, so I look
> forward to seeing an updated version.
> 
> Still, does this document create an IANA registry for MT-IDs? Generally, I
> would expect an I-D to state something of the form:
> 
> "IANA is requested to create a registry for Š.. with initial assignments and
> allocation policies according to table 42"
> 
> (which the RFC editor tends to reword to something like "IANA has created a
> registry for Š.")
> 
> This makes it clear if the registry, its policies, etc., are to be found in
> this document, and are therefore completely documented in this document.
> 
> If this document does not create said IANA registry, I would expect the IANA
> section to say something like "IANA is requested to allocate a Š. from the
> XXXX registry, defined in RFCxxxx" - that way I would know where to go look
> for assignments, policies, Š.
> 
> Now, if this document creates an IANA registry for MT-IDs, then setting aside
> 0 as a non-allocatable, non-usable value simply removes a value from that
> space - there's nothing "magic" as such about the number 0. If there is a
> common practice that a specific value such as 0 has a commonly understood
> meaning, and that therefore that value should be avoided, it would actually be
> immensely useful to have that explanation with the IANA registry creation -
> effectively this would be guidance to IANA as to how to assign values from
> that registry.
> 
> If this document doesn't create that IANA registry, then I would expect this
> discussion to be in the document which does?

Thomas,

I think we probably had a misunderstanding here.

We ask the IANA to do two things,

1. make 30 a permanent assignment in the space of "PIM Hello Option".
Option #30 will then refer to PIM MT-ID Hello Option.

2. assign a new value for a new type of PIM Join Attribute.  This value
indicates the Join Attribute is "PIM MT-ID".

Both Hello Option and Join Attribute are existing IANA registries.  So this
draft doesn't request to create a new registry but to assign a new value (or
make one permanent).

The draft does *NOT* ask IANA to create a registry for the MT-ID space.

> 
>>> 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)?
>>> 
>> 
>> Because these packets do not require the receiving router to perform any RPF
>> action.  And when a router doesn't perform RPF action,  MT-ID is not needed.
> 
> Suggest saying that in the document. Is it a SHOULD or a MUST? It sounds a bit
> like a MUST to me?

This is similar to an earlier comment of yours.  We still want to process
the packets so maybe we will stay with "SHOULD NOT"?

> 
>>> 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.
>> 
>> That is exactly why we wanted to include this document how to handle error
>> case.  We can choose to discard, or ignore the attributes but continue with
>> the next update.  The second is more appropriate for PIM because
>> "discarding" would require a rewinding of the operation already done on
>> previous PDUs which is hard to do.
> 
> That's fine, but then it is not "Validating" - a packet with one or more PIM
> MT-ID Join Attributes are all valid.

A PIM Join/Prune packets contain information for many multicast routing
entries (*,G) /(S,G).  And the Join Attributes are per (*,G)/(S,G).  We
don't want a malformed attribute (for example) for one (S,G) to affect the
processing result of (*,G)/(S,G)s in front of it.

This is what implementations are currently doing anyway.  The draft just
makes it more explicit.

> 
> You state that an implementation must validate "There is at most 1 PIM MT-ID
> attribute encoded". Therefore, if I receive a packet with 2, it can't be
> valid. Yet, in the next sentence you say that it's ok if there are more than
> one, just use the last.
> 
> Either it is "at most 1" or it is "there may be more, use the last". It can't
> be both.

Actually, one describes "sending", the other describes "receiving". That was
our intention.

> 
> By the way, you use the terms "encoded" and "included" for PIM MT-ID
> attributes in this bullet, both. Are there any differences? If yes, what are
> they? If no, why different words?
> 

There is no difference.

>>> 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?
>> 
>> The paragraph does attempt to describe how to validate the particular type
>> of Join Attribute that is PIM MT-ID.  It doesn't specify how to validate
>> Join Attributes or the Join message in general.
> 
> Then it is even more confusing. Would "Validating PIM MT-ID Join Attributes in
> a received Join Packet" be a more correct title (we can fuss over if it is too
> long or not, but semantically it seems more correct)?
> 

I actually don't see it that bad.  Maybe just "Validation"?


> 
>> 
>>> o Section 5: Suggest calling out that reserved bits SHOULD be cleared on
>>> transmission and
>>> MUST  be ignored on reception.
>>> 
>> 
>> Yes it s ithere.
>> 
> 
> Sorry, no, I do not find that. Can you point me to where you say that, please?

It wasn't obvious in rev-08.  But we made it explicit in rev-09.

> 
>>> 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.
>>> 
>> 
>> That would be RFC4601.
>> 
>>> o Section 6, IANA considerations.
>>> 
>>> - Suggest that "The IANA" be replaced by simply "IANA"
>>> 
>> 
>> Ok.
>> 
>>> - 2nd paragraph, should it be "IANA has assigned the PIM HELLO Option Type
>>> ...."
>>> 
>> 
>> Not yet but IANA will.
> 
> See comment above. The IANA section contains instructions to what we as
> protocol authors request (kindly) that the good folks at IANA do for us. To
> make their life easier (and the document more readable), suggest rephrasing as
> instructions (as also discussed above with registry creation).
> 

Same.  I felt we might have a disconnect here.  So please let us know if the
above explanation helps.  Thanks.



-- 
Yiqun