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

[Yiqun Cai <[e-mail]>]

Thomas,

Do you have any further comments regarding this?  Please let us know so that
we can move the process forward.

Thanks.


On 9/6/11 5:29 PM, "Yiqun Cai" <[e-mail]> wrote:

> 
> 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