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

["Adrian Farrel" <[e-mail]>]

Hi,

it looks to me that there are a few minor tweaks agreed in this email.

Do you want to send me RFC Editor note comments (OLD... NEW...) or spin a new
version?

Thanks,
Adrian

> -----Original Message-----
> From: Yiqun Cai [mailto:[e-mail]]
> Sent: 07 September 2011 01:29
> To: Thomas Heide Clausen
> Cc: [e-mail]; [e-mail];
[e-mail]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt
> 
> 
> 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