From adrian@olddog.co.uk Thu Aug 4 09:02:44 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18CD21F8574 for ; Thu, 4 Aug 2011 09:02:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPzWkGrm3hcJ for ; Thu, 4 Aug 2011 09:02:42 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 6700621F84EC for ; Thu, 4 Aug 2011 09:02:42 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p74G2rKV021146; Thu, 4 Aug 2011 17:02:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p74G2p52021136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Aug 2011 17:02:52 +0100 From: "Adrian Farrel" To: Date: Thu, 4 Aug 2011 17:02:52 +0100 Message-ID: <022401cc52bf$f7901d70$e6b05850$@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: AcxSv+iVmzR/B+NwSF6KP3LhmTp7qA== Content-Language: en-gb Cc: pim@ietf.org Subject: [pim] AD Review of draft-ietf-pim-port X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:02:44 -0000 Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. I don't have any major technical issues with your draft. The intention and solution are fine. However, I found a largish number of small issues and questions. These are mainly concerns with clarity, although I did have some more substantial concerns about the use of experimental code points. All of my comments are up for discussion, and you should not feel rail-roaded into making changes. But I do think my comments need to be addressed before it goes to IESG review, and I would like you to have a look and see whether you can work to improve the text before I take it forward. I have moved the draft into "AD-review:Revised-ID-needed" state in the datatracker, and I look forward to seeing the new revision which I can put forward for IETF last call. Thanks, Adrian --- You should change "draft" to "document" in the Abstract. --- While I understand your motivation, the argument presented in the Abstract is suspect. You suggest that replacing one retransmission protocol with another will reduce CPU and bandwidth load. I think that the purposes you describe in the Introduction have a bit more focus, and would make for a better Abstract. Perhaps you could write... This document creates a simple incremental mechanism to provide reliable PIM message delivery in PIM version 2 for use with PIM Sparse-Mode (including Source-Specific Multicast) and Bidirectional PIM. The reliable transport mechanism will be used for Join-Prune message transmission only, and can use either TCP or SCTP as the transport protocol. --- In Section 1 you say: This specification enables greater scalability in terms of control traffic overhead. However, for routers connected to multi-access links that comes at the price of increased control plane state overhead and the control plane overhead required to maintain this state. Notwithstanding the price may be worth paying, isn't there overhead of TCP state even on p2p links? --- I appreciate you positioning this work as Experimental. This is consistent with the way that PIM has developed over the years, and fits with the type of extension you are defining. It would be really good if you could add a paragraph to the end of Section 1 that explains the experiment with some scope indicating at what point you might bring the work back to move it on to the Standards Track. You don't need make a big song and dance. I think that you can mention that the protocol extension operates between peers so, experimentation does not need to be constrained to walled gardens. --- Section 1.2 Datagram Mode: The current procedures PIM uses by encapsulating Join/Prune messages in IP packets sent either triggered or periodically. I think you don't want to say "current" since, once your I-D is approved, you hope that this will no longer be the case. How about: Datagram Mode: The procedures whereby PIM encapsulates Join/Prune messages in IP packets sent either triggered or periodically. --- Section 2 This document does not update the PIM Join/Prune packet format. However, for Join/Prune messages sent over TCP/SCTP connections, only what would be the IP payload of a native PIM Join/Prune is included, there is no IP Header. Well, of course, there is an IP header if TCP is delivered over IP. And I don't think anyone would think you intended to carry PIM over IP over TCP over IP. But why are we worried about this? 4601 doesn't spend much time on the IP header (see Section 4.9 of RFC 4601). Perhaps you could replace the sentence to give... This document does not update the PIM Join/Prune packet format. In the procedures described in this document, each Join/Prune message is sent as the payload of a PORT message carried over TCP/SCTP. On which subject, maybe I am slow, but it took me a long time to realise that the PIM messages are not the direct payload of TCP/SCTP and that a wrapping message (the PORT message) is used. Could you make this clearer? Perhaps my suggested change is enough. --- Sections 3.1 and 3.2 Length: Length in bytes for the value part of the Type/Length/Value encoding; where X is the number of bytes that make up the Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is used [AFI]. You should not give [AIF] as a reference for AFI 0 because according to IANA the zero value is Reserved. Thus, the 0 you are specifying is scoped to just these fields. You should write... Length: Length in bytes for the value part of the Type/Length/Value encoding; where X is the number of bytes that make up the Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 if AFI of value 0 is used. --- Sections 3.1 and 3.2 I am hugely suspicious of your determination of three reserved bits as Experimental. Less scrupulous people than yourselves use this sort of mechanism to end-run the standards process and achieve proprietary extensions. That is, they don't use them for experimentation at all :-( At this stage, you probably need to give a hint of the type of experiment that might be run with these bits. Otherwise it would be better to leave all of the bits unreserved. If you do keep the bits as experimental, you must give some clues to non-participating routers about what they do if they see any of the bits set. Do they ignore the bits; do they ignore the message; do they reject the message with an error; or do they tear down the TCP connection? --- Section 4 When a Transport connection is established (or reestablished), the two routers MUST both send a full set of Join/Prune messages for state for which the other router is the upstream neighbor. I understand why. What is the risk that the amount of information that has to be sent is very considerably large? Is there a need for graceful restart? --- Section 4.2 Can you have another look at the text in this section. It looks to me that it contains two attempts to write the same material. Perhaps some paragraphs can be deleted? Could you also include a forward pointer to Section 5.2. --- Section 4.2 JP_HOLDTIME and JP_HoldTime are actually called J/P_Holdtime in RFC 4601 --- Section 5 Title should read 5. PORT Message Definitions --- Section 5 (also Sections 5.3 and 10.4) The TLV type field is 16 bits. The range 61440 - 65535 is for experimental use [RFC3692]. Curious that you give the reference to 3692 but don't follow the advice it contains :-) It says... In many, if not most cases, reserving a single value for experimental use will suffice. While it may be tempting to reserve more in order to make it easy to test many things at once, reserving many may also increase the temptation for someone using a particular value to assume that a specific experimental value can be used for a given purpose exclusively. Can you explain why you need 4096 experimental values rather than, say, four? The same issue arises for the message type in Section 10.3. --- Sections 5.1 and 5.2 I have the same misgivings about the EXP fields in these two messages. Possibly, however, you intend processing rules to be covered by the text in Section 5 that states... PORT messages are error checked. This includes a bad PIM checksum, illegal type fields, illegal addresses or a truncated message. If any parsing errors occur in a PORT message, it is skipped, and we proceed to any following PORT messages. Anyway, clarification of how to handle unexpected EXP bits would help. Meanwhile, the text here implies that the checksum applies to the PORT message. It does not. It may be better to list the error checking on the PORT message, and then state that each payload PIM message is also subject to the normal error checks. --- Sections 5.1 and 5.2 I understand that the PORT messages are just simple wrappers, but I am surprised that you have designed a message format that is different from that used by regular PIM. Also that you have created a new registry for PORT messages rather than picking two values from the PIM message registry. Lastly, that you have not included "protocol version" Of course, this works, and maybe the working group is also OK with this. It just seemed an odd choice. --- Section 5.1 Is there a reason why a PORT message can only contain one PIM message? --- Section 5.1 The description of how to handle unrecognised PORT options is clear. It allows you to survive in the presence of experiments. It does not give you very graceful future-proofing in that you cannot have one router send an option it would like parsed by its peer, but does not care about, since the whole message will be skipped. OTOH, it does not allow a receiver to indicate that it has skipped the received message (and why). If this is a conscious choice, so be it. --- Section 5.2 Wouldn't it be nice to align the YLVs in the same way in both messages? --- Section 5.2 I think you should give some advice for the sender about the Holdtime. 1. Should it be configurable? 2. Is there a default? 3. How often should a KeepAlive be sent relative to the Holdtime if there are no other messages sent? --- Section 5.3 Maybe "PIM IPv4 Join/Prune Option" and "PIM IPv6 Join/Prune Option" would look better as sub-sections. --- Section 6 The mention of "LAN Prune Delay option" could use a reference to [RFC4601] --- Section 8 Idle curiosity... Why don't you allow other PIM messages to delivered reliably over TCP or SCTP? --- Section 10.1 You should request IANA to insert a reference to this document in the port numbers registry. --- Section 13.2 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY NUMBERS http://www.iana.org/numbers.html, February 2007. This should read [AFI] IANA, "Address Family Numbers", ADDRESS FAMILY NUMBERS http://www.iana.org/assignments/address-family-numbers, February 2007. --- Manageability I think you have done a good job in calling out the items that should be configurable. The Ops ADs are increasingly asking us to pull together a single, small section entitled "Manageability". They are pushing back on this for new protocols and for significant protocol extensions. In your case this would just be a list of items and references to the appropriate sections. You would also need to add a list of objects that might be reasonably made available by an implementation for inspection by an operator. Could you add such a section? From wwwrun@rfc-editor.org Tue Aug 9 03:23:17 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB0621F8ACE for ; Tue, 9 Aug 2011 03:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, NO_RELAYS=-0.001, 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 tC+F7iYx9fMd for ; Tue, 9 Aug 2011 03:23:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 84CD821F8AAC for ; Tue, 9 Aug 2011 03:23:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D1BDE98C4F9; Tue, 9 Aug 2011 03:23:45 -0700 (PDT) To: fenner@research.att.com, M.Handley@cs.ucl.ac.uk, holbrook@arastra.com, kouvelas@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, mmcbride7@gmail.com, stig@venaas.com From: RFC Errata System Message-Id: <20110809102345.D1BDE98C4F9@rfc-editor.org> Date: Tue, 9 Aug 2011 03:23:45 -0700 (PDT) X-Mailman-Approved-At: Tue, 09 Aug 2011 09:24:41 -0700 Cc: wcang@sfc.wide.ad.jp, pim@ietf.org, rfc-editor@rfc-editor.org Subject: [pim] [Technical Errata Reported] RFC4601 (2927) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 10:23:18 -0000 The following errata report has been submitted for RFC4601, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4601&eid=2927 -------------------------------------- Type: Technical Reported by: Ang Way Chuang Section: 4.2.2 Original Text ------------- void Update_SPTbit(S,G,iif) { if ( iif == RPF_interface(S) AND JoinDesired(S,G) == TRUE AND ( DirectlyConnected(S) == TRUE OR RPF_interface(S) != RPF_interface(RP(G)) OR inherited_olist(S,G,rpt) == NULL OR ( ( RPF'(S,G) == RPF'(*,G) ) AND ( RPF'(S,G) != NULL ) ) OR ( I_Am_Assert_Loser(S,G,iif) ) { Set SPTbit(S,G) to TRUE } } Corrected Text -------------- void Update_SPTbit(S,G,iif) { if ( iif == RPF_interface(S) AND JoinDesired(S,G) == TRUE AND ( DirectlyConnected(S) == TRUE OR RPF_interface(S) != RPF_interface(RP(G)) OR inherited_olist(S,G,rpt) == NULL OR ( ( RPF'(S,G) == RPF'(*,G) ) AND ( RPF'(S,G) != NULL ) ) OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) { Set SPTbit(S,G) to TRUE } } Notes ----- The logical evaluation is not properly enclosed. The RFC also doesn't mention the reason for the extra checking on the RPF'(S,G) != NULL. It is non-obvious to me. If the check on iif == RPF_interface(S) passes, how would there be any condition where RPF'(S,G) == NULL? Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4601 (draft-ietf-pim-sm-v2-new-12) -------------------------------------- Title : Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) Publication Date : August 2006 Author(s) : B. Fenner, M. Handley, H. Holbrook, I. Kouvelas Category : PROPOSED STANDARD Source : Protocol Independent Multicast Area : Routing Stream : IETF Verifying Party : IESG From ycai@cisco.com Tue Aug 9 13:49:49 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF6E21F8B04; Tue, 9 Aug 2011 13:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BBtadf2gVD0A; Tue, 9 Aug 2011 13:49:48 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DA42821F8B02; Tue, 9 Aug 2011 13:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ycai@cisco.com; l=10968; q=dns/txt; s=iport; t=1312923018; x=1314132618; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=CKrLUywYoxwv2VZEj3FNiVTIxKhr3CKT4sw6BlHN+uY=; b=EOCmw3d7tH3DzQy/0WeQJwSSPGPruhOAqYcjZFGVPAEHhbNmN/+49JVt gPI3UWQfeCAqmyYmM9mVObEZjsYYn7g1D5D9I2w2/OA36lNEz+TBQQzvp FZ7sPwPW0QV/7W07Kukkx55hC/+Mx2tv4vgpVK89yvYr1GsTMxF4Jlvsl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8IABOdQU6rRDoJ/2dsb2JhbABCpz0Cd4FAAQEBAQIBAQEBDwEnAgExCwUNAQhnBjABAQQBDQUbB4dLBJ8QAZ5ahkYEh1yLKYUShF2DAIQc X-IronPort-AV: E=Sophos;i="4.67,345,1309737600"; d="scan'208";a="11479663" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2011 20:50:16 +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 p79KoGCj030223; Tue, 9 Aug 2011 20:50:16 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); Tue, 9 Aug 2011 13:50:16 -0700 Received: from 128.107.161.230 ([128.107.161.230]) by xmb-sjc-216.amer.cisco.com ([171.70.151.184]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 Aug 2011 20:50:15 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 09 Aug 2011 13:50:21 -0700 From: Yiqun Cai To: Marshall Eubanks , IETF Discussion Message-ID: Thread-Topic: [pim] tsv-dir review of draft-ietf-pim-mtid-08 Thread-Index: AcxW1fQVCxnlCmf+6kW+cOAFGDDVgQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Aug 2011 20:50:16.0307 (UTC) FILETIME=[F149CC30:01CC56D5] Cc: TSV Area , pim@ietf.org, Transport Directorate Subject: Re: [pim] tsv-dir review of draft-ietf-pim-mtid-08 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 20:49:49 -0000 Marshall, thank you very much for the review. Some of my comments are inline. On 6/30/11 7:22 AM, "Marshall Eubanks" wrote: > I've reviewed this document as part of the transport area directorate's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors for their information and to allow them to address any issues raised. > The authors should consider this review together with any other last-call > comments they receive. Please always CC tsv-dir@ietf.org if you reply to or > forward this review. > > Note : I also reviewed the WG mailing list discussions for this document. > > This draft is basically ready for publication, but has some issues that in my > opinion should be fixed before publication. > > There are, however, some issues that I think that should be addressed, either > in a follow-on document, or a revision of this document. > > draft-ietf-pim-mtid introduces a new type of PIM Join Attribute [RFC5384], > the MT-ID Join Attribute, that extends > PIM signaling to cover multiple topologies and to enable the identification of > which topology should be used when > constructing a particular multicast distribution tree. > > Multiple topologies have been used for some time in unicast (they are > supported by IS-IS and OSPF), and also in multicast. The most common multicast > requirement for multiple topologies is for video transport, where important or > expensive video streams (say, of sporting events) are protected from > disruption by multiple transport on completely different network paths. In > that use, if a network link goes down or becomes congested or otherwise > suboptimal, another source of the video data is already present and the > display can be seamlessly switched to the other copy of the stream. This use > case is alluded to in the document. > > Another use case for multiple-topologies is to separate out different types of > traffic (say, latency sensitive traffic from larger, bulk, flows). This is not > alluded to in this document, and it is not clear to what extent this was > intended. These multiple topologies may or may not result > in the replication of data, and so may not be intended by the author. However, > I would say that this could be used to support this, and so it will be. If > there is some reason NOT to use this mechanism for this purpose, some > description of the reasons why would be in order. > > This document sets up a numerical variable, the MT-ID Join Attribute, to > assign to multicast topologies, to be used to separate different topologies > for different paths. This number for a given multicast topology need not be > the same as any unicast multiple topology identifiers, and similarly the > multicast topologies and the underlying unicast topologies may be different. You are right that there are indeed more use cases that can make use of the functions described by this draft. And some do exist in the field. However, we (as co-authors) were very reluctant to list them. We felt this would be more appropriate to be described and published as whitepapers by vendors, and we indeed have discussed them in public on behalf of our employer. It was our intention to try to keep this draft focused on the changes required from a PIM protocol point of view. I hope you will understand and appreciate our viewpoints. > > This document is sort, straight-forward, and relatively well-written. I had a > few non-fatal issues. (I would be glad to suggest some text for any of these > issues to the authors if they interested.) > > Minor Issues : > > Section 3.2 > > "- As shown earlier, this value is not required to be the same as the MT-ID > used by the unicast routing protocols that contribute routes to the topology. > In practice, when only one unicast routing protocol (such as OSPF or IS-IS) is > used, the PIM MT-ID is RECOMMENDED to be assigned using the same value as the > IGP topology identifier. Using the same example presented earlier, if > every route in PIM 500 is contributed by OSPF 1000, it is RECOMMENDED to name > this RPF topology as PIM 1000 instead of PIM 500. This is for the purpose of > reducing management overhead and simplifying troubleshooting." > > In the actual example, PIM 500 is not the same network topology as OSPF 1000 > (it has an extra link, to the source, obtained by MBGP). This is specifically > mentioned previously in the text. So, this is NOT the same example as > presented earlier and it is NOT clear that this recommendation applies here. What we tried to say here is that, 1. If a PIM topology has routes contributed by different protocols, say OSPF and MBGP, it is better to use a different MT-ID for PIM. For example, use 500 for PIM and 1000 for OSPF. 2. But if a PIM topology has all its routes contributed by a single protocol, then it is better to use the same MT-ID as the underlying unicast protocol and in this case, 1000 is used for both PIM and OSPF. Please let us know if the explanation helps and we will definitely appreciate if you suggest some text here. > > If this is left as is, it will certainly confuse some people. I would suggest > adding text to clarify this, or creating another example where the > unicast and multicast topologies are the same. > > Section 4.2.3 > > "- There is at most 1 PIM MT-ID attribute encoded. If there are multiple PIM > MT-ID Join Attributes included, only the last one is accepted for this > particular source. Processing of the rest of the Join message continues." > > Is this a typo ? > > s/at most/at least/ > > would seem to be appropriate. (It says, "at most" 1, and then describes what > do to if there is more than 1.) Otherwise, please explain what is meant. We did mean there can be "at most" 1 MT-ID attribute. But if there are more than 1 included, most likely due to an implementation error, the rest of the paragraph suggests what an implementation should do. Would it be better if we add "due to an implementation error"? > > Section 6. > > The Labels for Section 6.1 and 6.2 are the same. I suspect this is just a > typo, and they should be > > 6.1. PIM-Hello Options > > 6.2. PIM Join Attribute Types > Good catch. Will fix. > More Substantive Issues : > > I had two substantive issues with this document. > > 1.) The range for the topologies. It is highly likely that the users of this > capability would want to use multiple topologies differently for different > multicast address ranges. For example, use of two topologies is likely to be > an expensive customer option, that not all customers would pay for, and so > would not apply to all multicast addresses. Or, the backup typologies may > (probably will be) tailored differently for different customers in different > locations. Or, topologies might be tailored for different data types > (different backups for real time video conferencing versus TV broadcast > transmissions, say). This is very briefly alluded to in Section 3.1, but no > consideration is given to issues arising from this. > > For example, suppose I have two customers, and I wish to have one basic > topology (say, PIM 100) for 239.10/16, and I wish to have two backup > topologies for the two customers (say, PIM 1001 for 239.10.1/24 and PIM 1002 > for 239.10.2/24.) Can I have PIM 100 cover both the PIM 1001 and PIM 1002 > range ? Are there issues with this ? Would it be better to split PIM 100 into > pieces to match 1001 and 1002 ? Nothing like this is discussed The draft allows the above to happen. Because as I indicated earlier, the draft tries to focus on the protocol changes required to support the functionality but not the deployment cases that can make use of it. > > I can easily see interoperability issues arising from this (i.e., vendor A > might allow PIM 100 to overlap PIM 1001 and PIM 1002, and vendor B might not). > I think that some text to discuss the entire issue of ranging (presumably, > that they can be allowed and overlaps SHOULD be supported) is needed. > > Again, this could be out of scope here, but, then, where will it appear ? I agree it is out of scope for the reasons I explained earlier but I don't have a good answer what is the best practice to document all these cases. > > 2.) There is very little discussion as to how to use this capability. Now, > this might be considered out of scope for this document, but there will be > issues, and I do not see a follow-on in the pipeline. > > Issues include sharing of links and the general connections between > topologies. It is likely that in real uses, a portion of the multiple > topologies may be either physically shared or directly linked. It may not be > possible to engineer out all single points of failure, for example an undersea > cable. This is possible with the first use case (independent topologies for > video) and likely with the second (different topologies for different types of > content). > Yes, same as above. > Issues I see here include > > - the actual multicast data will not include any PIM attributes. How, then, > is a midpoint router receiving two copies of every packet know that it > shouldn't just drop one, and only populate one of the downstreams ? Or, should > it replicate one input into both downstream topologies ? I can easily see > interop issues here, and possibly even more basic transport issues from > replicated data. > To use the functionality, the two streams of multicast must differ somehow at the network layer. For example, one uses (S1,G1) and the other uses (S2,G2). Because the addresses are different, the forwarding trees will be built using routes in the (multiple) topologies. And once the forwarding trees are built, the actual action of "forwarding" doesn't need to be concerned with topologies. > - if at any point the two multicast topologies go through a shared LAN or > switch or any sort of multiple access network, how are the topological flows > going to be kept distinct. (This is similar to the above, but the actual > routers might be kept separate.) > > - what happens with failovers ? If a link fails, SHOULD the backup links not > collapse the topologies ? Again, I think some thought and text would be > useful. > > If there is a solution to this, it may be simple (you MUST use tunnels) or it > may be complicated. In either case, some text here would be good. > Marshall, it would be good if you can suggest some text for us to use. Thanks. > Regards > Marshall > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- Yiqun From stig@venaas.com Tue Aug 9 15:40:08 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18B821F8C2B for ; Tue, 9 Aug 2011 15:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, 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 8VQxoXREUCq0 for ; Tue, 9 Aug 2011 15:40:04 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 7992421F8A4B for ; Tue, 9 Aug 2011 15:40:03 -0700 (PDT) Received: from [10.33.12.82] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9946E804C; Wed, 10 Aug 2011 00:40:31 +0200 (CEST) Message-ID: <4E41B75B.4070308@venaas.com> Date: Tue, 09 Aug 2011 15:40:27 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <022401cc52bf$f7901d70$e6b05850$@olddog.co.uk> In-Reply-To: <022401cc52bf$f7901d70$e6b05850$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-port@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD Review of draft-ietf-pim-port X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 22:40:08 -0000 On 8/4/2011 9:02 AM, Adrian Farrel wrote: > Hi, > > Don't panic! OK, I'm trying not to panic :) See my comments below. > I have performed my AD review of your draft. The purpose of the > review is to catch any nits or issues before the document goes > forward to IETF last call and IESG review. By getting these issues > out at this stage we can hope for a higher quality review and a > smoother passage through the process. > > I don't have any major technical issues with your draft. The intention > and solution are fine. However, I found a largish number of small > issues and questions. These are mainly concerns with clarity, although > I did have some more substantial concerns about the use of experimental > code points. > > All of my comments are up for discussion, and you should not feel > rail-roaded into making changes. But I do think my comments need to be > addressed before it goes to IESG review, and I would like you to have a > look and see whether you can work to improve the text before I take it > forward. > > I have moved the draft into "AD-review:Revised-ID-needed" state in > the datatracker, and I look forward to seeing the new revision which > I can put forward for IETF last call. > > Thanks, > Adrian > > --- > > You should change "draft" to "document" in the Abstract. Right > --- > > While I understand your motivation, the argument presented in the > Abstract is suspect. You suggest that replacing one retransmission > protocol with another will reduce CPU and bandwidth load. Yes! The major reason for this is to not require periodic signaling just to maintain state. That can require a lot of CPU. There are other advantages too though. > I think that the purposes you describe in the Introduction have a bit > more focus, and would make for a better Abstract. Perhaps you could > write... > > This document creates a simple incremental mechanism to provide > reliable PIM message delivery in PIM version 2 for use with PIM > Sparse-Mode (including Source-Specific Multicast) and Bidirectional > PIM. > > The reliable transport mechanism will be used for Join-Prune message > transmission only, and can use either TCP or SCTP as the transport > protocol. This doesn't really say why we want a reliable transport though. Do you think it is better to not explain that in the abstract, and talk about the CPU savings in the introduction instead? > --- > > In Section 1 you say: > > This specification enables greater scalability in terms of control > traffic overhead. However, for routers connected to multi-access > links that comes at the price of increased control plane state > overhead and the control plane overhead required to maintain this > state. > > Notwithstanding the price may be worth paying, isn't there overhead > of TCP state even on p2p links? Yes, the overhead is bigger for multi-access though. There are two types of state. TCP state: This would be on a per neighbor basis. So the amount of state is based on how many neighbors there are. PIM state: When using PORT one needs to use explicit tracking. Normally with PIM for a given (S,G) you only need to remember that someone on the link has joined. But with PORT, for a multi-access link, you need to remember exactly which neighbors. Perhaps I could alter this to say that there is a PIM state overhead for multi-access links? > --- > > I appreciate you positioning this work as Experimental. This is > consistent with the way that PIM has developed over the years, and fits > with the type of extension you are defining. > > It would be really good if you could add a paragraph to the end of > Section 1 that explains the experiment with some scope indicating at > what point you might bring the work back to move it on to the Standards > Track. You don't need make a big song and dance. I think that you can > mention that the protocol extension operates between peers so, > experimentation does not need to be constrained to walled gardens. I think experimental is appropriate, because PIM has always been a soft-state protocol, so this is something completely new and untested. So I can add this, and also the sentence you suggest regarding no constraint regarding walled gardens. Perhaps I can add that it should be considered as a proposed standard once there are experiences from multiple deployments in the field? I don't want to require interoperability, but half expect that with some deployment experience we may figure out some necessary improvements. > --- > > Section 1.2 > > Datagram Mode: The current procedures PIM uses by encapsulating > Join/Prune messages in IP packets sent either triggered or > periodically. > > I think you don't want to say "current" since, once your I-D is > approved, you hope that this will no longer be the case. How about: > > Datagram Mode: The procedures whereby PIM encapsulates Join/Prune > messages in IP packets sent either triggered or periodically. Right, thanks. > --- > > Section 2 > > This document does not update the PIM Join/Prune packet format. > However, for Join/Prune messages sent over TCP/SCTP connections, only > what would be the IP payload of a native PIM Join/Prune is included, > there is no IP Header. > > Well, of course, there is an IP header if TCP is delivered over IP. And > I don't think anyone would think you intended to carry PIM over IP over > TCP over IP. But why are we worried about this? 4601 doesn't spend much > time on the IP header (see Section 4.9 of RFC 4601). > > Perhaps you could replace the sentence to give... > > This document does not update the PIM Join/Prune packet format. > In the procedures described in this document, each Join/Prune message > is sent as the payload of a PORT message carried over TCP/SCTP. Yes, happy with that change :) > On which subject, maybe I am slow, but it took me a long time to realise > that the PIM messages are not the direct payload of TCP/SCTP and that a > wrapping message (the PORT message) is used. Could you make this > clearer? Perhaps my suggested change is enough. Yes. > --- > > Sections 3.1 and 3.2 > > Length: Length in bytes for the value part of the Type/Length/Value > encoding; where X is the number of bytes that make up the > Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, > 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is > used [AFI]. > > You should not give [AIF] as a reference for AFI 0 because according to > IANA the zero value is Reserved. Thus, the 0 you are specifying is > scoped to just these fields. You should write... > > Length: Length in bytes for the value part of the Type/Length/Value > encoding; where X is the number of bytes that make up the > Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is > used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 if AFI of > value 0 is used. Agree. > --- > > Sections 3.1 and 3.2 > > I am hugely suspicious of your determination of three reserved bits as > Experimental. Less scrupulous people than yourselves use this sort of > mechanism to end-run the standards process and achieve proprietary > extensions. That is, they don't use them for experimentation at all :-( > > At this stage, you probably need to give a hint of the type of > experiment that might be run with these bits. Otherwise it would be > better to leave all of the bits unreserved. I don't have any concreate ideas at this stage. But if PORT gets enhanced in the future, it might be good for showing additional capabilities, which PORT enhancements are supported. So if a vendor comes up with a possible PORT extension, and wants to do an experiment, one of these bits can show that it is supported. The main purpose would be to allow testing out new features at a small scale, for a limited time period, but not for more permanent use. It's good to be able to experiment and know that it doesn't conflict with possible future IANA assignments. Pretty much as described in the referenced RFC 3692. I'm fully aware that it can be abused though. But so can reserved bits be. I don't have a strong feeling regarding keeping them or not. I guess we could check with the WG (anyone of you reading this? :) > If you do keep the bits as experimental, you must give some clues to > non-participating routers about what they do if they see any of the bits > set. Do they ignore the bits; do they ignore the message; do they reject > the message with an error; or do they tear down the TCP connection? I agree, that would be needed. I'm a bit unsure how they should be treated, as it depends a bit on what the potential use might be. > --- > > Section 4 > > > When a Transport connection is established (or reestablished), the > two routers MUST both send a full set of Join/Prune messages for > state for which the other router is the upstream neighbor. > > I understand why. > What is the risk that the amount of information that has to be sent is > very considerably large? Is there a need for graceful restart? This is the current PIM behavior, PORT doesn't change this. For both regular PIM and PIM with PORT, one could consider graceful restart extensions. I have ideas regarding that, but at this point I'm not sure if it should be PORT specific, and if we do, I think it is better to leave it as a future extension. > --- > > Section 4.2 > > Can you have another look at the text in this section. It looks to me > that it contains two attempts to write the same material. Perhaps some > paragraphs can be deleted? > > Could you also include a forward pointer to Section 5.2. You're right, I think this can be improved. I'll work on that. > --- > > Section 4.2 > > JP_HOLDTIME and JP_HoldTime are actually called J/P_Holdtime in RFC 4601 Will change. > --- > > Section 5 > > Title should read > > 5. PORT Message Definitions Yes > --- > > Section 5 (also Sections 5.3 and 10.4) > > The TLV type field is 16 bits. The range 61440 - 65535 is for > experimental use [RFC3692]. > > Curious that you give the reference to 3692 but don't follow the advice > it contains :-) It says... > > In many, if not most cases, reserving a single value for experimental > use will suffice. While it may be tempting to reserve more in order > to make it easy to test many things at once, reserving many may also > increase the temptation for someone using a particular value to > assume that a specific experimental value can be used for a given > purpose exclusively. > > Can you explain why you need 4096 experimental values rather than, say, > four? I can make it 4. I felt there was plenty of space, but I agree it will make it easier to abuse it. So I'm happy to use 4. > The same issue arises for the message type in Section 10.3. > > --- > > Sections 5.1 and 5.2 > > I have the same misgivings about the EXP fields in these two messages. > Possibly, however, you intend processing rules to be covered by the text > in Section 5 that states... > > PORT messages are error checked. This includes a bad PIM checksum, > illegal type fields, illegal addresses or a truncated message. If > any parsing errors occur in a PORT message, it is skipped, and we > proceed to any following PORT messages. > > Anyway, clarification of how to handle unexpected EXP bits would help. Agree. > Meanwhile, the text here implies that the checksum applies to the PORT > message. It does not. It may be better to list the error checking on > the PORT message, and then state that each payload PIM message is also > subject to the normal error checks. Agree. > --- > > Sections 5.1 and 5.2 > > I understand that the PORT messages are just simple wrappers, but I am > surprised that you have designed a message format that is different from > that used by regular PIM. Also that you have created a new registry for > PORT messages rather than picking two values from the PIM message > registry. Lastly, that you have not included "protocol version" One issue with using types from the existing PIM registry is that we have very few unallocated types. Also, if a PORT message type would only be used for PORT, I don't see why it makes sense to use the same registry. I would say that PORT may have several different messages, some of them may include a PIM message in the payload. It would be just confusing to say that they are all PORT messages. > Of course, this works, and maybe the working group is also OK with this. > > It just seemed an odd choice. > > --- > > Section 5.1 > > Is there a reason why a PORT message can only contain one PIM message? Ease of parsing. You might as well send a second PORT message. Note that if you have two PIM J/P messages, you might also try to merge them. Also if you have multiple PIM messages, what do you do if say one has wrong checksum and not the other. Also, an implementation would probably read an entire PORT message from TCP before processing. If you have multiple PIM messages, you will wait unless you've read all the data before you process the first message. I guess this could be made to work though. > --- > > Section 5.1 > > The description of how to handle unrecognised PORT options is clear. It > allows you to survive in the presence of experiments. It does not give > you very graceful future-proofing in that you cannot have one router > send an option it would like parsed by its peer, but does not care > about, since the whole message will be skipped. OTOH, it does not allow > a receiver to indicate that it has skipped the received message (and > why). > > > If this is a conscious choice, so be it. I think this is the best option. An alternative would be to have some bits indicating how a peer should behave. Or have say two option ranges, where you say that if you don't understand an option in one range, then you just ignore that option but continue processing, while if the option is in another range, then the entire message should be ignored. I'm interested in your and the WG thoughts on this. > --- > > Section 5.2 > > Wouldn't it be nice to align the YLVs in the same way in both messages? Don't think worth doing that. > --- > > Section 5.2 > > I think you should give some advice for the sender about the Holdtime. > 1. Should it be configurable? > 2. Is there a default? > 3. How often should a KeepAlive be sent relative to the Holdtime if > there are no other messages sent? I prefer leaving this open. An implementation can choose this freely, and still have interoperability. Since we have reliability, a keepalive need only be sent once within each holdtime. The main thing is to send it well before the holdtime. I can add 1-2 sentences with some considerations, but don't want to specify defaults. This can be considered if we want to make it a standard, and we know better what makes sense in different deployments. There are a lot of different opinions on what the best defaults are. > --- > > Section 5.3 > > Maybe "PIM IPv4 Join/Prune Option" and "PIM IPv6 Join/Prune Option" > would look better as sub-sections. Agree. > --- > > Section 6 > > The mention of "LAN Prune Delay option" could use a reference to > [RFC4601] Agree. > --- > > Section 8 > > Idle curiosity... > Why don't you allow other PIM messages to delivered reliably over TCP > or SCTP? That is a long story. The main issue are messages that are periodic. While Hello messages need to be outside PORT, for capabilities, for PORT connection parameters etc. E.g. Asserts would be difficult as they need to be seen by all the routers. I don't have any plans, but at least PORT could be extended to allow other PIM message types in the future, if we see any benefits. > --- > > Section 10.1 > > You should request IANA to insert a reference to this document in the > port numbers registry. Yes. > --- > > Section 13.2 > > [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY > NUMBERS http://www.iana.org/numbers.html, February 2007. > > This should read > > [AFI] IANA, "Address Family Numbers", ADDRESS FAMILY NUMBERS > http://www.iana.org/assignments/address-family-numbers, > February 2007. Oh right. > --- > > Manageability > > I think you have done a good job in calling out the items that should > be configurable. The Ops ADs are increasingly asking us to pull > together a single, small section entitled "Manageability". They are > pushing back on this for new protocols and for significant protocol > extensions. > > In your case this would just be a list of items and references to the > appropriate sections. You would also need to add a list of objects that > might be reasonably made available by an implementation for inspection > by an operator. > > Could you add such a section? OK. I will need some time on this, and propose some improvements. There are a few things above we probably need to discuss a bit further though. Thanks for the detailed review. It has been through several thorough reviews by people in the WG, but you found some issues I think should be taken care of. And a few I'm not so sure about as well... Stig > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From adrian@olddog.co.uk Tue Aug 9 14:48:58 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EE521F8C6C for ; Tue, 9 Aug 2011 14:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_61=0.6] 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 u5+i9bV7WbUF for ; Tue, 9 Aug 2011 14:48:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1409521F8C63 for ; Tue, 9 Aug 2011 14:48:57 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p79LnFYt008924; Tue, 9 Aug 2011 22:49:15 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p79LnCKW008918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Aug 2011 22:49:14 +0100 From: "Adrian Farrel" To: "'Ang Way Chuang'" , "'RFC Errata System'" References: <20110809102345.D1BDE98C4F9@rfc-editor.org> <4E41489C.6040505@sfc.wide.ad.jp> In-Reply-To: <4E41489C.6040505@sfc.wide.ad.jp> Date: Tue, 9 Aug 2011 22:49:12 +0100 Message-ID: <02bf01cc56de$2e3c1640$8ab442c0$@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: AQJDyoDrm2TcN8Ni8VcNbn4ARXOPtgGl88BYlBj2PdA= Content-Language: en-gb X-Mailman-Approved-At: Wed, 10 Aug 2011 09:35:45 -0700 Cc: kouvelas@cisco.com, fenner@research.att.com, holbrook@arastra.com, mmcbride7@gmail.com, M.Handley@cs.ucl.ac.uk, pim@ietf.org Subject: Re: [pim] [Technical Errata Reported] RFC4601 (2927) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:48:58 -0000 How nice to hear someone say "blimey." I think my grandfather used to say it - he was born in East London - but it is not in wide use :-) I updated the type to Editorial. Thanks for coming back on the point. Cheers, Adrian > -----Original Message----- > From: Ang Way Chuang [mailto:wcang@sfc.wide.ad.jp] > Sent: 09 August 2011 15:48 > To: RFC Errata System > Cc: fenner@research.att.com; M.Handley@cs.ucl.ac.uk; holbrook@arastra.com; > kouvelas@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; > mmcbride7@gmail.com; stig@venaas.com; pim@ietf.org > Subject: Re: [Technical Errata Reported] RFC4601 (2927) > > blimey, the type should be editorial not technical. > > On 09/08/11 19:23, RFC Errata System wrote: > > The following errata report has been submitted for RFC4601, > > "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol > Specification (Revised)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=4601&eid=2927 > > > > -------------------------------------- > > Type: Technical > > Reported by: Ang Way Chuang > > > > Section: 4.2.2 > > > > Original Text > > ------------- > > void > > > > Update_SPTbit(S,G,iif) { > > > > if ( iif == RPF_interface(S) > > > > AND JoinDesired(S,G) == TRUE > > > > AND ( DirectlyConnected(S) == TRUE > > > > OR RPF_interface(S) != RPF_interface(RP(G)) > > > > OR inherited_olist(S,G,rpt) == NULL > > > > OR ( ( RPF'(S,G) == RPF'(*,G) ) AND > > > > ( RPF'(S,G) != NULL ) ) > > > > OR ( I_Am_Assert_Loser(S,G,iif) ) { > > > > Set SPTbit(S,G) to TRUE > > > > } > > > > } > > > > Corrected Text > > -------------- > > void > > > > Update_SPTbit(S,G,iif) { > > > > if ( iif == RPF_interface(S) > > > > AND JoinDesired(S,G) == TRUE > > > > AND ( DirectlyConnected(S) == TRUE > > > > OR RPF_interface(S) != RPF_interface(RP(G)) > > > > OR inherited_olist(S,G,rpt) == NULL > > > > OR ( ( RPF'(S,G) == RPF'(*,G) ) AND > > > > ( RPF'(S,G) != NULL ) ) > > > > OR ( I_Am_Assert_Loser(S,G,iif) ) ) ) { > > > > Set SPTbit(S,G) to TRUE > > > > } > > > > } > > > > Notes > > ----- > > The logical evaluation is not properly enclosed. The RFC also doesn't mention > the reason for the extra checking on the RPF'(S,G) != NULL. It is non-obvious to > me. If the check on iif == RPF_interface(S) passes, how would there be any > condition where RPF'(S,G) == NULL? > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC4601 (draft-ietf-pim-sm-v2-new-12) > > -------------------------------------- > > Title : Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol > Specification (Revised) > > Publication Date : August 2006 > > Author(s) : B. Fenner, M. Handley, H. Holbrook, I. Kouvelas > > Category : PROPOSED STANDARD > > Source : Protocol Independent Multicast > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > From adrian@olddog.co.uk Wed Aug 10 11:20:41 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E824621F8A64 for ; Wed, 10 Aug 2011 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 WJ77gjdUBjuC for ; Wed, 10 Aug 2011 11:20:38 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5DE21F8A56 for ; Wed, 10 Aug 2011 11:20:37 -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 p7AIL6lO015399; Wed, 10 Aug 2011 19:21:06 +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 p7AIL4Hg015393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Aug 2011 19:21:05 +0100 From: "Adrian Farrel" To: "'Stig Venaas'" References: <022401cc52bf$f7901d70$e6b05850$@olddog.co.uk> <4E41B75B.4070308@venaas.com> In-Reply-To: <4E41B75B.4070308@venaas.com> Date: Wed, 10 Aug 2011 19:21:03 +0100 Message-ID: <041001cc578a$4431a7b0$cc94f710$@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: AQIX0FDkdqhCRWqmx9Ueap8y2zmzpgJqdjJUlGwNmsA= Content-Language: en-gb Cc: draft-ietf-pim-port@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD Review of draft-ietf-pim-port X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 18:20:41 -0000 Hi Stig. In line. Snipped the agreements. > > While I understand your motivation, the argument presented in the > > Abstract is suspect. You suggest that replacing one retransmission > > protocol with another will reduce CPU and bandwidth load. > > Yes! The major reason for this is to not require periodic signaling > just to maintain state. That can require a lot of CPU. There are > other advantages too though. > > > I think that the purposes you describe in the Introduction have a bit > > more focus, and would make for a better Abstract. Perhaps you could > > write... > > > > This document creates a simple incremental mechanism to provide > > reliable PIM message delivery in PIM version 2 for use with PIM > > Sparse-Mode (including Source-Specific Multicast) and Bidirectional > > PIM. > > > > The reliable transport mechanism will be used for Join-Prune message > > transmission only, and can use either TCP or SCTP as the transport > > protocol. > > This doesn't really say why we want a reliable transport though. Do > you think it is better to not explain that in the abstract, and talk > about the CPU savings in the introduction instead? Hmmm, well, no. I think the Abstract and Introduction should state the full picture. I am saying that moving the reliability mechanism from one protocol to another does not reduce the protocol overhead, it just moves it. But something you say lower down makes sense. This is not about making anything reliable per se, this is about moving from a soft-state model to a hard-state model. In hard state you have: - confirmed delivery (aka reliable delivery) - explicit state teardown (which also has to be confirmed) - neighbor failure detection So we could argue that the objective of the draft is to remove state refresh. Is that the case? Or am I missing something? > > In Section 1 you say: > > > > This specification enables greater scalability in terms of control > > traffic overhead. However, for routers connected to multi-access > > links that comes at the price of increased control plane state > > overhead and the control plane overhead required to maintain this > > state. > > > > Notwithstanding the price may be worth paying, isn't there overhead > > of TCP state even on p2p links? > > Yes, the overhead is bigger for multi-access though. There are two > types of state. > > TCP state: This would be on a per neighbor basis. So the amount of > state is based on how many neighbors there are. > > PIM state: When using PORT one needs to use explicit tracking. > Normally with PIM for a given (S,G) you only need to remember > that someone on the link has joined. But with PORT, for a > multi-access link, you need to remember exactly which neighbors. > > Perhaps I could alter this to say that there is a PIM state overhead > for multi-access links? Yes. s/control plane/PIM/ > > I appreciate you positioning this work as Experimental. This is > > consistent with the way that PIM has developed over the years, and fits > > with the type of extension you are defining. > > > > It would be really good if you could add a paragraph to the end of > > Section 1 that explains the experiment with some scope indicating at > > what point you might bring the work back to move it on to the Standards > > Track. You don't need make a big song and dance. I think that you can > > mention that the protocol extension operates between peers so, > > experimentation does not need to be constrained to walled gardens. > > I think experimental is appropriate, because PIM has always been a > soft-state protocol, so this is something completely new and untested. > So I can add this, and also the sentence you suggest > regarding no constraint regarding walled gardens. > > Perhaps I can add that it should be considered as a proposed standard > once there are experiences from multiple deployments in the field? > I don't want to require interoperability, but half expect that with > some deployment experience we may figure out some necessary improvements. That sounds about right. > > Sections 3.1 and 3.2 > > > > I am hugely suspicious of your determination of three reserved bits as > > Experimental. Less scrupulous people than yourselves use this sort of > > mechanism to end-run the standards process and achieve proprietary > > extensions. That is, they don't use them for experimentation at all :-( > > > > At this stage, you probably need to give a hint of the type of > > experiment that might be run with these bits. Otherwise it would be > > better to leave all of the bits unreserved. > > I don't have any concreate ideas at this stage. But if PORT gets > enhanced in the future, it might be good for showing additional > capabilities, which PORT enhancements are supported. So if a > vendor comes up with a possible PORT extension, and wants to do > an experiment, one of these bits can show that it is supported. > > The main purpose would be to allow testing out new features at a > small scale, for a limited time period, but not for more permanent > use. It's good to be able to experiment and know that it doesn't > conflict with possible future IANA assignments. Pretty much as > described in the referenced RFC 3692. I'm fully aware that it can be > abused though. But so can reserved bits be. > > I don't have a strong feeling regarding keeping them or not. I guess > we could check with the WG (anyone of you reading this? :) > > > If you do keep the bits as experimental, you must give some clues to > > non-participating routers about what they do if they see any of the bits > > set. Do they ignore the bits; do they ignore the message; do they reject > > the message with an error; or do they tear down the TCP connection? > > I agree, that would be needed. I'm a bit unsure how they should be > treated, as it depends a bit on what the potential use might be. Well, let's try keeping them. I half expect the IESG will push back, but who knows. How about saying that a receiver that sees one of these bits set must drop the message and may log an error? That also requires that these bits should be set to zero by non-participating routers. > > Section 4 > > > > When a Transport connection is established (or reestablished), the > > two routers MUST both send a full set of Join/Prune messages for > > state for which the other router is the upstream neighbor. > > > > I understand why. > > What is the risk that the amount of information that has to be sent is > > very considerably large? Is there a need for graceful restart? > > This is the current PIM behavior, PORT doesn't change this. For both > regular PIM and PIM with PORT, one could consider graceful restart > extensions. I have ideas regarding that, but at this point I'm not > sure if it should be PORT specific, and if we do, I think it is > better to leave it as a future extension. Hmmm. Well, it is different. Currently when a PIM router restarts it has to resynch as you describe. And that applies with or without PORT. But the draft describes what to do when a Transport connection is re-established. This could happen with the two routers both still up and running (perhaps there was a blip on the link that took down the TCP connection, but would have been handled seamlessly by the soft state part of the protocol). So GR becomes more important in the presence of reliable transport. Maybe you can simply flag the issue. People can look at this in a separate I-D and as part of the Experiment. > > Sections 5.1 and 5.2 > > > > I understand that the PORT messages are just simple wrappers, but I am > > surprised that you have designed a message format that is different from > > that used by regular PIM. Also that you have created a new registry for > > PORT messages rather than picking two values from the PIM message > > registry. Lastly, that you have not included "protocol version" > > One issue with using types from the existing PIM registry is that we > have very few unallocated types. Also, if a PORT message type would > only be used for PORT, I don't see why it makes sense to use the same > registry. I would say that PORT may have several different messages, > some of them may include a PIM message in the payload. It would be > just confusing to say that they are all PORT messages. OK > > Section 5.1 > > > > Is there a reason why a PORT message can only contain one PIM message? > > Ease of parsing. You might as well send a second PORT message. Note > that if you have two PIM J/P messages, you might also try to merge > them. Also if you have multiple PIM messages, what do you do if say > one has wrong checksum and not the other. Also, an implementation > would probably read an entire PORT message from TCP before processing. > If you have multiple PIM messages, you will wait unless > you've read all the data before you process the first message. I > guess this could be made to work though. OK. No problem. I was just curious. > > Section 5.1 > > > > The description of how to handle unrecognised PORT options is clear. It > > allows you to survive in the presence of experiments. It does not give > > you very graceful future-proofing in that you cannot have one router > > send an option it would like parsed by its peer, but does not care > > about, since the whole message will be skipped. OTOH, it does not allow > > a receiver to indicate that it has skipped the received message (and > > why). > > > > If this is a conscious choice, so be it. > > I think this is the best option. An alternative would be to have some > bits indicating how a peer should behave. Or have say two option > ranges, where you say that if you don't understand an option in one > range, then you just ignore that option but continue processing, > while if the option is in another range, then the entire message > should be ignored. > > I'm interested in your and the WG thoughts on this. I think you have captured the three possible behaviors: i) discard the message with the unknown option ii) ignore the unknown option and process the message iii) reject the message with the unknown option Within ii) there is: a) retain the option in messages forwarded/triggered b) purge the option in messages forwarded/triggered Many protocols do as you say: blend these behaviors depending on additional fields or sub-ranges (see LDP and RSVP for example). I have no strong views, but I would like you to have made the decision rather than allowed it to creep up. It is a hard decision to change once boxes are deployed. > > Section 5.2 > > > > Wouldn't it be nice to align the TLVs in the same way in both messages? > > Don't think worth doing that. OK. I must be anal ;-) > > Section 5.2 > > > > I think you should give some advice for the sender about the Holdtime. > > 1. Should it be configurable? > > 2. Is there a default? > > 3. How often should a KeepAlive be sent relative to the Holdtime if > > there are no other messages sent? > > I prefer leaving this open. An implementation can choose this freely, > and still have interoperability. Since we have reliability, a > keepalive need only be sent once within each holdtime. The main thing > is to send it well before the holdtime. I can add 1-2 sentences with > some considerations, but don't want to specify defaults. This can be > considered if we want to make it a standard, and we know better what > makes sense in different deployments. > > There are a lot of different opinions on what the best defaults are. Ah, good point. This is not a standard! In fact, just noting that this is an issue for experimentation should do the job. > I will need some time on this, and propose some improvements. There > are a few things above we probably need to discuss a bit further > though. > > Thanks for the detailed review. It has been through several > thorough reviews by people in the WG, but you found some issues > I think should be taken care of. And a few I'm not so sure about > as well... Oh well, sorry to add to the development time. I guess the market is not champing at the bit for an RFC :-) Let me know when you have a revision and we will take it to the next step. Cheers, Adrian From stig@venaas.com Thu Aug 11 14:41:58 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8A721F86AD for ; Thu, 11 Aug 2011 14:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 7GXmFlR0hM-b for ; Thu, 11 Aug 2011 14:41:57 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id BD3B521F8532 for ; Thu, 11 Aug 2011 14:41:57 -0700 (PDT) Received: from [10.33.12.82] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id E3B548050 for ; Thu, 11 Aug 2011 23:42:31 +0200 (CEST) Message-ID: <4E444CC4.70306@venaas.com> Date: Thu, 11 Aug 2011 14:42:28 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] pim minutes from Quebec X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 21:41:58 -0000 The minutes are now available at: http://www.ietf.org/proceedings/81/minutes/pim.txt Stig From stig@venaas.com Fri Aug 12 14:08:40 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9121F85C4 for ; Fri, 12 Aug 2011 14:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 70cSqL-P5lYZ for ; Fri, 12 Aug 2011 14:08:40 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id CBF1221F85C0 for ; Fri, 12 Aug 2011 14:08:39 -0700 (PDT) Received: from [10.33.12.82] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 8F81B7FE3; Fri, 12 Aug 2011 23:09:16 +0200 (CEST) Message-ID: <4E45967A.3000206@venaas.com> Date: Fri, 12 Aug 2011 14:09:14 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Mike McBride \(mmcbride\)" Subject: [pim] Adoption of draft-hou-pim-ecmp-01.txt as a pim wg doc X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 21:08:40 -0000 At the pim wg meeting in Quebec there was good support for adopting draft-hou-pim-ecmp-01.txt as a wg doc. There were 25 for adoption, none against. We would still like to check with you on the list though. If you are in favor or against adopting this draft, please send an email to the pim wg list with your opinion. Please do so by Friday August 26th. Note that you don't need to repeat your vote if you voted at the meeting. Any other comments you may have on the draft are of course also welcome. The draft is available at http://tools.ietf.org/html/draft-hou-pim-ecmp-01 Stig From asaeda@sfc.wide.ad.jp Mon Aug 15 18:59:42 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CDE21F8B94 for ; Mon, 15 Aug 2011 18:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.607 X-Spam-Level: X-Spam-Status: No, score=-97.607 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, 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 V5dwCtZqUCOm for ; Mon, 15 Aug 2011 18:59:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 499D121F87C5 for ; Mon, 15 Aug 2011 18:59:42 -0700 (PDT) Received: from localhost (Y060012.ppp.dion.ne.jp [219.108.60.12]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1BD86278148; Tue, 16 Aug 2011 10:59:58 +0900 (JST) Date: Tue, 16 Aug 2011 10:59:59 +0900 (JST) Message-Id: <20110816.105959.54940351.asaeda@sfc.wide.ad.jp> To: stig@venaas.com From: Hitoshi Asaeda In-Reply-To: <4E45967A.3000206@venaas.com> References: <4E45967A.3000206@venaas.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mmcbride@cisco.com, pim@ietf.org Subject: Re: [pim] Adoption of draft-hou-pim-ecmp-01.txt as a pim wg doc X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 01:59:42 -0000 Hi, I could not attend the last IETF, hence I'd tell I support draft-chown-mboned-multicast-filtering and draft-hou-pim-ecmp for adoption. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Mon Aug 15 19:10:10 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5991A21F8C40 for ; Mon, 15 Aug 2011 19:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.352 X-Spam-Level: X-Spam-Status: No, score=-98.352 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, 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 5OLdFUkTNmMA for ; Mon, 15 Aug 2011 19:10:09 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6D21F8C3A for ; Mon, 15 Aug 2011 19:10:09 -0700 (PDT) Received: from localhost (Y060012.ppp.dion.ne.jp [219.108.60.12]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 37D3B2780AA; Tue, 16 Aug 2011 11:10:06 +0900 (JST) Date: Tue, 16 Aug 2011 11:10:08 +0900 (JST) Message-Id: <20110816.111008.32534089.asaeda@sfc.wide.ad.jp> To: stig@venaas.com From: Hitoshi Asaeda In-Reply-To: <20110816.105959.54940351.asaeda@sfc.wide.ad.jp> References: <4E45967A.3000206@venaas.com> <20110816.105959.54940351.asaeda@sfc.wide.ad.jp> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mmcbride@cisco.com, pim@ietf.org Subject: Re: [pim] Adoption of draft-hou-pim-ecmp-01.txt as a pim wg doc X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 02:10:10 -0000 > draft-chown-mboned-multicast-filtering > and > draft-hou-pim-ecmp Oh, draft-chown-mboned-multicast-filtering is mboned document. Sorry for my mistake.:P Regards, -- Hitoshi Asaeda From internet-drafts@ietf.org Wed Aug 17 16:30:38 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4617721F8B03; Wed, 17 Aug 2011 16:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 1EXEi5sCzKqd; Wed, 17 Aug 2011 16:30:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D824D21F8AE1; Wed, 17 Aug 2011 16:30:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.58 Message-ID: <20110817233037.18543.13714.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2011 16:30:37 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-mtid-09.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 23:30:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : PIM Multi-Topology ID (MT-ID) Join Attribute Author(s) : Yiqun Cai Heidi Ou Filename : draft-ietf-pim-mtid-09.txt Pages : 14 Date : 2011-08-17 This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-mtid-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-mtid-09.txt From adrian@olddog.co.uk Fri Aug 19 04:46:02 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCD121F8AE9 for ; Fri, 19 Aug 2011 04:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 D+h6CgTfXcNv for ; Fri, 19 Aug 2011 04:46:01 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id CD5EB21F86EC for ; Fri, 19 Aug 2011 04:45:57 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7JBkruS005535; Fri, 19 Aug 2011 12:46:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p7JBkqKq005529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Aug 2011 12:46:52 +0100 From: "Adrian Farrel" To: Date: Fri, 19 Aug 2011 12:46:45 +0100 Message-ID: <03bb01cc5e65$b0521920$10f64b60$@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: AcxeZau5EAHRy2c8Qq6ukjIuBfUz6A== Content-Language: en-gb Cc: pim-chairs@tools.ietf.org Subject: [pim] Triage on Errata on RFC 3973 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 11:46:02 -0000 Hi, There are four errata on this RFC that I would like to clean up. You can see them at http://www.rfc-editor.org/errata_search.php?rfc=3973&rec_status=15&presentation= table Here are my proposed resolutions. Please let me know your opinions. Thanks, Adrian Erratum 967 I think this is really just an editorial problem. But I also think that it is correct and I will accept the erratum. Erratum 968 I think this is really just an editorial problem. But I also think that it is correct and that the parameter to be cut is the initial "0". I will accept the erratum. Erratum 969 I think this is really just an editorial problem. But I also think that it is correct and that the parameter to be cut is the initial "1". I will accept the erratum. Erratum 970 I think this is complaining about this RFC defining a bit that is outside the scope of this document. I can agree with that and note that you might have had trouble getting this past me had I been your AD at the time. However, the Erratum does not make any specific point or propose and resolution. I will reject the erratum. From prvs=2094e8155=Jonathan.Nicholas@itt.com Tue Aug 23 04:50:45 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9637D21F8515 for ; Tue, 23 Aug 2011 04:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 sWRknMWK3XeX for ; Tue, 23 Aug 2011 04:50:44 -0700 (PDT) Received: from cip-fwa-c2.itt.com (cip-fwa-c2.itt.com [151.190.252.22]) by ietfa.amsl.com (Postfix) with ESMTP id A234521F850E for ; Tue, 23 Aug 2011 04:50:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAANuTU04KHOwD/2dsb2JhbABBmEqQSYFAAQEBAQMBAQFrCwwEAgEIEQQBASgHJwsUCQgBAQQBDQUIh225NoVpXwSkLw X-IronPort-AV: E=Sophos;i="4.68,269,1312156800"; d="scan'208";a="106781006" Received: from usfwa1excas3.itt.net ([10.28.236.3]) by cip-fwa-c2.itt.com with ESMTP/TLS/AES128-SHA; 23 Aug 2011 11:51:13 +0000 Received: from usfwa1exmbx3.itt.net ([fe80::b9c6:1df5:8949:cb49]) by USFWA1EXCAS3.itt.net ([fe80::15c5:b97e:108a:5f2e%10]) with mapi; Tue, 23 Aug 2011 07:51:47 -0400 From: "Nicholas, Jonathan - ES" To: "adrian@olddog.co.uk" , "pim@ietf.org" Date: Tue, 23 Aug 2011 07:51:46 -0400 Thread-Topic: [pim] Triage on Errata on RFC 3973 Thread-Index: AcxeZau5EAHRy2c8Qq6ukjIuBfUz6ADJT8hw Message-ID: <6C565C0133EA3F478AEC8F5ADB52726A0ACDF4F352@USFWA1EXMBX3.itt.net> References: <03bb01cc5e65$b0521920$10f64b60$@olddog.co.uk> In-Reply-To: <03bb01cc5e65$b0521920$10f64b60$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim-chairs@tools.ietf.org" Subject: Re: [pim] Triage on Errata on RFC 3973 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:50:45 -0000 I agree with these resolutions. Jonathan Nicholas > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Adrian Farrel > Sent: Friday, August 19, 2011 7:47 AM > To: pim@ietf.org > Cc: pim-chairs@tools.ietf.org > Subject: [pim] Triage on Errata on RFC 3973 > > Hi, > > There are four errata on this RFC that I would like to clean up. You > can see > them at > http://www.rfc- > editor.org/errata_search.php?rfc=3D3973&rec_status=3D15&presentation=3D > table > > Here are my proposed resolutions. Please let me know your opinions. > > Thanks, > Adrian > > Erratum 967 > I think this is really just an editorial problem. > But I also think that it is correct and I will accept the erratum. > > Erratum 968 > I think this is really just an editorial problem. > But I also think that it is correct and that the parameter to be cut is > the > initial "0". > I will accept the erratum. > > Erratum 969 > I think this is really just an editorial problem. > But I also think that it is correct and that the parameter to be cut is > the > initial "1". > I will accept the erratum. > > Erratum 970 > I think this is complaining about this RFC defining a bit that is > outside the > scope of this document. I can agree with that and note that you might > have had > trouble getting this past me had I been your AD at the time. However, > the > Erratum does not make any specific point or propose and resolution. > I will reject the erratum. > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim This e-mail and any files transmitted with it may be proprietary and are in= tended solely for the use of the individual or entity to whom they are addr= essed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely = those of the author and do not necessarily represent those of ITT Corporati= on. The recipient should check this e-mail and any attachments for the pres= ence of viruses. ITT accepts no liability for any damage caused by any viru= s transmitted by this e-mail. From stig@venaas.com Mon Aug 29 10:44:02 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCC221F8A23 for ; Mon, 29 Aug 2011 10:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, 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 lFIc0eTgqqdn for ; Mon, 29 Aug 2011 10:44:02 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id EF39D21F88B7 for ; Mon, 29 Aug 2011 10:44:01 -0700 (PDT) Received: from [10.33.12.95] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 17F0F7FDC; Mon, 29 Aug 2011 19:45:24 +0200 (CEST) Message-ID: <4E5BD031.5080608@venaas.com> Date: Mon, 29 Aug 2011 10:45:21 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: "pim@ietf.org" References: <4E45967A.3000206@venaas.com> In-Reply-To: <4E45967A.3000206@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-hou-pim-ecmp@tools.ietf.org, "Mike McBride \(mmcbride\)" Subject: Re: [pim] Adoption of draft-hou-pim-ecmp-01.txt as a pim wg doc X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 17:44:02 -0000 On 8/12/2011 2:09 PM, Stig Venaas wrote: > At the pim wg meeting in Quebec there was good support for > adopting draft-hou-pim-ecmp-01.txt as a wg doc. There were > 25 for adoption, none against. We would still like to check > with you on the list though. > > If you are in favor or against adopting this draft, please > send an email to the pim wg list with your opinion. Please > do so by Friday August 26th. I have not seen any responses, but with the big support at the meeting it is clear that it should be adopted. Authors, please submit a new 00 draft as a WG document. Stig > Note that you don't need to repeat your vote if you voted > at the meeting. > > Any other comments you may have on the draft are of course > also welcome. > > The draft is available at > http://tools.ietf.org/html/draft-hou-pim-ecmp-01 > > Stig > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From iesg-secretary@ietf.org Mon Aug 29 10:52:38 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B8121F8BDC; Mon, 29 Aug 2011 10:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 z3SPozCGMWqY; Mon, 29 Aug 2011 10:52:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124DB21F8BF3; Mon, 29 Aug 2011 10:52:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110829175237.21218.38522.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2011 10:52:37 -0700 Cc: pim chair , pim mailing list , RFC Editor Subject: [pim] Protocol Action: 'An Interface ID Hello Option for PIM' to Proposed Standard (draft-ietf-pim-hello-intid-01.txt) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 17:52:38 -0000 The IESG has approved the following document: - 'An Interface ID Hello Option for PIM' (draft-ietf-pim-hello-intid-01.txt) as a Proposed Standard This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-hello-intid/ Technical Summary This document defines a new PIM Hello option to advertise an interface identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. Working Group Summary There is consensus within the PIM WG to publish the document. The participation has been with individuals from a variety of vendors and providers. The authors made minor changes based upon feedback during the wglc. Document Quality There exists at least one implementation of this protocol for which IANA early allocation was performed. Personnel Mike McBride is the Document Shepherd Adrian Farrel is the Responsible Area Director RFC Editor Note Section1 New final paragraph NEW All multi-byte integers in this specification are transmitted in network byte order (i.e. most-significant byte first). END Section 2 OLD The Interface Identifier option is used to identify which interface of a neighboring router a PIM Hello [RFC4601] is sent on. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. NEW The Interface Identifier option is used to identify through which interface of a neighboring router a PIM Hello [RFC4601] was sent. This allows PIM protocols to refer to, or identify, a particular interface on a neighboring router. END Section 2.1 OLD The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. Many systems make use of an ifIndex [RFC1213], which can be used as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may want to only optionally refer to an Interface using the Interface Identifier Hello option, and use the value of 0 to show that it is not referred to. Note that the value of 0 is not a valid ifIndex as defined in [RFC1213]. NEW The 32 bit Local Interface Identifier is selected such that it is unique among the router's PIM enabled interfaces. That is, there MUST NOT be two PIM interfaces with the same Local Interface Identifier. While an interface is up, the Identifier MUST always be the same once it has been allocated. If an interface goes down and comes up, the router SHOULD use the same Identifier. If a node goes down and comes up again. the Identifier for each interface MAY change. Many systems make use of an ifIndex [RFC2863] as a Local Interface Identifier. The Local Interface Identifier MUST be non-zero. The reason for this, is that some protocols may have messages that optionally reference an Interface Identifier, and they may use the value of 0 to show that no Interface Identifier is being referenced. Note that the value of 0 is not a valid ifIndex as defined in [RFC2863]. END Section 2.2 OLD The 32 bit Router Identifier may be used to uniquely identify the router. It may be selected to be unique within some administrative domain, or possibly globally unique. The requirements for the scope in which it needs to be unique depend on the protocol that utilizes this. A router implementation MAY choose an IPv4 unicast address assigned to the router as the Router Identifier, but MUST allow the identifier to be configured manually. Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other protocols making use of 32 bit identifiers for routers. One may use the same identifier to construct the Interface Identifier option, provided it meets the stability and uniqueness requirements of protocols making use of this option. NEW The 32 bit Router Identifier may be used to uniquely identify the router. The requirements for the scope in which the Router Identifier needs to be unique depend on the protocols that utilize it. It may need to be unique within some administrative domain, or it may possibly be globally unique. A router implementation selects a Router Identifier according to a configured policy that defines the uniqueness scope. Thus, an implementation MAY be configured to choose an IPv4 unicast address assigned to the router as the Router Identifier, but the implementation MUST allow the identifier to be configured manually. Protocols such as BGP [RFC4271] and OSPFv2 [RFC2328] are other protocols that make use of 32 bit identifiers for routers. Provided that the stability and uniqueness requirements of the protocols that make use of the Router Identifier are met, an implementation MAY use the same identifier as is used by other protocols. END Section 3 Definition of Router Identifier ADD The field MUST contain a valid Router Identifier or the value zero. END Section 7.2 OLD [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. NEW [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2863] McCloghrie, K. and Kastenholz, F., "The Interfaces Group MIB", RFC 2863, June 2000. END From internet-drafts@ietf.org Mon Aug 29 11:22:58 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ABE21F8CB4; Mon, 29 Aug 2011 11:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 DY+XNBf7ROLR; Mon, 29 Aug 2011 11:22:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F76421F8C77; Mon, 29 Aug 2011 11:22:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110829182252.1191.14524.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2011 11:22:52 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-port-08.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 18:22:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : A Reliable Transport Mechanism for PIM Author(s) : Dino Farinacci IJsbrand Wijnands Stig Venaas Maria Napierala Filename : draft-ietf-pim-port-08.txt Pages : 35 Date : 2011-08-29 This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-port-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-port-08.txt From stig@venaas.com Mon Aug 29 11:39:41 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0D821F8CC5 for ; Mon, 29 Aug 2011 11:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, 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 FGxa0MO8yR6p for ; Mon, 29 Aug 2011 11:39:40 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 243F421F8CC3 for ; Mon, 29 Aug 2011 11:39:40 -0700 (PDT) Received: from [10.33.12.95] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 98DD78041; Mon, 29 Aug 2011 20:41:02 +0200 (CEST) Message-ID: <4E5BDD3C.7090507@venaas.com> Date: Mon, 29 Aug 2011 11:41:00 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <022401cc52bf$f7901d70$e6b05850$@olddog.co.uk> <4E41B75B.4070308@venaas.com> <041001cc578a$4431a7b0$cc94f710$@olddog.co.uk> In-Reply-To: <041001cc578a$4431a7b0$cc94f710$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-port@tools.ietf.org, pim@ietf.org Subject: Re: [pim] AD Review of draft-ietf-pim-port X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 18:39:41 -0000 I have now submitted version 08 that I hope addresses all the issues. There are some protocol changes that I want you all to be aware of. Please have a look and let us know if you have any concerns. The new draft is at http://www.ietf.org/internet-drafts/draft-ietf-pim-port-08.txt A diff is available at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-port-08.txt See the diff for all changes. The main changes as I see them are below. Removed experimental bits from the defined PORT messages. If something is needed for an experiment, one can use an experimental option instead of a bit. A bit can be requested if the experiment results in the need for something more permanent. The number of PORT messages for experimental use has been reduced to 4. Split the PORT option space into two, as follows: Each PORT Option is a TLV. The type is 16 bits. The PORT Option type space is split in two ranges. The types in the range 0 - 32767 (the most significant bit is not set) are for Critical Options. The types in the range 32768 - 65535 (the most significant bit is set) are for Non-Critical Options. The behavior of a router receiving a message with an unknown PORT Option, is determined by whether the option is a critical option. If the message contains an unknown critical option, the entire message must be ignored. If the option is non-critical, only that particular option is ignored, and the message is processed as if the option was not present. This should allow us enough flexibility to be future proof. The options we have defined so far are Critical Options. I also reduced significantly the number of options for experimental use. I have now defined this: PORT Option types are assigned by IANA, except the ranges 32764 - 32767 and 65532 - 65535 that are for experimental use [RFC3692]. The IANA considerations were updated accordingly. A section on manageability added as requested. Comments welcome. Stig From internet-drafts@ietf.org Wed Aug 31 10:17:15 2011 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A228321F8D08; Wed, 31 Aug 2011 10:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 WUAG1y3fG7hd; Wed, 31 Aug 2011 10:17:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8B21F8D84; Wed, 31 Aug 2011 10:17:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110831171655.9503.85960.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2011 10:16:55 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-ecmp-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:17:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Workin= g Group of the IETF. Title : Protocol Independent Multicast ECMP Assert Author(s) : Yiqun Cai Liming Wei Heidi Ou Vishal Arya Sunil Jethwani Filename : draft-ietf-pim-ecmp-00.txt Pages : 11 Date : 2011-08-30 A PIM router uses RPF procedure to select an upstream interface and router to build forwarding state. When there are equal cost multiple paths (ECMP), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Assert, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP path selection to be based on administratively selected metrics, such as data transmission delays, path preferences and routing metrics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pim-ecmp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pim-ecmp-00.txt