Re: BGMP WG Last Call: draft-ietf-bgmp-spec-03.txt to Experimental

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

=====================================================================

<DEL>

   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.



<DEL>

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.


<DEL>

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:

<EMAIL>
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).
</EMAIL>

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



<DEL>

            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.

<DEL>

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

<DEL>

Table of Contents


xp t


*** Something with the formatting went wrong here, because the table
*** of contents didn't appear :)


<END>