From 558-mailing-list-admin@catarina.usc.edu Tue Oct 1 08:14:32 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11184 for ; Tue, 1 Oct 2002 08:14:32 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g91CDqb84978 for ; Tue, 1 Oct 2002 05:13:52 -0700 (PDT) (envelope-from 558-mailing-list-admin@catarina.usc.edu) Date: Tue, 1 Oct 2002 05:13:52 -0700 (PDT) Message-Id: <200210011213.g91CDqb84978@catarina.usc.edu> Subject: catarina.usc.edu mailing list memberships reminder From: mailman-owner@catarina.usc.edu To: bgmp-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: 558-mailing-list-admin@catarina.usc.edu Errors-To: 558-mailing-list-admin@catarina.usc.edu X-BeenThere: 558-mailing-list@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your catarina.usc.edu mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, bgmp-request@catarina.usc.edu) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@catarina.usc.edu. Thanks! Passwords for bgmp-archive@lists.ietf.org: List Password // URL ---- -------- bgmp@catarina.usc.edu opipeg http://catarina.usc.edu/mailman/options/bgmp/bgmp-archive%40lists.ietf.org From bgmp-admin@catarina.usc.edu Thu Oct 10 20:20:47 2002 Received: from catarina.usc.edu (catarina.usc.edu [204.57.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27319 for ; Thu, 10 Oct 2002 20:20:46 -0400 (EDT) Received: from catarina.usc.edu (localhost.localdomain [127.0.0.1]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g9B0F4b55147; Thu, 10 Oct 2002 17:15:04 -0700 (PDT) (envelope-from bgmp-admin@catarina.usc.edu) Received: from possum.icir.org (possum.icir.org [192.150.187.67]) by catarina.usc.edu (8.11.6/8.11.6) with ESMTP id g9B0Etb55132 for ; Thu, 10 Oct 2002 17:14:55 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Received: from possum.icir.org (localhost [127.0.0.1]) by possum.icir.org (8.12.3/8.11.3) with ESMTP id g9B0IPoo073844; Thu, 10 Oct 2002 17:18:25 -0700 (PDT) (envelope-from pavlin@possum.icir.org) Message-Id: <200210110018.g9B0IPoo073844@possum.icir.org> To: Bill Fenner cc: bgmp@catarina.usc.edu Subject: Re: [bgmp] BGMP WG Last Call: draft-ietf-bgmp-spec-03.txt to Experimental In-Reply-To: Message from Bill Fenner of "Tue, 10 Sep 2002 11:32:22 PDT." <200209101832.LAA00664@windsor.research.att.com> From: Pavlin Radoslavov Sender: bgmp-admin@catarina.usc.edu Errors-To: bgmp-admin@catarina.usc.edu X-BeenThere: bgmp@catarina.usc.edu X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 10 Oct 2002 17:18:25 -0700 > > Dear BGMP WG, > > This is the long-delayed BGMP Working Group Last Call for the BGMP > Specification to be published as Experimental. Please review the draft > and send any comments to the working group, by September 25, 2002. > > Thanks, > Bill > > Title : Border Gateway Multicast Protocol (BGMP): Protocol > Specification > Author(s) : D. Thaler > Filename : draft-ietf-bgmp-spec-03.txt > Pages : 44 > Date : 22-Jul-02 Below are some (non-technical) comments I have (they are prefixed with ***). I know those comments are after the deadline, but I hope it is still not too late. Otherwise they would have to wait when it is time for the Experimental RFC to become a Proposed Standard :) Thanks, Pavlin ===================================================================== For non-source-specific groups, BGMP assumes that ranges of the class D space have been associated (e.g., with Unicast-Prefix-Based Multicast [V4PREFIX,V6PREFIX] addressing) with selected domains. *** "class D space" -> "multicast address space", because the term *** "Class D" is IPv4-specific. 6.3.2. Receiving Prune Notifications When the BGMP component receives a (*,G) or (S,G) Prune alert from another component, or a BGMP (*,G) or (S,G) Prune message from an external peer, it searches the tree state table for a matching entry. If no (S,G) entry was found for an (S,G) Prune, but (*,G) state exists, an (S,G) entry is created, with the target list copied from the (*,G) entry. If no matching entry exists, or if the component or peer is not listed in the target list, no further actions are taken. Otherwise, the component or peer is removed from the target list. If the target list becomes null as a result, the next-hop peer towards the nominal root of G (for a (*,G) entry), or towards S (for an (S,G) entry if and only if the BGMP router does NOT have any corresponding (*,G) entry), must be notified as follows. *** When (S,G) Prune received, and no (S,G) entry was found, then *** the target list is copied from the (*,G) entry to the newly *** created (S,G) entry. My understanding is that the component or *** peer should be removed from the newly created target *** list of that (S,G) entry. However, the way the above two *** paragraphs are written, it is ambiguous what the "Otherwise" in *** the beginning of the second paragraph refers to. If it refers to *** the last sentence in the paragraph above it, then there shoudn't *** be a paragraph split. 6.6. Interaction between (S,G) state and G-routes As discussed earlier, routers with (*,G) state will not propagate (S,G) joins. However, a special case occurs when (S,G) state coincides with the G-route (or route towards the nominal root of G). When this occurs, care must be taken so that the data will reach the root domain without causing duplicates or black holes. For this reason, (S,G) state on the path between the source and the root domain is annotated as being "poison-reversed". A PR-bit is kept for this purpose, which is updated by (UN)POISON_REVERSE messages. *** I had completely forgot the purpose of the PR-bit, but after *** reading the whole text so far, AND after reading several times *** the above section, the exact purpose of the PR-bit and the *** problem it solves were still unclear for me. Only after I read *** Dave Thaler's email from Apr 17 2001 *** (http://netweb.usc.edu/bgmp/mail-archive/bgmp.200104), it became *** much clear what the problem and the high-level solutions are: Its [the PR-bit] basic purpose is to indicate to BGMP nodes whether they need to forward packets up towards the root domain. For example, in a case where an (S,G) branch exists, a transit domain may get packets along the (S,G) branch, and needs to know whether to (also) forward them up towards the root domain. If the domain in question is on the path between S and the root domain, then the answer is yes (and the PR bit will be set on the S,G state). If the domain in question is not on the path between S and the root domain, then the answer is no (and the PR bit will be clear on the S,G state). *** IMO, the email text is much clearer than the draft text. Hence, *** is it possible rewrite the text in Section 6.6 to something *** similar to the email text that is easier to understand. Also, a *** number of people in the past have asked about specific examples *** re. the PR-bit, and Dave's response was that he has Powerpoint *** slides with that, but so far I didn't see an URL. Dave, can you *** send me a Postscript or PDF version of those slides, which I can *** put on the BGMP web page. Then, in Section 6.6 (or some *** Appendix) you may eventually mention that URL for people who *** want to understand better the problem. Message Header Error subcodes: Expires December 2002 [Page 30] Draft BGMP June 2002 2 - Bad Message Length (MC) 3 - Bad Message Type (MC) OPEN Message Error subcodes: 1 - Unsupported Version (MC) 4 - Unsupported Optional Parameter 5 - Authentication Failure (MC) 6 - Unacceptable Hold Time (MC) 7 - Unsupported Capability (MC) UPDATE Message Error subcodes: 1 - Malformed Attribute List (MC) 2 - Unrecognized Attribute Type 5 - Attribute Length Error (MC) 10 - Invalid Address 11 - Invalid Mask 13 - Unrecognized Address Family *** It seems that the above text is mis-formatted: each "(MC)" *** appears in the beginning of a separate line, but the intention *** probably was to be at the end of the line above it. [V4PREFIX] D. Thaler, "Unicast-Prefix-based IPv4 Multicast Addresses", draft- thaler-ipv4-uni-based-mcast-00.txt, Work in progress, November 2001. *** This I-D has expired [V6PREFIX] Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", draft-ietf-ipngwg-uni-based-mcast-03.txt, Work in progress, October 2001. *** This now is RFC 3306 [MBGP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998. *** RFC 2283 is obsoleted by RFC 2858 [CBT] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing", RFC 2189, September 1997. [DWR] Fenner, W., "Domain-Wide Reports", draft-ietf-idmr-membership- reports-04.txt, Work in progress, August 1999. *** This I-D has expired [PIMSM] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. *** Shoudn't this reference be draft-ietf-pim-sm-v2-new-05.txt instead? Table of Contents xp t *** Something with the formatting went wrong here, because the table *** of contents didn't appear :) _______________________________________________ bgmp mailing list bgmp@catarina.usc.edu http://catarina.usc.edu/mailman/listinfo/bgmp