From ycai@cisco.com Tue Sep 6 17:26:24 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2B021F8B47 for ; Tue, 6 Sep 2011 17:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvJukFpOVpQx for ; Tue, 6 Sep 2011 17:26:22 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 922F921F8AFD for ; Tue, 6 Sep 2011 17:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=23354; q=dns/txt; s=iport; t=1315355290; x=1316564890; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=3RXSusByQLWbAbYdknPQGijl76kE3ZjQ6rx1kBn2nBo=; b=IDglFFdWWAKUov/i/jTEAYfmruuTDcTgYRmaaGy23hb6ilGEzUQ5xCyp 84RKdBYTBbA9XkjQ37R+xuIhezwgf7kJWX6DQLqt1YR3X8LIAO7Fq7CEE zdsmC7eh01REhhmVwZOK2n4azgeAfQS9il+zoAVReTR5fQNqpcmoxyHol g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYIAFm5Zk6rRDoJ/2dsb2JhbABDpxF2AniBRgEBAQECARIBByIBLwoDBQ0BCBQEgQUBAQQOBQkQCYdRBJk8AZ9RhmoEhzwvi0OFGIdshCk X-IronPort-AV: E=Sophos;i="4.68,342,1312156800"; d="scan'208";a="550376" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Sep 2011 00:28:10 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p870SAtv015216; Wed, 7 Sep 2011 00:28:10 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 17:28:10 -0700 Received: from 128.107.161.214 ([128.107.161.214]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Wed, 7 Sep 2011 00:28:09 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 06 Sep 2011 17:29:07 -0700 From: Yiqun Cai To: Thomas Heide Clausen Message-ID: Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt Thread-Index: Acxs9SdbiXDE3hgGQk+duqi7ffVmPA== In-Reply-To: <5948F513-A5C8-4474-A693-AE48DC38845C@thomasclausen.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 07 Sep 2011 00:28:10.0010 (UTC) FILETIME=[05638FA0:01CC6CF5] X-Mailman-Approved-At: Tue, 06 Sep 2011 20:12:36 -0700 Cc: rtg-dir@ietf.org, draft-ietf-pim-mtid.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 00:26:24 -0000 Thomas, Thank you for taking the time to review the document. We too appreciate you= r effort. On the other hand, we do hope that at certain point we can converg= e 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" wrote: > Dear Yiqun, >=20 > Thank you for your detailed reply to my review. As a reviewer, I apprecia= te > when the authors engage such as you have done, and I am pleased to conti= nue > in these iterations with you. Do accept my apologies for the delay in get= ting > back to you - life had a way of interfering in an unpredictable manner th= ese > past two weeks, but I should be back now. >=20 > On Aug 9, 2011, at 23:12 , Yiqun Cai wrote: >=20 >> Thomas, >>=20 >> Thank you very much for the review. Please see comments inline. >>=20 >>=20 >> On 6/28/11 9:47 AM, "Thomas Heide Clausen" wr= ote: >>=20 >>> Hello, >>>=20 >>> I have been selected as the Routing Directorate reviewer for this draft= . The >>> Routing Directorate seeks to review all routing or routing-related draf= ts as >>> they pass through IETF last call and IESG review, and sometimes on spec= ial >>> request. The purpose of the review is to provide assistance to the Rout= ing >>> ADs. For more information about the Routing Directorate, please see >>> http://www.ietf.org/iesg/directorate/routing.html >>>=20 >>> Although these comments are primarily for the use of the Routing ADs, i= t >>> would >>> be helpful if you could consider them along with any other IETF Last Ca= ll >>> comments that you receive, and strive to resolve them through discussio= n or >>> by >>> updating the draft. >>>=20 >>> 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 >>>=20 >>> Summary: >>>=20 >>> I have some minor concerns about this document that I think should be >>> resolved >>> before publication. >>>=20 >>> Comments: >>>=20 >>> 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. >>>=20 >>> The document is relatively difficult to read. Specifically the introduc= tion >>> 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 subsectio= n to >>> the introduction, >>> then introduce that which this document actually introduces (and how). >>> Currently, that is difficult >>> to extract. >>=20 >> This was actually described in the 4th paragraph in the "Introduction". >>=20 >> "This document introduces a new type of PIM Join Attribute ...". >>=20 >> As Marshall pointed out in another review comment, there are potentiall= y >> quite a few use cases that can benefit from this functionality. We hope= d to >> capture at least one of them. >=20 > Marshall is quite right, and I think that you do well in capturing one in= the > text.=20 >=20 > My comment is one of clarity as to what the document provides: "if PIM w= as > able to =8A it would be=8A.." and "This capability would facilitate=8A" etc. r= eads > as a problem statement. I would suggest that it would be clearer to the r= eader > what this document provides by phrasing it akin to "Using the PIM Join > Attribute, specified in this document, PIM can =8A." and "This capability > enables=8A." >=20 > I remember from my initial read-through of the document that I thought "W= ell, > true, if PIM had this capability it would be nice, someone should go spec= ify > that". As this is the document "specifying that", I suggest affirming wha= t > this document provides, rather than suggesting what PIM lacks in the > introduction. >=20 We can try to reword that if we submit another rev. >=20 >=20 >>> I feel that RFC2119 language is not used consistently, and that termino= logy >>> in >>> general is=20 >>> 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-autho= rs >>> are >>> conscious and consistent >>> in their choice of words inside a spec. >>=20 >> We will add a section to clarify that. >=20 > Great, thanks! That will help. I note from the below that you intend to g= o > 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 helpe= d me > understand the spec. A suggestion here would also be that this terminolog= y > 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 readabil= ity > purposes. >=20 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 Jo= in >>> Attribute with value 0 -- >>> yet that when performing a validity check, a Join packet with an MT-ID=3D= 0 is >>> still considered valid). >>=20 >> Indeed. >>=20 >> However it was done on practical purpose, >>=20 >> 1. we want to specify a valid range >> 2. we also want to specify what an implementation should behave if anot= her >> implementation includes a value that is outside of that range. >>=20 >> 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 ca= n't >> be solved easily. >=20 > Quite so, I agree that it is good to specify error cases. >=20 > My issue is, that you state that: >=20 > 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=3D0 is > considered valid. >=20 > If you really mean "MUST NOT", then you must also consider a packet recei= ved > that violates that "MUST NOT" as to be invalid. >=20 > Otherwise, the specification appears incoherent. >=20 I noticed another place you have the same comment. We agree "SHOULD NOT" i= s more appropriate here. >=20 >>> 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 studie= d in >>> academia) suggesting >>> the usefulness and justifying the validity of the proposed approach. No= te: I >>> am not saying that >>> the approach isn't useful and valid - I am saying that I do not know, a= nd >>> would feel comforted by >>> some supporting references to this effect. >>=20 >> Actually, this is the first attempt to integrate multi-topology routing >> with multicast. >=20 > Oh=8A..this raises a red flag with me, then, even more than before. My worr= y > 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 s= ome > 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. >=20 > You tell me that this is a first attempt at integrating multicast and > multi-topology routing - and that is, indeed, both interesting and > commendable.=20 >=20 > 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?=20 >=20 > Were there any WG discussions regarding Exp-vs-PS that I should go look a= t? 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".=20 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=20 >>> section 3.1 actually didn't help my understanding much. Also, that exam= ple >>> is >>> filled with details, whose importance I am not sure I capture: is the c= hoice >>> of=20 >>> "OSPF 1000" and "OSPF 2000" (etc.) important, or are they simply >>> illustrative. >>>=20 >>=20 >> The text was added based on the comment from WG LC. Some people do like= to >> see how MT-IDs are assigned numerically. >=20 > Alright, then. Would it be possible to simply add a sentence clarifying t= hat > 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. >=20 >>> o First paragraph on page 5 states "The above example shows that the na= ming >>> spaces of=20 >>> MT-ID are not required to be the same between PIM and IGPs". That appea= rs >>> reasonable=20 >>> -- however the last bullet point in section 3.2 on the same page goes o= n to >>> say that=20 >>> "...the PIM MT-ID is RECOMMENDED to be assigned using the same value as= the >>> IGP=20 >>> topology identifier". >>=20 >> Yes. The text describes two different cases and provides two different >> recommendations depending on how the topologies are built. >=20 > 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 thes= e > consequences are =8A.." See below. >=20 >>> Citing RFC2119: >>>=20 >>> 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. >>>=20 >>> It appears to me that if this RFC2119 meaning is intended, then it woul= d be >>> important >>> to (i) explain why and (ii) give guidance as to understand what the >>> implications are of >>> not following the recommendation. >=20 > 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? >=20 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 lik= e to keep it if possible. > In either case, I would like to understand why you recommend or suggest t= his. > 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. >=20 >>> Same holds for the last bullet point on page 5. >>>=20 >>> 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? >>>=20 >>=20 >> 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. >=20 > OK, let's ascribe that to me not knowing multicast jargon ;) >=20 > I suggest inserting a rephrasing of this paragraph into the terminology > section, then? >=20 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 specificat= ion >>> does, vs. what >>> PIM already does, which caused me to chase off reading PIM RFCs. >>>=20 >>> Reading through the specification, would it be correct to say that: >>>=20 >>> - 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? >>>=20 >>> If yes, then I would suggest calling that out explicitly. >>=20 >> No it is not a new name-space. >>=20 >> This document introduces a new type of Join Attribute which was introduc= ed >> by RFC5384. >=20 > 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. > >=20 >>> 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, "PI= M >>> MT-ID", is that >>> the same as what the ultimate paragraph of section 2 calls "MT-ID". >>=20 >> In this document, yes they are the same. >=20 > If they are the same, then I suggest picking one, defining in a terminolo= gy > 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 sec= tion > state "MT-ID - is . In some literature, this is also occasiona= lly > called PIM MT-ID" >=20 Please see the above. >>=20 >>>=20 >>> o Section 4.2.1: missing colon before bullet points >>>=20 >>> o Section 4.2.1 first bullet point: why MUST NOT? What are the conseque= nces >>> of >>> including a Join Attribute when the MT-ID=3D0? >>> Specifically, in 4.2.3, the ultimate bullet, the validation rules simpl= y >>> state >>> that if >>> the value is 0, then the Join Attribute "...is ignored" (there is a SHO= ULD >>> or >>> MUST=20 >>> needed here?) and that the rest of the message is processed as if that = Join >>> Attribute was not included. >>=20 >> In common practice (as with OSPF and IS-IS too), 0 is reserved for >> "default" topology. Including 0 will cause unnecessary interop issues t= hat >> brings no additional gain. Thus we prevent the inclusion of it. >=20 > This actually links in with the IANA section of this document, which I fi= nd > somewhat hard to read/parse. You mention that you will rework that, so I = look > forward to seeing an updated version. >=20 > Still, does this document create an IANA registry for MT-IDs? Generally, = I > would expect an I-D to state something of the form: >=20 > "IANA is requested to create a registry for =8A.. with initial assignments = and > allocation policies according to table 42" >=20 > (which the RFC editor tends to reword to something like "IANA has created= a > registry for =8A.") >=20 > 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. >=20 > If this document does not create said IANA registry, I would expect the I= ANA > section to say something like "IANA is requested to allocate a =8A. from th= e > XXXX registry, defined in RFCxxxx" - that way I would know where to go lo= ok > for assignments, policies, =8A. >=20 > Now, if this document creates an IANA registry for MT-IDs, then setting a= side > 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 actual= ly 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 fro= m > that registry. >=20 > If this document doesn't create that IANA registry, then I would expect t= his > 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 (o= r make one permanent). The draft does *NOT* ask IANA to create a registry for the MT-ID space. >=20 >>> 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 recommend= ation >>> (or, if there are no negative consequences, then the benefits of follow= ing >>> them)? >>>=20 >>=20 >> 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 nee= ded. >=20 > 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"? >=20 >>> o Section 4.2.3, first bullet: as t his is about "Validating a PIM MT-I= D >>> Join >>> Attribute", I find it >>> curious that it suggests to check that there is at most 1 PIM MT-ID Joi= n >>> 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 spec= ified >>> somewhere >>> other than a section specifying how to determine if an attribute is val= id or >>> not. >>=20 >> That is exactly why we wanted to include this document how to handle err= or >> case. We can choose to discard, or ignore the attributes but continue w= ith >> 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. >=20 > 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. >=20 > 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 t= han > one, just use the last. >=20 > Either it is "at most 1" or it is "there may be more, use the last". It c= an't > be both. Actually, one describes "sending", the other describes "receiving". That wa= s our intention. >=20 > 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? >=20 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 Jo= in >>> Attributes encoded. >>> Encoded where? Should this section be retitled "Validating a Join Packe= t >>> with >>> a PIM MT-ID=20 >>> Join Attribute" instead? >>=20 >> The paragraph does attempt to describe how to validate the particular ty= pe >> of Join Attribute that is PIM MT-ID. It doesn't specify how to validate >> Join Attributes or the Join message in general. >=20 > Then it is even more confusing. Would "Validating PIM MT-ID Join Attribut= es in > a received Join Packet" be a more correct title (we can fuss over if it i= s too > long or not, but semantically it seems more correct)? >=20 I actually don't see it that bad. Maybe just "Validation"? >=20 >>=20 >>> o Section 5: Suggest calling out that reserved bits SHOULD be cleared o= n >>> transmission and >>> MUST be ignored on reception. >>>=20 >>=20 >> Yes it s ithere. >>=20 >=20 > Sorry, no, I do not find that. Can you point me to where you say that, pl= ease? It wasn't obvious in rev-08. But we made it explicit in rev-09. >=20 >>> 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 alwa= ys be >>> 2. >>>=20 >>=20 >> That would be RFC4601. >>=20 >>> o Section 6, IANA considerations. >>>=20 >>> - Suggest that "The IANA" be replaced by simply "IANA" >>>=20 >>=20 >> Ok. >>=20 >>> - 2nd paragraph, should it be "IANA has assigned the PIM HELLO Option T= ype >>> ...." >>>=20 >>=20 >> Not yet but IANA will. >=20 > 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 rephrasi= ng as > instructions (as also discussed above with registry creation). >=20 Same. I felt we might have a disconnect here. So please let us know if th= e above explanation helps. Thanks. --=20 Yiqun From ycai@cisco.com Mon Sep 19 17:32:47 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992AC21F8ADC for ; Mon, 19 Sep 2011 17:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.2 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhpEQJNhGvFI for ; Mon, 19 Sep 2011 17:32:46 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 00D2221F84C9 for ; Mon, 19 Sep 2011 17:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=24570; q=dns/txt; s=iport; t=1316478910; x=1317688510; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=N3KnjWYxKHZifedV2NbSEX+kaMxK6dAKlnfYyPTNCts=; b=CBmSK4GtwqsUkWS7N4tPMTGLORdCy7nkvWG2CXcr49tTKOx45Jm43Czv 0BGCD9D91XjZFGlSwKKoBwrhgThRtVLxUileyG0QnM36fgbV/qvhRiKG0 pXUoerqaoIKbQXigdVOdHiI1ZNCPQYktkNT83IeFx2I/8BRsuC9tpKqm3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAGAJ3fd06rRDoJ/2dsb2JhbABCpllnAneBUwEBAQECARIBByIBLwoDBQ0BCBQEgQUBAQQOBQkQCYdVBJdcAZ47hngEhz8wi1qFJod6hC0 X-IronPort-AV: E=Sophos;i="4.68,408,1312156800"; d="scan'208";a="3082635" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Sep 2011 00:34:55 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8K0Yted023027; Tue, 20 Sep 2011 00:34:55 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 17:34:54 -0700 Received: from 128.107.161.214 ([128.107.161.214]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Sep 2011 00:34:54 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 19 Sep 2011 17:34:58 -0700 From: Yiqun Cai To: Thomas Heide Clausen Message-ID: Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt Thread-Index: Acxs9SdbiXDE3hgGQk+duqi7ffVmPAKN/iX+ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Sep 2011 00:34:54.0814 (UTC) FILETIME=[1E0A7FE0:01CC772D] X-Mailman-Approved-At: Tue, 20 Sep 2011 04:28:16 -0700 Cc: rtg-dir@ietf.org, draft-ietf-pim-mtid.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 00:32:47 -0000 Thomas, Do you have any further comments regarding this? Please let us know so tha= t we can move the process forward. Thanks. On 9/6/11 5:29 PM, "Yiqun Cai" wrote: >=20 > Thomas, >=20 > Thank you for taking the time to review the document. We too appreciate y= our > effort. On the other hand, we do hope that at certain point we can conve= rge > quickly and progress the draft forward. >=20 > Our reply is inline. I removed sections that we obviously are in agreeme= nt to > reduce the context and the length of the email. I also removed "Executiv= e > symmary for ADs" in your previous email. >=20 > If you are ok with the proposal, I guess we can submit another rev if > AD/chairs are ok with it. >=20 > AD/Chairs, the most significant request for change is to move it to > "Experimental". Please advice. Thanks. >=20 > Thank you all. >=20 > On 8/30/11 12:47 AM, "Thomas Heide Clausen" wr= ote: >=20 >> Dear Yiqun, >>=20 >> Thank you for your detailed reply to my review. As a reviewer, I appreci= ate >> when the authors engage such as you have done, and I am pleased to cont= inue >> in these iterations with you. Do accept my apologies for the delay in ge= tting >> back to you - life had a way of interfering in an unpredictable manner t= hese >> past two weeks, but I should be back now. >>=20 >=20 >> On Aug 9, 2011, at 23:12 , Yiqun Cai wrote: >>=20 >>> Thomas, >>>=20 >>> Thank you very much for the review. Please see comments inline. >>>=20 >>>=20 >>> On 6/28/11 9:47 AM, "Thomas Heide Clausen" w= rote: >>>=20 >>>> Hello, >>>>=20 >>>> I have been selected as the Routing Directorate reviewer for this draf= t. >>>> The >>>> Routing Directorate seeks to review all routing or routing-related dra= fts >>>> as >>>> they pass through IETF last call and IESG review, and sometimes on spe= cial >>>> request. The purpose of the review is to provide assistance to the Rou= ting >>>> ADs. For more information about the Routing Directorate, please see >>>> http://www.ietf.org/iesg/directorate/routing.html >>>>=20 >>>> 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 C= all >>>> comments that you receive, and strive to resolve them through discussi= on or >>>> by >>>> updating the draft. >>>>=20 >>>> 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 >>>>=20 >>>> Summary: >>>>=20 >>>> I have some minor concerns about this document that I think should be >>>> resolved >>>> before publication. >>>>=20 >>>> Comments: >>>>=20 >>>> This is the first PIM document I have reviewed, so I went back and rea= d >>>> some >>>> of the previous >>>> RFCs. It may mean that my review is not sufficiently in-depth. >>>>=20 >>>> The document is relatively difficult to read. Specifically the introdu= ction >>>> 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 subsecti= on to >>>> the introduction, >>>> then introduce that which this document actually introduces (and how). >>>> Currently, that is difficult >>>> to extract. >>>=20 >>> This was actually described in the 4th paragraph in the "Introduction". >>>=20 >>> "This document introduces a new type of PIM Join Attribute ...". >>>=20 >>> As Marshall pointed out in another review comment, there are potential= ly >>> quite a few use cases that can benefit from this functionality. We hop= ed to >>> capture at least one of them. >>=20 >> Marshall is quite right, and I think that you do well in capturing one i= n the >> text.=20 >>=20 >> My comment is one of clarity as to what the document provides: "if PIM = was >> able to =8A it would be=8A.." and "This capability would facilitate=8A" etc. = reads >> as a problem statement. I would suggest that it would be clearer to the >> reader=20 >> what this document provides by phrasing it akin to "Using the PIM Join >> Attribute, specified in this document, PIM can =8A." and "This capability >> enables=8A." >>=20 >> 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 spe= cify >> that". As this is the document "specifying that", I suggest affirming wh= at >> this document provides, rather than suggesting what PIM lacks in the >> introduction. >>=20 >=20 > We can try to reword that if we submit another rev. >=20 >>=20 >>=20 >>>> I feel that RFC2119 language is not used consistently, and that termin= ology >>>> in >>>> general is=20 >>>> 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-auth= ors >>>> are >>>> conscious and consistent >>>> in their choice of words inside a spec. >>>=20 >>> We will add a section to clarify that. >>=20 >> 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 help= ed me >> understand the spec. A suggestion here would also be that this terminolo= gy >> section points to relevant RFCs from which terminology is imported (ala: >> "This=20 >> document furthermore uses the terminology defined in RFCxxxx, RFCyyyy an= d >> RFCzzzz, specifically the terms foo, bar and foobar"). This, for readabi= lity >> purposes. >>=20 >=20 > A new section, "Terminologies", was indeed inserted to rev-09 of the draf= t. 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 bel= ieve > are the most fundamental terminologies in the document. >=20 >>>> 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 J= oin >>>> Attribute with value 0 -- >>>> yet that when performing a validity check, a Join packet with an MT-ID= =3D0 is >>>> still considered valid). >>>=20 >>> Indeed. >>>=20 >>> However it was done on practical purpose, >>>=20 >>> 1. we want to specify a valid range >>> 2. we also want to specify what an implementation should behave if ano= ther >>> implementation includes a value that is outside of that range. >>>=20 >>> 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 c= an't >>> be solved easily. >>=20 >> Quite so, I agree that it is good to specify error cases. >>=20 >> My issue is, that you state that: >>=20 >> 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=3D0 is >> considered valid. >>=20 >> If you really mean "MUST NOT", then you must also consider a packet rece= ived >> that violates that "MUST NOT" as to be invalid. >>=20 >> Otherwise, the specification appears incoherent. >>=20 >=20 > I noticed another place you have the same comment. We agree "SHOULD NOT"= is > more appropriate here. >=20 >>=20 >>>> 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 studi= ed in >>>> academia) suggesting >>>> the usefulness and justifying the validity of the proposed approach. N= ote: >>>> 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. >>>=20 >>> Actually, this is the first attempt to integrate multi-topology routin= g >>> with multicast. >>=20 >> Oh=8A..this raises a red flag with me, then, even more than before. My wor= ry >> 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, o= r >> 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=20 >> raised this issue in my review. >>=20 >> You tell me that this is a first attempt at integrating multicast and >> multi-topology routing - and that is, indeed, both interesting and >> commendable.=20 >>=20 >> 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 studie= d the >> matter and obtained a better understanding of behavior and performance >> characteristics? >>=20 >> Were there any WG discussions regarding Exp-vs-PS that I should go look = at? >=20 > The WG didn't have any debate on this. >=20 > 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 "propos= ed > standard".=20 >=20 > We, as co-authors, are fine with moving to Experimental. >=20 > AD/Chairs, do you have any opinion here? >=20 >=20 >>>> o As a relatively newcomer to PIM, examples are appreciated. Alas, the >>>> example >>>> in=20 >>>> section 3.1 actually didn't help my understanding much. Also, that exa= mple >>>> is >>>> filled with details, whose importance I am not sure I capture: is the >>>> choice >>>> of=20 >>>> "OSPF 1000" and "OSPF 2000" (etc.) important, or are they simply >>>> illustrative. >>>>=20 >>>=20 >>> The text was added based on the comment from WG LC. Some people do lik= e to >>> see how MT-IDs are assigned numerically. >>=20 >> Alright, then. Would it be possible to simply add a sentence clarifying = that >> these numbers are mere examples, without any other significance? >=20 > 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 ..." >=20 > So I guess we are ok here. >=20 >>=20 >>>> o First paragraph on page 5 states "The above example shows that the n= aming >>>> spaces of=20 >>>> MT-ID are not required to be the same between PIM and IGPs". That appe= ars >>>> reasonable=20 >>>> -- however the last bullet point in section 3.2 on the same page goes = on to >>>> say that=20 >>>> "...the PIM MT-ID is RECOMMENDED to be assigned using the same value a= s the >>>> IGP=20 >>>> topology identifier". >>>=20 >>> Yes. The text describes two different cases and provides two different >>> recommendations depending on how the topologies are built. >>=20 >> RECOMMENDED is a SHOULD - which I read to mean "If you do NOT follow thi= s >> recommendation, you should know that there may be consequences - and the= se >> consequences are =8A.." See below. >>=20 >>>> Citing RFC2119: >>>>=20 >>>> 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. >>>>=20 >>>> It appears to me that if this RFC2119 meaning is intended, then it wou= ld be >>>> important >>>> to (i) explain why and (ii) give guidance as to understand what the >>>> implications are of >>>> not following the recommendation. >>=20 >> My issue with this text is that you say "RECOMMENDED" - but that I do no= t see >> any consequences of following (or not) the recommendation. In other word= s, >> the=20 >> 2119-meaning of "RECOMMENDED" appears to be too strong. Maybe writing >> "suggested" (lower-case, non-2119) would suffice? >>=20 >=20 > OK, now we feel like stuck here. The word "RECOMMENDED" was added from t= he > last call comments. If you don't have a strong opinion on it, we would l= ike > to keep it if possible. >=20 >> In either case, I would like to understand why you recommend or suggest = this. >> Could you add an explanatory sentence/paragraph? >=20 > That was explained in the last sentence, "This is for the purpose of redu= cing > management overhead and simplifying troubleshooting". There is really no= thing > very glorious. >=20 >>=20 >>>> Same holds for the last bullet point on page 5. >>>>=20 >>>> 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? >>>>=20 >>>=20 >>> In multicast jargons, S usually refers to a /32 host address (assuming >>> IPv4). But the routing table usually contains only a prefix that cover= s or >>> includes S, instead of S. >>=20 >> OK, let's ascribe that to me not knowing multicast jargon ;) >>=20 >> I suggest inserting a rephrasing of this paragraph into the terminology >> section, then? >>=20 >=20 > 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 draft= s. > And it is not essential for this draft. So I would prefer not to expand = on > "S", hope you can agree. >=20 >=20 >>>> o Generally to section 3.1, it is somewhat unclear what this specifica= tion >>>> does, vs. what >>>> PIM already does, which caused me to chase off reading PIM RFCs. >>>>=20 >>>> Reading through the specification, would it be correct to say that: >>>>=20 >>>> - 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? >>>>=20 >>>> If yes, then I would suggest calling that out explicitly. >>>=20 >>> No it is not a new name-space. >>>=20 >>> This document introduces a new type of Join Attribute which was introdu= ced >>> by RFC5384. >>=20 >> Then I strongly suggest stating that, almost as you phrased it above, in >> section 3. >=20 > Yes. The terminologies section we added to rev-09 hopefully captures tha= t. >=20 >>=20 >>=20 >>>> o Section 4.2.1, "...it may chose" - may or MAY? Also, can guideline b= e >>>> given >>>> as to when >>>> a PIM router would chose to, or not, encode the PIM MT-ID? Finally, "P= IM >>>> MT-ID", is that >>>> the same as what the ultimate paragraph of section 2 calls "MT-ID". >>>=20 >>> In this document, yes they are the same. >>=20 >> If they are the same, then I suggest picking one, defining in a terminol= ogy >> section - and sticking to that choice through the document. If both term= s are >> used in literature, pick the most used term, and have the terminology se= ction >> state "MT-ID - is . In some literature, this is also occasion= ally >> called PIM MT-ID" >>=20 >=20 > Please see the above. >=20 >>>=20 >>>>=20 >>>> o Section 4.2.1: missing colon before bullet points >>>>=20 >>>> o Section 4.2.1 first bullet point: why MUST NOT? What are the consequ= ences >>>> of >>>> including a Join Attribute when the MT-ID=3D0? >>>> Specifically, in 4.2.3, the ultimate bullet, the validation rules simp= ly >>>> state >>>> that if >>>> the value is 0, then the Join Attribute "...is ignored" (there is a SH= OULD >>>> or >>>> MUST=20 >>>> needed here?) and that the rest of the message is processed as if that= Join >>>> Attribute was not included. >>>=20 >>> 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. >>=20 >> This actually links in with the IANA section of this document, which I f= ind >> somewhat hard to read/parse. You mention that you will rework that, so I= look >> forward to seeing an updated version. >>=20 >> Still, does this document create an IANA registry for MT-IDs? Generally,= I >> would expect an I-D to state something of the form: >>=20 >> "IANA is requested to create a registry for =8A.. with initial assignments= and >> allocation policies according to table 42" >>=20 >> (which the RFC editor tends to reword to something like "IANA has create= d a >> registry for =8A.") >>=20 >> 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. >>=20 >> 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 =8A. from t= he >> XXXX registry, defined in RFCxxxx" - that way I would know where to go l= ook >> for assignments, policies, =8A. >>=20 >> 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 tha= t >> 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 understoo= d >> meaning, and that therefore that value should be avoided, it would actua= lly >> be=20 >> immensely useful to have that explanation with the IANA registry creatio= n - >> effectively this would be guidance to IANA as to how to assign values fr= om >> that registry. >>=20 >> If this document doesn't create that IANA registry, then I would expect = this >> discussion to be in the document which does? >=20 > Thomas, >=20 > I think we probably had a misunderstanding here. >=20 > We ask the IANA to do two things, >=20 > 1. make 30 a permanent assignment in the space of "PIM Hello Option". Op= tion > #30 will then refer to PIM MT-ID Hello Option. >=20 > 2. assign a new value for a new type of PIM Join Attribute. This value > indicates the Join Attribute is "PIM MT-ID". >=20 > Both Hello Option and Join Attribute are existing IANA registries. So th= is > draft doesn't request to create a new registry but to assign a new value = (or > make one permanent). >=20 > The draft does *NOT* ask IANA to create a registry for the MT-ID space. >=20 >>=20 >>>> 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 follo= wing >>>> them)? >>>>=20 >>>=20 >>> Because these packets do not require the receiving router to perform an= y RPF >>> action. And when a router doesn't perform RPF action, MT-ID is not ne= eded. >>=20 >> Suggest saying that in the document. Is it a SHOULD or a MUST? It sounds= a >> bit=20 >> like a MUST to me? >=20 > This is similar to an earlier comment of yours. We still want to process= the > packets so maybe we will stay with "SHOULD NOT"? >=20 >>=20 >>>> 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 Jo= in >>>> Attribute included - >>>> then goes on to say that it's OK if there are more, just ignore all bu= t 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 va= lid >>>> or >>>> not. >>>=20 >>> That is exactly why we wanted to include this document how to handle er= ror >>> 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. >>=20 >> That's fine, but then it is not "Validating" - a packet with one or more= PIM >> MT-ID Join Attributes are all valid. >=20 > 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 d= on'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. >=20 > This is what implementations are currently doing anyway. The draft just = makes > it more explicit. >=20 >>=20 >> You state that an implementation must validate "There is at most 1 PIM M= T-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. >>=20 >> Either it is "at most 1" or it is "there may be more, use the last". It = can't >> be both. >=20 > Actually, one describes "sending", the other describes "receiving". That = was > our intention. >=20 >>=20 >> 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? >>=20 >=20 > There is no difference. >=20 >>>> 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 J= oin >>>> Attributes encoded. >>>> Encoded where? Should this section be retitled "Validating a Join Pack= et >>>> with >>>> a PIM MT-ID=20 >>>> Join Attribute" instead? >>>=20 >>> The paragraph does attempt to describe how to validate the particular t= ype >>> of Join Attribute that is PIM MT-ID. It doesn't specify how to validat= e >>> Join Attributes or the Join message in general. >>=20 >> Then it is even more confusing. Would "Validating PIM MT-ID Join Attribu= tes >> in=20 >> a received Join Packet" be a more correct title (we can fuss over if it = is >> too=20 >> long or not, but semantically it seems more correct)? >>=20 >=20 > I actually don't see it that bad. Maybe just "Validation"? >=20 >=20 >>=20 >>>=20 >>>> o Section 5: Suggest calling out that reserved bits SHOULD be cleared = on >>>> transmission and >>>> MUST be ignored on reception. >>>>=20 >>>=20 >>> Yes it s ithere. >>>=20 >>=20 >> Sorry, no, I do not find that. Can you point me to where you say that, >> please? >=20 > It wasn't obvious in rev-08. But we made it explicit in rev-09. >=20 >>=20 >>>> 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 alw= ays >>>> be >>>> 2. >>>>=20 >>>=20 >>> That would be RFC4601. >>>=20 >>>> o Section 6, IANA considerations. >>>>=20 >>>> - Suggest that "The IANA" be replaced by simply "IANA" >>>>=20 >>>=20 >>> Ok. >>>=20 >>>> - 2nd paragraph, should it be "IANA has assigned the PIM HELLO Option = Type >>>> ...." >>>>=20 >>>=20 >>> Not yet but IANA will. >>=20 >> 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 rephras= ing >> as=20 >> instructions (as also discussed above with registry creation). >>=20 >=20 > Same. I felt we might have a disconnect here. So please let us know if = the > above explanation helps. Thanks. >=20 >=20 --=20 Yiqun From adrian@olddog.co.uk Sun Sep 25 23:59:55 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F51D21F88B6 for ; Sun, 25 Sep 2011 23:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqaAXvaPtb6g for ; Sun, 25 Sep 2011 23:59:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA5C21F888A for ; Sun, 25 Sep 2011 23:59:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8Q72ZUj006946 for ; Mon, 26 Sep 2011 08:02:35 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8Q72WGY006934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 26 Sep 2011 08:02:34 +0100 From: "Adrian Farrel" To: Date: Mon, 26 Sep 2011 08:02:30 +0100 Message-ID: <06d301cc7c1a$436f3fe0$ca4dbfa0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acx8Gj8matKvr4SYRQiSLRoVsM+VrQ== Content-Language: en-gb Subject: [RTG-DIR] NomCom feedback X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 06:59:55 -0000 Please consider giving feedback on some or all NomCom candidates at https://www.ietf.org/group/nomcom/2011/input/ Thanks, Adrian From matthew.bocci@alcatel-lucent.com Mon Sep 26 06:37:39 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CAC21F8520 for ; Mon, 26 Sep 2011 06:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tYgi6WWvnQp for ; Mon, 26 Sep 2011 06:37:38 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 976DB21F84AB for ; Mon, 26 Sep 2011 06:37:37 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8QDV52w023756 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Sep 2011 15:40:13 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.35]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 26 Sep 2011 15:39:16 +0200 From: "Bocci, Matthew (Matthew)" To: "rtg-ads@tools.ietf.org" Date: Mon, 26 Sep 2011 15:39:12 +0200 Thread-Topic: RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt Thread-Index: Acx8Ua88i+7TmgifRFGxwO8RYSPZNg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CAA63F1018C6Ematthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 13:37:39 -0000 --_000_CAA63F1018C6Ematthewboccialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t 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 wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-kompella-l2vpn-l2vpn-07.txt Reviewer: Matthew Bocci Review Date: 26-09-11 IETF LC End Date: 26-09-11 Intended Status: Informational Summary: I have some major concerns about this document, and some minor concerns tha= t I think should be resolved before the document is published. Comments: Major Issues: - Relationship to published and on-going work in the L2VPN and PWE3 working= groups. This draft describes an alternative to the procedures for signalli= ng PW labels used in pt-pt layer 2 VPNs (VPWS) and for auto-discovery of en= dpoints participating in a L2VPN. The existing IETF-approved technologies u= se LDP for the signalling (as described in RFC4447) and a combination of th= at with BGP for auto-discovery (RFC6074). Since this draft describes an alt= ernative that was rejected by the L2VPN WG, I would suggest adding a discla= imer to the abstract and introduction, as per the recommendation of RFC5742= , along the lines of "The IETF technology for this function is specified in= RFC6074 and RFC4447", in addition to the suggestions on the list that impl= ementations of this draft must also comply to these RFCs. - Section 9: IANA Considerations. This section requests a registry be creat= ed with standards action code points. I believe this is not appropriate as = this is an informational draft. There has already been some discussion on t= his point on the list, and that is noted as a part of this review. - Section 5: Layer 2 VPN interworking. This section introduces a layer 2 tr= ansport service for IP packet. However, just encapsulating IP packets betwe= en PEs will not be sufficient for a layer 2 VPN service between the CEs. Yo= u also need to support something to allow L2 address resolution between the= CEs, for example translation of the neighbour discover protocols (e.g. ARP= over Ethernet and InvARP over FR). Since this is describing the L2VPN, and= not just the PW encapsulation, I think this section should either say how = this is done with BGP (draft-ietf-l2vpn-arp-mediation uses LDP) or just say= it is out of scope of this particular draft and the L2 address is statical= ly configured. Minor Issues: General: - The draft mainly discussed pt-pt L2VPNs. The general term for this is VPW= S, but this term is not mentioned anywhere. It would help to clarify with a= statement in the introduction that this the subject of the draft. - It would help if the figures showing the TLV structures showed the detail= ed structure, throughout, including bit fields, etc, in line with common pr= actice in IETF RFCs. - 1. Introduction, 5th paragraph: "Technically, the approach proposed here uses the concepts and solution and described in [RFC4761], which describes VPLS, a particular form of a Layer 2 VPN." This reads as if RFC4761 is *the* description of VPLS. This is not the case= and the IETF has standardised two VPLS methods. I propose modifying this t= o "=85which describes a method for VPLS,=85". - 1.1 Terminology. Final paragraph. "These will be referred to as Attachment Circuits (ACs), following [RFC4447]. Similarly, the entity that connects two attachment circuits across the Service Provider network is called a pseudo-wire (PW)." RFC3985 is probably the correct reference. Also: s/pseudo-wire/pseudowire - 1.2.5: PE Scaling This section spends a lot of time discussing the scaling issues of L3 VPNs.= I am not sure why this is required in a BGP L2VPN draft, unless the issue = is that because the control plane is the same, many of the same scaling con= siderations apply. Please can you clarify if this is true, and if so make s= uch a note in the text? - 1.3: Advantages of Layer 3 VPNs I do not think this adds any value to a draft on L2 VPNs. The content may b= e useful elsewhere, but I think it would be better if this was removed from= this draft. - 3: Operation of Layer 2 VPNs "In what follows, Frame Relay serves as the Layer 2 medium, and each CE has multiple DLCIs to its PE, each to connect to another CE in the VPN. If the Layer 2 medium were ATM, then each CE would have multiple VPI/VCIs to connect to other CEs. " I think I know what you mean by "medium" I.e. The underlying link layer, wh= ere each group of DLCIs is an AC in the RFC3985 sense, plus DLCI acts as a = demarkation of a L2VPN service between the PE and CE. If so, I think it wou= ld help to add this clarification. - 6.3: IP-Only Layer 2 Interworking: +----------------------------+ | Tunnel | VPN | IP | VPN label is the | Encap | Label | Packet | demultiplexing field +----------------------------+ Figure 3: Format of IP-only Layer 2 interworking packet I think the field marked "Tunnel Encap" should instead be labelled "PSN Tra= nsport Header" or "MPLS Transport Header", in common with the other encapsu= lation RFCs that you have referenced. Best regards Matthew --_000_CAA63F1018C6Ematthewboccialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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. The purpose of the review is to provide as= sistance to the Routing ADs. For more information about the Routing Directo= rate, 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 th= at you receive, and strive to resolve them through discussion or by updatin= g the draft.
=
Document: draft-kompella-l2vpn-l2vpn-07.txt 
Reviewer: Matthew Bocci 
Review Date: 26-09-11 
IETF LC End Da= te: 26-09-11 
Intended Status: Informa= tional

Summary:

I have some major concerns about this document, and some minor concerns= that I think should be resolved before the document is published. 


Comments:

=
Major Issues:
- Relationship to published and o= n-going work in the L2VPN and PWE3 working groups. This draft describes an = alternative to the procedures for signalling PW labels used in pt-pt layer = 2 VPNs (VPWS) and for auto-discovery of endpoints participating in a L2VPN.= The existing IETF-approved technologies use LDP for the signalling (as des= cribed in RFC4447) and a combination of that with BGP for auto-discovery (R= FC6074). Since this draft describes an alternative that was rejected by the= L2VPN WG, I would suggest adding a disclaimer to the abstract and introduc= tion, as per the recommendation of RFC5742, along the lines of "The IE= TF technology for this function is specified in RFC6074 and RFC4447", = in addition to the suggestions on the list that implementations of this dra= ft must also comply to these RFCs.  
<= br>
- Section 9: IANA Considerations. This = section requests a registry be created with standards action code points. I= believe this is not appropriate as this is an informational draft. There h= as already been some discussion on this point on the list, and that is note= d as a part of this review.

- Section 5: Layer 2 VPN interworking. This section i= ntroduces a layer 2 transport service for IP packet. However, just encapsul= ating IP packets between PEs will not be sufficient for a layer 2 VPN servi= ce between the CEs. You also need to support something to allow L2 address = resolution between the CEs, for example translation of the neighbour discov= er protocols (e.g. ARP over Ethernet and InvARP over FR). Since this is des= cribing the L2VPN, and not just the PW encapsulation, I think this section = should either say how this is done with BGP (draft-ietf-l2vpn-arp-mediation= uses LDP) or just say it is out of scope of this particular draft and the = L2 address is statically configured.



Minor Issues:

General:
- The draft mainly discussed pt-pt L2VPNs. The general term for this is= VPWS, but this term is not mentioned anywhere. It would help to clarify wi= th a statement in the introduction that this the subject of the draft.

- It would= help if the figures showing the TLV structures showed the detailed structu= re, throughout, including bit fields, etc, in line with common practice in = IETF RFCs.


- 1. Introduction, 5th paragraph:
&qu= ot;Technically, the approach proposed here uses the concepts and
   solution and described in [RFC4761], whi= ch describes VPLS, a
   particula= r form of a Layer 2 VPN."

<= /div>
This reads as if RFC4761 is *the* description of V= PLS. This is not the case and the IETF has standardised two VPLS methods. I= propose modifying this to "=85which describes a method for VPLS,=85&q= uot;.

= - 1.1 Terminology. Final paragraph.
  =  "These will be referred to as Attachment
   Circuits (ACs), following [RFC4447].  Similarly= , the entity that
   connects two= attachment circuits across the Service Provider network
   is called a pseudo-wire (PW)."
=

RFC3985 is probabl= y the correct reference.
Also: =
 s/pseudo-wire/pseudowire

- 1.2.5: PE Scaling
This section spends a lot of time discussing th= e scaling issues of L3 VPNs. I am not sure why this is required in a BGP L2= VPN draft, unless the issue is that because the control plane is the same, = many of the same scaling considerations apply. Please can you clarify if th= is is true, and if so make such a note in the text?

- 1.3: Advantages of Layer 3= VPNs
I do not think this adds any value to= a draft on L2 VPNs. The content may be useful elsewhere, but I think it wo= uld be better if this was removed from this draft. 

- 3: Operation of Layer = 2 VPNs
"In what follows, Frame Relay s= erves as the Layer 2 medium, and each
 = ;  CE has multiple DLCIs to its PE, each to connect to another CE in t= he
   VPN.  If the Layer 2 m= edium were ATM, then each CE would have
&nb= sp;  multiple VPI/VCIs to connect to other CEs. "

I think I know what y= ou mean by "medium" I.e. The underlying link layer, where each gr= oup of DLCIs is an AC in the RFC3985 sense, plus DLCI acts as a demarkation= of a L2VPN service between the PE and CE. If so, I think it would help to = add this clarification.

- 6.3: IP-Only Layer 2 Interworking:

       = ;  +----------------------------+
         | Tunnel |  VPN  |   &= nbsp;IP     |     VPN label is the
         | Encap  | Label |  = ;Packet   |     demultiplexing field
         +--------------------------= --+


I think the field marked "Tunnel Encap" should instea= d be labelled "PSN Transport Header" or "MPLS Transport Head= er", in common with the other encapsulation RFCs that you have referen= ced.

<= br>
Best regards

Matthew

--_000_CAA63F1018C6Ematthewboccialcatellucentcom_-- From adrian@olddog.co.uk Mon Sep 26 12:18:20 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE381F0C62 for ; Mon, 26 Sep 2011 12:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-bFeWDow98m for ; Mon, 26 Sep 2011 12:18:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDD31F0C60 for ; Mon, 26 Sep 2011 12:18:17 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8QJKs90001461; Mon, 26 Sep 2011 20:20:55 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8QJKrCF001455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Sep 2011 20:20:53 +0100 From: "Adrian Farrel" To: "'Yiqun Cai'" , "'Thomas Heide Clausen'" References: <5948F513-A5C8-4474-A693-AE48DC38845C@thomasclausen.org> In-Reply-To: Date: Mon, 26 Sep 2011 20:20:51 +0100 Message-ID: <07d501cc7c81$68240c00$386c2400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG7kfU9K2zc53msBrm4yN2t8tWN25WB3h+g Content-Language: en-gb Cc: rtg-dir@ietf.org, draft-ietf-pim-mtid.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 19:18:20 -0000 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:ycai@cisco.com] > Sent: 07 September 2011 01:29 > To: Thomas Heide Clausen > Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; draft-ietf-pim-mtid.all@tools.ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt >=20 >=20 > Thomas, >=20 > 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. >=20 > 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. >=20 > If you are ok with the proposal, I guess we can submit another rev if > AD/chairs are ok with it. >=20 > AD/Chairs, the most significant request for change is to move it to > "Experimental". Please advice. Thanks. >=20 > Thank you all. >=20 > On 8/30/11 12:47 AM, "Thomas Heide Clausen" > wrote: >=20 > > 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. > > >=20 > > 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" = > 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 =A9 it would be=A9.." and "This capability would = facilitate=A9" 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 =A9." and "This = capability > > enables=A9." > > > > 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. > > >=20 > We can try to reword that if we submit another rev. >=20 > > > > > >>> 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. > > >=20 > 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. >=20 > >>> 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=3D0 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=3D0 = 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. > > >=20 > I noticed another place you have the same comment. We agree "SHOULD = NOT" > is > more appropriate here. >=20 > > > >>> 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=A9..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? >=20 > The WG didn't have any debate on this. >=20 > 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". >=20 > We, as co-authors, are fine with moving to Experimental. >=20 > AD/Chairs, do you have any opinion here? >=20 >=20 > >>> 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? >=20 > 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 ..." >=20 > So I guess we are ok here. >=20 > > > >>> 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 =A9.." 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? > > >=20 > 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. >=20 > > In either case, I would like to understand why you recommend or = suggest this. > > Could you add an explanatory sentence/paragraph? >=20 > 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. >=20 > > > >>> 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? > > >=20 > 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. >=20 >=20 > >>> 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. >=20 > Yes. The terminologies section we added to rev-09 hopefully captures = that. >=20 > > > > > >>> 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 . In some literature, this is also = occasionally > > called PIM MT-ID" > > >=20 > Please see the above. >=20 > >> > >>> > >>> 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=3D0? > >>> 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 =A9.. 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 =A9.") > > > > 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 =A9. = from the > > XXXX registry, defined in RFCxxxx" - that way I would know where to = go look > > for assignments, policies, =A9. > > > > 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? >=20 > Thomas, >=20 > I think we probably had a misunderstanding here. >=20 > We ask the IANA to do two things, >=20 > 1. make 30 a permanent assignment in the space of "PIM Hello Option". > Option #30 will then refer to PIM MT-ID Hello Option. >=20 > 2. assign a new value for a new type of PIM Join Attribute. This = value > indicates the Join Attribute is "PIM MT-ID". >=20 > 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). >=20 > The draft does *NOT* ask IANA to create a registry for the MT-ID = space. >=20 > > > >>> 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? >=20 > This is similar to an earlier comment of yours. We still want to = process > the packets so maybe we will stay with "SHOULD NOT"? >=20 > > > >>> 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. >=20 > 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. >=20 > This is what implementations are currently doing anyway. The draft = just > makes it more explicit. >=20 > > > > 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. >=20 > Actually, one describes "sending", the other describes "receiving". = That was > our intention. >=20 > > > > 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? > > >=20 > There is no difference. >=20 > >>> 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)? > > >=20 > I actually don't see it that bad. Maybe just "Validation"? >=20 >=20 > > > >> > >>> 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? >=20 > It wasn't obvious in rev-08. But we made it explicit in rev-09. >=20 > > > >>> 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). > > >=20 > Same. I felt we might have a disconnect here. So please let us know = if the > above explanation helps. Thanks. >=20 >=20 >=20 > -- > Yiqun From ycai@cisco.com Mon Sep 26 13:54:21 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0247811E810F for ; Mon, 26 Sep 2011 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PODlmrpzon-f for ; Mon, 26 Sep 2011 13:54:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4B47711E810E for ; Mon, 26 Sep 2011 13:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=25864; q=dns/txt; s=iport; t=1317070623; x=1318280223; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=/T162zWDHK1vyJMgjPjH/JxGeslAkLswsG3M1RS7MMM=; b=j7qKnndmmbUXkyYJpnJcRavn3W20MVphDq3VDkCxiwJaYTktlav9tTcb wdzxv9Fxa2sTnIC5u5I4bqR4xbx9Z2Sy7puj3G3flbELUc1MQz0I4m1Jj oLYtoA0XG4+ZaimoTVSxQdM7NIZ1N10Ip0lFg7lopaFWOzDCToG59bcBQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwHAHnmgE6rRDoG/2dsb2JhbABCpn9tAniBUwEBAQECARIBByIBLwoDBQcGAQgRAwEBAQEnTQkIAgQBDQUJEAmHVgacMgGeNIcLBIdyi2CFK4d8hCw X-IronPort-AV: E=Sophos;i="4.68,446,1312156800"; d="scan'208";a="4413100" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 26 Sep 2011 20:56:40 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8QKudNE027135; Mon, 26 Sep 2011 20:56:39 GMT Received: from xmb-sjc-216.amer.cisco.com ([171.70.151.184]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 13:56:39 -0700 Received: from 128.107.161.214 ([128.107.161.214]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Sep 2011 20:56:39 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 26 Sep 2011 13:56:36 -0700 From: Yiqun Cai To: Adrian Farrel , "'Thomas Heide Clausen'" Message-ID: Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt Thread-Index: AQG7kfU9K2zc53msBrm4yN2t8tWN25WB3h+ggAAbhZ0= In-Reply-To: <07d501cc7c81$68240c00$386c2400$@olddog.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 26 Sep 2011 20:56:39.0680 (UTC) FILETIME=[C99FE000:01CC7C8E] X-Mailman-Approved-At: Mon, 26 Sep 2011 14:01:33 -0700 Cc: rtg-dir@ietf.org, draft-ietf-pim-mtid.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 20:54:21 -0000 Adrian, I was about to send you a note ;) We will spin a new version with the agreed change then (which is really minor). And since we haven't reached a final agreement on the "status", we will kee= p it as "Proposed Standard". I will do that within a couple of weeks. Thanks. On 9/26/11 12:20 PM, "Adrian Farrel" wrote: > Hi, >=20 > it looks to me that there are a few minor tweaks agreed in this email. >=20 > Do you want to send me RFC Editor note comments (OLD... NEW...) or spin a= new > version? >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Yiqun Cai [mailto:ycai@cisco.com] >> Sent: 07 September 2011 01:29 >> To: Thomas Heide Clausen >> Cc: rtg-ads@tools.ietf.org; rtg-dir@ietf.org; > draft-ietf-pim-mtid.all@tools.ietf.org >> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pim-mtid-08.txt >>=20 >>=20 >> Thomas, >>=20 >> 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 conv= erge >> quickly and progress the draft forward. >>=20 >> Our reply is inline. I removed sections that we obviously are in agreem= ent >> to reduce the context and the length of the email. I also removed >> "Executive symmary for ADs" in your previous email. >>=20 >> If you are ok with the proposal, I guess we can submit another rev if >> AD/chairs are ok with it. >>=20 >> AD/Chairs, the most significant request for change is to move it to >> "Experimental". Please advice. Thanks. >>=20 >> Thank you all. >>=20 >> On 8/30/11 12:47 AM, "Thomas Heide Clausen" >> wrote: >>=20 >>> Dear Yiqun, >>>=20 >>> Thank you for your detailed reply to my review. As a reviewer, I apprec= iate >>> when the authors engage such as you have done, and I am pleased to con= tinue >>> 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. >>>=20 >>=20 >>> On Aug 9, 2011, at 23:12 , Yiqun Cai wrote: >>>=20 >>>> Thomas, >>>>=20 >>>> Thank you very much for the review. Please see comments inline. >>>>=20 >>>>=20 >>>> On 6/28/11 9:47 AM, "Thomas Heide Clausen" >> wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> I have been selected as the Routing Directorate reviewer for this dra= ft. > The >>>>> Routing Directorate seeks to review all routing or routing-related dr= afts > as >>>>> they pass through IETF last call and IESG review, and sometimes on sp= ecial >>>>> request. The purpose of the review is to provide assistance to the Ro= uting >>>>> ADs. For more information about the Routing Directorate, please see >>>>> http://www.ietf.org/iesg/directorate/routing.html >>>>>=20 >>>>> 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 discuss= ion > or >>>>> by >>>>> updating the draft. >>>>>=20 >>>>> 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 >>>>>=20 >>>>> Summary: >>>>>=20 >>>>> I have some minor concerns about this document that I think should be >>>>> resolved >>>>> before publication. >>>>>=20 >>>>> Comments: >>>>>=20 >>>>> This is the first PIM document I have reviewed, so I went back and re= ad >> some >>>>> of the previous >>>>> RFCs. It may mean that my review is not sufficiently in-depth. >>>>>=20 >>>>> 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 subsect= ion > to >>>>> the introduction, >>>>> then introduce that which this document actually introduces (and how)= . >>>>> Currently, that is difficult >>>>> to extract. >>>>=20 >>>> This was actually described in the 4th paragraph in the "Introduction"= . >>>>=20 >>>> "This document introduces a new type of PIM Join Attribute ...". >>>>=20 >>>> As Marshall pointed out in another review comment, there are potentia= lly >>>> quite a few use cases that can benefit from this functionality. We ho= ped > to >>>> capture at least one of them. >>>=20 >>> Marshall is quite right, and I think that you do well in capturing one = in > the >>> text. >>>=20 >>> My comment is one of clarity as to what the document provides: "if PIM= was >>> able to =A9 it would be=A9.." and "This capability would facilitate=A9" 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 =A9." and "This capabilit= y >>> enables=A9." >>>=20 >>> 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 sp= ecify >>> that". As this is the document "specifying that", I suggest affirming w= hat >>> this document provides, rather than suggesting what PIM lacks in the >>> introduction. >>>=20 >>=20 >> We can try to reword that if we submit another rev. >>=20 >>>=20 >>>=20 >>>>> 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-aut= hors >>>>> are >>>>> conscious and consistent >>>>> in their choice of words inside a spec. >>>>=20 >>>> We will add a section to clarify that. >>>=20 >>> Great, thanks! That will help. I note from the below that you intend to= go >>> through the document for 2119-terminology tightening, which I appreciat= e 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 hel= ped >> me >>> understand the spec. A suggestion here would also be that this terminol= ogy >>> section points to relevant RFCs from which terminology is imported (ala= : > "This >>> document furthermore uses the terminology defined in RFCxxxx, RFCyyyy a= nd >>> RFCzzzz, specifically the terms foo, bar and foobar"). This, for readab= ility >>> purposes. >>>=20 >>=20 >> A new section, "Terminologies", was indeed inserted to rev-09 of the dra= ft. >> 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. >>=20 >>>>> 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-I= D=3D0 > is >>>>> still considered valid). >>>>=20 >>>> Indeed. >>>>=20 >>>> However it was done on practical purpose, >>>>=20 >>>> 1. we want to specify a valid range >>>> 2. we also want to specify what an implementation should behave if an= other >>>> implementation includes a value that is outside of that range. >>>>=20 >>>> 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. >>>=20 >>> Quite so, I agree that it is good to specify error cases. >>>=20 >>> My issue is, that you state that: >>>=20 >>> 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=3D0 is >>> considered valid. >>>=20 >>> If you really mean "MUST NOT", then you must also consider a packet rec= eived >>> that violates that "MUST NOT" as to be invalid. >>>=20 >>> Otherwise, the specification appears incoherent. >>>=20 >>=20 >> I noticed another place you have the same comment. We agree "SHOULD NOT= " >> is >> more appropriate here. >>=20 >>>=20 >>>>> 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 stud= ied > 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. >>>>=20 >>>> Actually, this is the first attempt to integrate multi-topology routi= ng >>>> with multicast. >>>=20 >>> Oh=A9..this raises a red flag with me, then, even more than before. My wo= rry >>> when I read through the document was, that I had no idea if, or how wel= l, 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 wa= s why > I >>> raised this issue in my review. >>>=20 >>> You tell me that this is a first attempt at integrating multicast and >>> multi-topology routing - and that is, indeed, both interesting and >>> commendable. >>>=20 >>> 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 studi= ed > the >>> matter and obtained a better understanding of behavior and performance >>> characteristics? >>>=20 >>> Were there any WG discussions regarding Exp-vs-PS that I should go look= at? >>=20 >> The WG didn't have any debate on this. >>=20 >> I'm not sure how strong you feel it this way. I didn't check but I woul= d >> guess there has been many "first time" drafts that started out as "propo= sed >> standard". >>=20 >> We, as co-authors, are fine with moving to Experimental. >>=20 >> AD/Chairs, do you have any opinion here? >>=20 >>=20 >>>>> o As a relatively newcomer to PIM, examples are appreciated. Alas, th= e >>>>> example >>>>> in >>>>> section 3.1 actually didn't help my understanding much. Also, that ex= ample >>>>> 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. >>>>>=20 >>>>=20 >>>> The text was added based on the comment from WG LC. Some people do li= ke >> to >>>> see how MT-IDs are assigned numerically. >>>=20 >>> Alright, then. Would it be possible to simply add a sentence clarifying= that >>> these numbers are mere examples, without any other significance? >>=20 >> Section 3.1 does indicate the part of the description is an example. Fo= r >> example, "consider the following example described by Figure 1", or "Th= e >> above example illustrates ..." >>=20 >> So I guess we are ok here. >>=20 >>>=20 >>>>> 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". >>>>=20 >>>> Yes. The text describes two different cases and provides two differen= t >>>> recommendations depending on how the topologies are built. >>>=20 >>> RECOMMENDED is a SHOULD - which I read to mean "If you do NOT follow th= is >>> recommendation, you should know that there may be consequences - and >> these >>> consequences are =A9.." See below. >>>=20 >>>>> Citing RFC2119: >>>>>=20 >>>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that ther= e >>>>> 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. >>>>>=20 >>>>> It appears to me that if this RFC2119 meaning is intended, then it wo= uld > be >>>>> important >>>>> to (i) explain why and (ii) give guidance as to understand what the >>>>> implications are of >>>>> not following the recommendation. >>>=20 >>> My issue with this text is that you say "RECOMMENDED" - but that I do n= ot > see >>> any consequences of following (or not) the recommendation. In other wor= ds, >> the >>> 2119-meaning of "RECOMMENDED" appears to be too strong. Maybe writing >>> "suggested" (lower-case, non-2119) would suffice? >>>=20 >>=20 >> 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. >>=20 >>> In either case, I would like to understand why you recommend or suggest > this. >>> Could you add an explanatory sentence/paragraph? >>=20 >> 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. >>=20 >>>=20 >>>>> Same holds for the last bullet point on page 5. >>>>>=20 >>>>> 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 maintaine= d by >>>>> the >>>>> two routing >>>>> topologies? >>>>>=20 >>>>=20 >>>> In multicast jargons, S usually refers to a /32 host address (assumin= g >>>> IPv4). But the routing table usually contains only a prefix that cove= rs or >>>> includes S, instead of S. >>>=20 >>> OK, let's ascribe that to me not knowing multicast jargon ;) >>>=20 >>> I suggest inserting a rephrasing of this paragraph into the terminology >>> section, then? >>>=20 >>=20 >> 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. >>=20 >>=20 >>>>> o Generally to section 3.1, it is somewhat unclear what this specific= ation >>>>> does, vs. what >>>>> PIM already does, which caused me to chase off reading PIM RFCs. >>>>>=20 >>>>> Reading through the specification, would it be correct to say that: >>>>>=20 >>>>> - 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? >>>>>=20 >>>>> If yes, then I would suggest calling that out explicitly. >>>>=20 >>>> No it is not a new name-space. >>>>=20 >>>> This document introduces a new type of Join Attribute which was introd= uced >>>> by RFC5384. >>>=20 >>> Then I strongly suggest stating that, almost as you phrased it above, i= n >>> section 3. >>=20 >> Yes. The terminologies section we added to rev-09 hopefully captures th= at. >>=20 >>>=20 >>>=20 >>>>> 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". >>>>=20 >>>> In this document, yes they are the same. >>>=20 >>> If they are the same, then I suggest picking one, defining in a termino= logy >>> section - and sticking to that choice through the document. If both ter= ms > are >>> used in literature, pick the most used term, and have the terminology > section >>> state "MT-ID - is . In some literature, this is also occasio= nally >>> called PIM MT-ID" >>>=20 >>=20 >> Please see the above. >>=20 >>>>=20 >>>>>=20 >>>>> o Section 4.2.1: missing colon before bullet points >>>>>=20 >>>>> o Section 4.2.1 first bullet point: why MUST NOT? What are the >> consequences >>>>> of >>>>> including a Join Attribute when the MT-ID=3D0? >>>>> Specifically, in 4.2.3, the ultimate bullet, the validation rules sim= ply >>>>> state >>>>> that if >>>>> the value is 0, then the Join Attribute "...is ignored" (there is a S= HOULD >>>>> or >>>>> MUST >>>>> needed here?) and that the rest of the message is processed as if tha= t > Join >>>>> Attribute was not included. >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> Still, does this document create an IANA registry for MT-IDs? Generally= , I >>> would expect an I-D to state something of the form: >>>=20 >>> "IANA is requested to create a registry for =A9.. with initial assignment= s and >>> allocation policies according to table 42" >>>=20 >>> (which the RFC editor tends to reword to something like "IANA has creat= ed a >>> registry for =A9.") >>>=20 >>> This makes it clear if the registry, its policies, etc., are to be foun= d in >>> this document, and are therefore completely documented in this document= . >>>=20 >>> 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 =A9. from = the >>> XXXX registry, defined in RFCxxxx" - that way I would know where to go = look >>> for assignments, policies, =A9. >>>=20 >>> 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 th= at >>> 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 understo= od >>> meaning, and that therefore that value should be avoided, it would actu= ally > be >>> immensely useful to have that explanation with the IANA registry creati= on - >>> effectively this would be guidance to IANA as to how to assign values f= rom >>> that registry. >>>=20 >>> If this document doesn't create that IANA registry, then I would expect= this >>> discussion to be in the document which does? >>=20 >> Thomas, >>=20 >> I think we probably had a misunderstanding here. >>=20 >> We ask the IANA to do two things, >>=20 >> 1. make 30 a permanent assignment in the space of "PIM Hello Option". >> Option #30 will then refer to PIM MT-ID Hello Option. >>=20 >> 2. assign a new value for a new type of PIM Join Attribute. This value >> indicates the Join Attribute is "PIM MT-ID". >>=20 >> Both Hello Option and Join Attribute are existing IANA registries. So t= his >> draft doesn't request to create a new registry but to assign a new value= (or >> make one permanent). >>=20 >> The draft does *NOT* ask IANA to create a registry for the MT-ID space. >>=20 >>>=20 >>>>> 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 foll= owing >>>>> them)? >>>>>=20 >>>>=20 >>>> Because these packets do not require the receiving router to perform a= ny > RPF >>>> action. And when a router doesn't perform RPF action, MT-ID is not > needed. >>>=20 >>> Suggest saying that in the document. Is it a SHOULD or a MUST? It sound= s a > bit >>> like a MUST to me? >>=20 >> This is similar to an earlier comment of yours. We still want to proces= s >> the packets so maybe we will stay with "SHOULD NOT"? >>=20 >>>=20 >>>>> 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 J= oin >>>>> Attribute included - >>>>> then goes on to say that it's OK if there are more, just ignore all b= ut > the >>>>> last. I would suggest >>>>> that either this is a validation check and so if more than 1 PIM MT-I= D > 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 v= alid > or >>>>> not. >>>>=20 >>>> That is exactly why we wanted to include this document how to handle e= rror >>>> 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 o= n >>>> previous PDUs which is hard to do. >>>=20 >>> That's fine, but then it is not "Validating" - a packet with one or mor= e PIM >>> MT-ID Join Attributes are all valid. >>=20 >> 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 t= he >> processing result of (*,G)/(S,G)s in front of it. >>=20 >> This is what implementations are currently doing anyway. The draft just >> makes it more explicit. >>=20 >>>=20 >>> 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 b= e >>> valid. Yet, in the next sentence you say that it's ok if there are more= than >>> one, just use the last. >>>=20 >>> Either it is "at most 1" or it is "there may be more, use the last". It > can't >>> be both. >>=20 >> Actually, one describes "sending", the other describes "receiving". That= was >> our intention. >>=20 >>>=20 >>> 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, wha= t are >>> they? If no, why different words? >>>=20 >>=20 >> There is no difference. >>=20 >>>>> 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 Pac= ket >>>>> with >>>>> a PIM MT-ID >>>>> Join Attribute" instead? >>>>=20 >>>> 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 valida= te >>>> Join Attributes or the Join message in general. >>>=20 >>> Then it is even more confusing. Would "Validating PIM MT-ID Join Attrib= utes > 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)? >>>=20 >>=20 >> I actually don't see it that bad. Maybe just "Validation"? >>=20 >>=20 >>>=20 >>>>=20 >>>>> o Section 5: Suggest calling out that reserved bits SHOULD be cleared= on >>>>> transmission and >>>>> MUST be ignored on reception. >>>>>=20 >>>>=20 >>>> Yes it s ithere. >>>>=20 >>>=20 >>> Sorry, no, I do not find that. Can you point me to where you say that, > please? >>=20 >> It wasn't obvious in rev-08. But we made it explicit in rev-09. >>=20 >>>=20 >>>>> o Section 5: Suggest citing the spec defining the format used (RFC538= 4?), >>>>> least it appears >>>>> odd to have an 8 bit "Length" field, and yet defining its value to al= ways > be >>>>> 2. >>>>>=20 >>>>=20 >>>> That would be RFC4601. >>>>=20 >>>>> o Section 6, IANA considerations. >>>>>=20 >>>>> - Suggest that "The IANA" be replaced by simply "IANA" >>>>>=20 >>>>=20 >>>> Ok. >>>>=20 >>>>> - 2nd paragraph, should it be "IANA has assigned the PIM HELLO Option= Type >>>>> ...." >>>>>=20 >>>>=20 >>>> Not yet but IANA will. >>>=20 >>> 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 rephra= sing > as >>> instructions (as also discussed above with registry creation). >>>=20 >>=20 >> Same. I felt we might have a disconnect here. So please let us know if= the >> above explanation helps. Thanks. >>=20 >>=20 >>=20 >> -- >> Yiqun >=20 --=20 Yiqun From bhupesh@cisco.com Mon Sep 26 14:00:53 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770641F0D0E for ; Mon, 26 Sep 2011 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpBBCCWQcCah for ; Mon, 26 Sep 2011 14:00:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE1A1F0CB7 for ; Mon, 26 Sep 2011 14:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bhupesh@cisco.com; l=7506; q=dns/txt; s=iport; t=1317071016; x=1318280616; h=from:to:cc:subject:in-reply-to:references:mime-version: content-transfer-encoding:date:message-id; bh=TKXxZ8UJir1b7AFZ11hbl+kgi2QixYUayFm3k37Y1X0=; b=IYKhkfZonubnHj/RUQGFzOYZpMxRJw0VxT8Za3V2LY7rnHeNHsesGxPB JrLd1ZFPWVGG9aKCJ/swRRxoDREMfyV6cH+oiSV7WTik+eEFfGUBAHGiQ WeVISh2nsp7bbUVJsn3agQ8Pb4eOWH9+kR8oWEuNjyJB25kgE3YheIOGi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAADogE6rRDoI/2dsb2JhbABChGKjDHiBUwEBAQECARIBEEgFAgcFCwsaAgUhAgIPHREaBgESGweHVpwqAYxDkXGBLIROgREEh3KLYJFT X-IronPort-AV: E=Sophos;i="4.68,446,1312156800"; d="scan'208";a="4397679" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 26 Sep 2011 21:03:34 +0000 Received: from bhukotha-desktop.cisco.com (dhcp-171-71-139-134.cisco.com [171.71.139.134]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8QL3YJd014643; Mon, 26 Sep 2011 21:03:34 GMT Received: by bhukotha-desktop.cisco.com (Postfix, from userid 1000) id 3EFFF3480DEB; Mon, 26 Sep 2011 14:03:34 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by bhukotha-desktop.cisco.com (Postfix) with ESMTP id 1184E3480181; Mon, 26 Sep 2011 14:03:34 -0700 (PDT) From: Bhupesh Kothari To: "Bocci\, Matthew \(Matthew\)" , Kireeti Kompella In-reply-to: References: X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Sep 2011 14:03:34 -0700 Message-ID: <25006.1317071014@cisco.com> X-Mailman-Approved-At: Mon, 26 Sep 2011 14:01:33 -0700 Cc: "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 21:00:53 -0000 Bocci, Matthew (Matthew) wrote: > Comments: >=20 > Major Issues: >=20 > - Relationship to published and on-going work in the L2VPN and PWE3 worki= ng > groups. This draft describes an alternative to the procedures for signall= ing PW > labels used in pt-pt layer 2 VPNs (VPWS) and for auto-discovery of endpoi= nts > participating in a L2VPN. The existing IETF-approved technologies use LDP= for > the signalling (as described in RFC4447) and a combination of that with B= GP for > auto-discovery (RFC6074). Since this draft describes an alternative that = was > rejected by the L2VPN WG, I would suggest adding a disclaimer to the abst= ract > and introduction, as per the recommendation of RFC5742, along the lines o= f "The > IETF technology for this function is specified in RFC6074 and > RFC4447", Is this a blocker for this draft to get published? If not, I would like to not include your suggestion. Or, to be fair, can I add the following: " The IETF techonology for this function is specified in RFC6074 and RFC4447 but following are the disadvantages of each: " I don't want a reader to assume that the IETF "approved" technology equals "better" technology. There are pros and cons of each, and SPs are the ultimate judge of which solution meets the requirements of their networks. In this case, this is 8/10 year old technology with many SP adoptions, even after IETF decided to not purse it. In addition, this is an Informational RFC and so it is clear to everyone that IETF did not adopt it for standards track. What more is required? > in > addition to the suggestions on the list that implementations of this draf= t must > also comply to these RFCs.=20=20 What is the rationale for this? Stating this adds no value, increases unnecessary complexity for both vendors and customers and is irrelevant, at least from a technical point of view. Neither RFC that you are mentioning is required for proper functioning of this draft. Why would you like to force a vendor to implement complete disjoint techonologies? As a result, you are also forcing the provider to incur the cost of extra code which is not at all needed if he/she wishes to deploy this techology. Also note that in all existing deployment cases, the routers that have implemented this draft also supports RFC4447. >=20 > - Section 9: IANA Considerations. This section requests a registry be cre= ated > with standards action code points. I believe this is not appropriate as t= his is > an informational draft. There has already been some discussion on this po= int on > the list, and that is noted as a part of this review. This has been discussed. Conclusion is to replace 'standards action' with 'expert review'. >=20 > - Section 5: Layer 2 VPN interworking. This section introduces a layer 2 > transport service for IP packet. However, just encapsulating IP packets b= etween > PEs will not be sufficient for a layer 2 VPN service between the CEs. You= also > need to support something to allow L2 address resolution between the CEs,= for > example translation of the neighbour discover protocols (e.g. ARP over Et= hernet > and InvARP over FR). Since this is describing the L2VPN, and not just the= PW > encapsulation, I think this section should either say how this is done wi= th BGP > (draft-ietf-l2vpn-arp-mediation uses LDP) or just say it is out of scope = of > this particular draft and the L2 address is statically configured. I am OK with 'out of scope ...' statement.=20 >=20 >=20 >=20 > Minor Issues: >=20 > General: > - The draft mainly discussed pt-pt L2VPNs. The general term for this is V= PWS, > but this term is not mentioned anywhere. It would help to clarify with a > statement in the introduction that this the subject of the draft. Agree. >=20 > - It would help if the figures showing the TLV structures showed the deta= iled > structure, throughout, including bit fields, etc, in line with common pra= ctice > in IETF RFCs. There is only one TLV defined in the draft (Table 2). Can you point which other places need changes? >=20 >=20=20 >=20 > - 1. Introduction, 5th paragraph: > "Technically, the approach proposed here uses the concepts and > solution and described in [RFC4761], which describes VPLS, a > particular form of a Layer 2 VPN." >=20 > This reads as if RFC4761 is *the* description of VPLS. This is not the ca= se and > the IETF has standardised two VPLS methods. I propose modifying this to "= =E2=80=A6which > describes a method for VPLS,=E2=80=A6". Agree. >=20 > - 1.1 Terminology. Final paragraph. > "These will be referred to as Attachment > Circuits (ACs), following [RFC4447]. Similarly, the entity that > connects two attachment circuits across the Service Provider network > is called a pseudo-wire (PW)." >=20 > RFC3985 is probably the correct reference. > Also:=20 > s/pseudo-wire/pseudowire Agree. >=20 > - 1.2.5: PE Scaling > This section spends a lot of time discussing the scaling issues of L3 VPN= s. I > am not sure why this is required in a BGP L2VPN draft, unless the issue i= s that > because the control plane is the same, many of the same scaling considera= tions > apply. Please can you clarify if this is true, and if so make such a note= in > the text? The intention of this sub-section is to highlight the better scaling properties of BGP VPWS in comparision to BGP L3 VPNs. In order to highlight, the sub-section has a couple of paragraphs on what the L3 VPN scaling issues are on PEs and RRs that also hold the BGP VPWS state.=20 >=20 > - 1.3: Advantages of Layer 3 VPNs > I do not think this adds any value to a draft on L2 VPNs. The content may= be > useful elsewhere, but I think it would be better if this was removed from= this > draft.=20 The content is useful. It is also a bit historic in the sense that when this draft came out (8/10 years back), it was more appropriate to contrast L2 and L3 VPNs. I am OK if this section was removed.=20 >=20 > - 3: Operation of Layer 2 VPNs > "In what follows, Frame Relay serves as the Layer 2 medium, and each > CE has multiple DLCIs to its PE, each to connect to another CE in the > VPN. If the Layer 2 medium were ATM, then each CE would have > multiple VPI/VCIs to connect to other CEs. " >=20 > I think I know what you mean by "medium" I.e. The underlying link layer, = where > each group of DLCIs is an AC in the RFC3985 sense, plus DLCI acts as a > demarkation of a L2VPN service between the PE and CE. If so, I think it w= ould > help to add this clarification. Agree.=20 > - 6.3: IP-Only Layer 2 Interworking: >=20 > +----------------------------+ > | Tunnel | VPN | IP | VPN label is the > | Encap | Label | Packet | demultiplexing field > +----------------------------+ >=20 > Figure 3: Format of IP-only Layer 2 interworking packet >=20 > I think the field marked "Tunnel Encap" should instead be labelled "PSN > Transport Header" or "MPLS Transport Header", in common with the other > encapsulation RFCs that you have referenced. >=20 Agree. >=20 > Best regards >=20 > Matthew >=20 Thanks for the review. Bhupesh From matthew.bocci@alcatel-lucent.com Tue Sep 27 03:24:07 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8366F21F8B2F for ; Tue, 27 Sep 2011 03:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.917 X-Spam-Level: X-Spam-Status: No, score=-105.917 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M2I6sgx48mx for ; Tue, 27 Sep 2011 03:24:06 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61CBE21F8B20 for ; Tue, 27 Sep 2011 03:24:05 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8RAPcq1005452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Sep 2011 12:26:46 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.35]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 27 Sep 2011 12:26:38 +0200 From: "Bocci, Matthew (Matthew)" To: Bhupesh Kothari , Kireeti Kompella Date: Tue, 27 Sep 2011 12:26:35 +0200 Thread-Topic: RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt Thread-Index: Acx8//BRkMsQ37AlT8Ky6V3z8DqkhQ== Message-ID: In-Reply-To: <25006.1317071014@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "rtg-dir@ietf.org" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 10:24:07 -0000 Bhupesh, Thanks for the quick response. Please see below. Matthew On 26/09/2011 22:03, "Bhupesh Kothari" wrote: > >Bocci, Matthew (Matthew) wrote: > >> Comments: >>=20 >> Major Issues: >>=20 >> - Relationship to published and on-going work in the L2VPN and PWE3 >>working >> groups. This draft describes an alternative to the procedures for >>signalling PW >> labels used in pt-pt layer 2 VPNs (VPWS) and for auto-discovery of >>endpoints >> participating in a L2VPN. The existing IETF-approved technologies use >>LDP for >> the signalling (as described in RFC4447) and a combination of that with >>BGP for >> auto-discovery (RFC6074). Since this draft describes an alternative >>that was >> rejected by the L2VPN WG, I would suggest adding a disclaimer to the >>abstract >> and introduction, as per the recommendation of RFC5742, along the lines >>of "The >> IETF technology for this function is specified in RFC6074 and >> RFC4447", > >Is this a blocker for this draft to get published? If not, I would >like to not include your suggestion. Yes, this needs to be included. The rationale for the statement is to distinguish an AD-sponsored Informational RFC from an Informational RFC that is the product of a working group. > >Or, to be fair, can I add the following: > >" >The IETF techonology for this function is specified in RFC6074 and >RFC4447 but following are the disadvantages of each: > > >" > >I don't want a reader to assume that the IETF "approved" technology >equals "better" technology. There are pros and cons of each, and SPs >are the ultimate judge of which solution meets the requirements of >their networks. In this case, this is 8/10 year old technology with >many SP adoptions, even after IETF decided to not purse it. I do not agree that this draft should debate the pros and cons of the output of PWE3 and L2VPN. I am sure there are many other channels to do that. I think the value in this draft is in documenting this alternative approach that has been implemented and deployed, and to do it to a sufficient level of detail that is useful to other implementers, not to position this within the market. > >In addition, this is an Informational RFC and so it is clear to >everyone that IETF did not adopt it for standards track. What more is >required? Please see my comment above about AD-sponsored vs. the product of a WG. > > > >> in >> addition to the suggestions on the list that implementations of this >>draft must >> also comply to these RFCs. > >What is the rationale for this? > >Stating this adds no value, increases unnecessary complexity for both >vendors and customers and is irrelevant, at least from a technical >point of view. > >Neither RFC that you are mentioning is required for proper functioning >of this draft. Why would you like to force a vendor to implement >complete disjoint techonologies? As a result, you are also forcing >the provider to incur the cost of extra code which is not at all >needed if he/she wishes to deploy this techology. > >Also note that in all existing deployment cases, the routers that have >implemented this draft also supports RFC4447. The two RFC's cited are the IETF standards track RFCs for endpoint discovery and signalling PWs used for VPWS. It doesn't sound like it is burdensome to implement RFC4447 as well if all existing deployments have it. I was reiterating the sentiments of others who have provided IETF last call comments on the draft. The way I would view this is that if you signal PWs, you must at least support tLDP, and in addition BGP can be supported. It is very important that we do not to create a situation where a service provider can inadvertently create non-interoperable islands in their infrastructure. > >>=20 >> - Section 9: IANA Considerations. This section requests a registry be >>created >> with standards action code points. I believe this is not appropriate as >>this is >> an informational draft. There has already been some discussion on this >>point on >> the list, and that is noted as a part of this review. > > >This has been discussed. Conclusion is to replace 'standards action' >with 'expert review'. Thanks > > > >>=20 >> - Section 5: Layer 2 VPN interworking. This section introduces a layer 2 >> transport service for IP packet. However, just encapsulating IP packets >>between >> PEs will not be sufficient for a layer 2 VPN service between the CEs. >>You also >> need to support something to allow L2 address resolution between the >>CEs, for >> example translation of the neighbour discover protocols (e.g. ARP over >>Ethernet >> and InvARP over FR). Since this is describing the L2VPN, and not just >>the PW >> encapsulation, I think this section should either say how this is done >>with BGP >> (draft-ietf-l2vpn-arp-mediation uses LDP) or just say it is out of >>scope of >> this particular draft and the L2 address is statically configured. > > >I am OK with 'out of scope ...' statement. Thanks >=20 > > >>=20 >>=20 >>=20 >> Minor Issues: >>=20 >> General: >> - The draft mainly discussed pt-pt L2VPNs. The general term for this is >>VPWS, >> but this term is not mentioned anywhere. It would help to clarify with a >> statement in the introduction that this the subject of the draft. > > >Agree. > > > >>=20 >> - It would help if the figures showing the TLV structures showed the >>detailed >> structure, throughout, including bit fields, etc, in line with common >>practice >> in IETF RFCs. > > >There is only one TLV defined in the draft (Table 2). Can you point >which other places need changes? I think it would also help if figure 3 showed the packet structure. You could use the following figure from RFC4619 as an template: +-------------------------------+ | MPLS Tunnel label(s) | n*4 octets (four octets per label) +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Control Word | | (See Figure 4) | 4 octets +-------------------------------+ | Payload | | (Frame relay frame | | information field) | n octets | | +-------------------------------+ > > >>=20 >> =20 >>=20 >> - 1. Introduction, 5th paragraph: >> "Technically, the approach proposed here uses the concepts and >> solution and described in [RFC4761], which describes VPLS, a >> particular form of a Layer 2 VPN." >>=20 >> This reads as if RFC4761 is *the* description of VPLS. This is not the >>case and >> the IETF has standardised two VPLS methods. I propose modifying this to >>"=8Awhich >> describes a method for VPLS,=8A". > > >Agree. > > >>=20 >> - 1.1 Terminology. Final paragraph. >> "These will be referred to as Attachment >> Circuits (ACs), following [RFC4447]. Similarly, the entity that >> connects two attachment circuits across the Service Provider network >> is called a pseudo-wire (PW)." >>=20 >> RFC3985 is probably the correct reference. >> Also:=20 >> s/pseudo-wire/pseudowire > > >Agree. > > > >>=20 >> - 1.2.5: PE Scaling >> This section spends a lot of time discussing the scaling issues of L3 >>VPNs. I >> am not sure why this is required in a BGP L2VPN draft, unless the issue >>is that >> because the control plane is the same, many of the same scaling >>considerations >> apply. Please can you clarify if this is true, and if so make such a >>note in >> the text? > >The intention of this sub-section is to highlight the better scaling >properties of BGP VPWS in comparision to BGP L3 VPNs. In order to >highlight, the sub-section has a couple of paragraphs on what the >L3 VPN scaling issues are on PEs and RRs that also hold the BGP VPWS >state. OK. Maybe you could add a sentence explaining that that these scaling issues may also affect the state space available for BGP VPWS on PEs and RRs that host both VPN types. >=20 > > > >>=20 >> - 1.3: Advantages of Layer 3 VPNs >> I do not think this adds any value to a draft on L2 VPNs. The content >>may be >> useful elsewhere, but I think it would be better if this was removed >>from this >> draft.=20 > > >The content is useful. It is also a bit historic in the sense that >when this draft came out (8/10 years back), it was more appropriate to >contrast L2 and L3 VPNs. > >I am OK if this section was removed. Thanks. I don't disagree that it is useful, it is just out of context so it would be better if it could be removed. >=20 > > >>=20 >> - 3: Operation of Layer 2 VPNs >> "In what follows, Frame Relay serves as the Layer 2 medium, and each >> CE has multiple DLCIs to its PE, each to connect to another CE in the >> VPN. If the Layer 2 medium were ATM, then each CE would have >> multiple VPI/VCIs to connect to other CEs. " >>=20 >> I think I know what you mean by "medium" I.e. The underlying link >>layer, where >> each group of DLCIs is an AC in the RFC3985 sense, plus DLCI acts as a >> demarkation of a L2VPN service between the PE and CE. If so, I think it >>would >> help to add this clarification. > > >Agree.=20 > > > > >> - 6.3: IP-Only Layer 2 Interworking: >>=20 >> +----------------------------+ >> | Tunnel | VPN | IP | VPN label is the >> | Encap | Label | Packet | demultiplexing field >> +----------------------------+ >>=20 >> Figure 3: Format of IP-only Layer 2 interworking packet >>=20 >> I think the field marked "Tunnel Encap" should instead be labelled "PSN >> Transport Header" or "MPLS Transport Header", in common with the other >> encapsulation RFCs that you have referenced. >>=20 > > >Agree. > > > >>=20 >> Best regards >>=20 >> Matthew >>=20 > > >Thanks for the review. > > >Bhupesh > From stbryant@cisco.com Tue Sep 27 04:46:50 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EAD21F84A4 for ; Tue, 27 Sep 2011 04:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK4E0XJS6Xnk for ; Tue, 27 Sep 2011 04:46:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 652CE21F8494 for ; Tue, 27 Sep 2011 04:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=8658; q=dns/txt; s=iport; t=1317124175; x=1318333775; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=VUykBwJnx1ov4AXhhSULwQMADm4Lm6unz3OuqV/nHv8=; b=PiDVV/OOfeR4UF7IFMrcibaWXWcYF2Ag17E7LtPWN3Pm9a+4udtKhzaQ txS07l+vw0tZ+3xLLntrq4h8yLxGrdEnV2isAO6wUApq77JcDo0USvZwU 9jQtANXhOC5z+Sc9U7GpdLBbLQaDTltdQvHKw7jOpotPLDO5IKX71vR2s o=; X-IronPort-AV: E=Sophos;i="4.68,449,1312156800"; d="scan'208";a="117441295" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Sep 2011 11:49:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8RBnLNT029012; Tue, 27 Sep 2011 11:49:21 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p8RBnE1j023241; Tue, 27 Sep 2011 12:49:15 +0100 (BST) Message-ID: <4E81B839.7060908@cisco.com> Date: Tue, 27 Sep 2011 12:49:13 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Bhupesh Kothari References: <25006.1317071014@cisco.com> In-Reply-To: <25006.1317071014@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Kireeti Kompella , "Bocci, Matthew \(Matthew\)" , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-kompella-l2vpn-l2vpn-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 11:46:51 -0000 On 26/09/2011 22:03, Bhupesh Kothari wrote: > Bocci, Matthew (Matthew) wrote: > >> Comments: >> >> Major Issues: >> >> - Relationship to published and on-going work in the L2VPN and PWE3 working >> groups. This draft describes an alternative to the procedures for signalling PW >> labels used in pt-pt layer 2 VPNs (VPWS) and for auto-discovery of endpoints >> participating in a L2VPN. The existing IETF-approved technologies use LDP for >> the signalling (as described in RFC4447) and a combination of that with BGP for >> auto-discovery (RFC6074). Since this draft describes an alternative that was >> rejected by the L2VPN WG, I would suggest adding a disclaimer to the abstract >> and introduction, as per the recommendation of RFC5742, along the lines of "The >> IETF technology for this function is specified in RFC6074 and >> RFC4447", > Is this a blocker for this draft to get published? If not, I would > like to not include your suggestion. > > Or, to be fair, can I add the following: > > " > The IETF techonology for this function is specified in RFC6074 and > RFC4447 but following are the disadvantages of each: > > > " > > I don't want a reader to assume that the IETF "approved" technology > equals "better" technology. There are pros and cons of each, and SPs > are the ultimate judge of which solution meets the requirements of > their networks. In this case, this is 8/10 year old technology with > many SP adoptions, even after IETF decided to not purse it. > > In addition, this is an Informational RFC and so it is clear to > everyone that IETF did not adopt it for standards track. What more is > required? Bhupesh There exists an IETF Standards Track solution to the problem. The IETF strongly prefers a single solution, and strongly prefers a Standards Track solution over a WG informational over an individual submission. This is an individual submission. Therefore you have three choices in the matter. You can either include a statement in the document noting that there exists another IETF standards track protocol that achieves the same functionality and which MUST be implemented in a product with the functionality described in this draft (Please see Andy Malis' email during IETF LC for some words). Alternatively you can demonstrate a clear and distinct applicability for this protocol and attempt to get the L2VPN WG to adopt the draft. Given the existing standards track documents from the L2VPN WG, that approach seems most unlikely to succeed. Finally if neither of those approaches are acceptable, you can withdraw the draft from publication. - Stewart > > >> in >> addition to the suggestions on the list that implementations of this draft must >> also comply to these RFCs. > What is the rationale for this? > > Stating this adds no value, increases unnecessary complexity for both > vendors and customers and is irrelevant, at least from a technical > point of view. > > Neither RFC that you are mentioning is required for proper functioning > of this draft. Why would you like to force a vendor to implement > complete disjoint techonologies? As a result, you are also forcing > the provider to incur the cost of extra code which is not at all > needed if he/she wishes to deploy this techology. > > Also note that in all existing deployment cases, the routers that have > implemented this draft also supports RFC4447. > >> - Section 9: IANA Considerations. This section requests a registry be created >> with standards action code points. I believe this is not appropriate as this is >> an informational draft. There has already been some discussion on this point on >> the list, and that is noted as a part of this review. > > This has been discussed. Conclusion is to replace 'standards action' > with 'expert review'. > > > >> - Section 5: Layer 2 VPN interworking. This section introduces a layer 2 >> transport service for IP packet. However, just encapsulating IP packets between >> PEs will not be sufficient for a layer 2 VPN service between the CEs. You also >> need to support something to allow L2 address resolution between the CEs, for >> example translation of the neighbour discover protocols (e.g. ARP over Ethernet >> and InvARP over FR). Since this is describing the L2VPN, and not just the PW >> encapsulation, I think this section should either say how this is done with BGP >> (draft-ietf-l2vpn-arp-mediation uses LDP) or just say it is out of scope of >> this particular draft and the L2 address is statically configured. > > I am OK with 'out of scope ...' statement. > > >> >> >> Minor Issues: >> >> General: >> - The draft mainly discussed pt-pt L2VPNs. The general term for this is VPWS, >> but this term is not mentioned anywhere. It would help to clarify with a >> statement in the introduction that this the subject of the draft. > > Agree. > > > >> - It would help if the figures showing the TLV structures showed the detailed >> structure, throughout, including bit fields, etc, in line with common practice >> in IETF RFCs. > > There is only one TLV defined in the draft (Table 2). Can you point > which other places need changes? > > >> >> >> - 1. Introduction, 5th paragraph: >> "Technically, the approach proposed here uses the concepts and >> solution and described in [RFC4761], which describes VPLS, a >> particular form of a Layer 2 VPN." >> >> This reads as if RFC4761 is *the* description of VPLS. This is not the case and >> the IETF has standardised two VPLS methods. I propose modifying this to "…which >> describes a method for VPLS,…". > > Agree. > > >> - 1.1 Terminology. Final paragraph. >> "These will be referred to as Attachment >> Circuits (ACs), following [RFC4447]. Similarly, the entity that >> connects two attachment circuits across the Service Provider network >> is called a pseudo-wire (PW)." >> >> RFC3985 is probably the correct reference. >> Also: >> s/pseudo-wire/pseudowire > > Agree. > > > >> - 1.2.5: PE Scaling >> This section spends a lot of time discussing the scaling issues of L3 VPNs. I >> am not sure why this is required in a BGP L2VPN draft, unless the issue is that >> because the control plane is the same, many of the same scaling considerations >> apply. Please can you clarify if this is true, and if so make such a note in >> the text? > The intention of this sub-section is to highlight the better scaling > properties of BGP VPWS in comparision to BGP L3 VPNs. In order to > highlight, the sub-section has a couple of paragraphs on what the > L3 VPN scaling issues are on PEs and RRs that also hold the BGP VPWS > state. > > > >> - 1.3: Advantages of Layer 3 VPNs >> I do not think this adds any value to a draft on L2 VPNs. The content may be >> useful elsewhere, but I think it would be better if this was removed from this >> draft. > > The content is useful. It is also a bit historic in the sense that > when this draft came out (8/10 years back), it was more appropriate to > contrast L2 and L3 VPNs. > > I am OK if this section was removed. > > >> - 3: Operation of Layer 2 VPNs >> "In what follows, Frame Relay serves as the Layer 2 medium, and each >> CE has multiple DLCIs to its PE, each to connect to another CE in the >> VPN. If the Layer 2 medium were ATM, then each CE would have >> multiple VPI/VCIs to connect to other CEs. " >> >> I think I know what you mean by "medium" I.e. The underlying link layer, where >> each group of DLCIs is an AC in the RFC3985 sense, plus DLCI acts as a >> demarkation of a L2VPN service between the PE and CE. If so, I think it would >> help to add this clarification. > > Agree. > > > > >> - 6.3: IP-Only Layer 2 Interworking: >> >> +----------------------------+ >> | Tunnel | VPN | IP | VPN label is the >> | Encap | Label | Packet | demultiplexing field >> +----------------------------+ >> >> Figure 3: Format of IP-only Layer 2 interworking packet >> >> I think the field marked "Tunnel Encap" should instead be labelled "PSN >> Transport Header" or "MPLS Transport Header", in common with the other >> encapsulation RFCs that you have referenced. >> > > Agree. > > > >> Best regards >> >> Matthew >> > > Thanks for the review. > > > Bhupesh > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html