headers
Mike McBride | 2 Jun 2004 08:47
Picon
Favicon

WG Last Call - draft-ietf-pim-anycast-rp-01

Today begins a Working Group Last Call for the Anycast-RP using PIM draft.
The Last Call runs 2 weeks from Wednesday, June 2nd, 2004 to Wednesday,
June 16, 2004.

Please review this document and send comments either to the list or
directly to the authors.

The document can be found here:

http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-01.txt

thanks,
Tom and Mike
Permalink | Reply | 1 comment |
headers
Pekka Savola | 2 Jun 2004 12:31
Picon

Re: WG Last Call - draft-ietf-pim-anycast-rp-01

On Tue, 1 Jun 2004, Mike McBride wrote:
> Today begins a Working Group Last Call for the Anycast-RP using PIM draft.
> The Last Call runs 2 weeks from Wednesday, June 2nd, 2004 to Wednesday,
> June 16, 2004.
> 
> Please review this document and send comments either to the list or
> directly to the authors.
> 
> The document can be found here:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-01.txt

And the aimed category is...?  Proposed Standard?

In any case, here are a few comments on the draft.  The approach seems
straightforward, even though slightly underspecified, relying on the
implementations just "getting it right".

substantial
-----------

==> this doc is missing a security considerations section.  It must be
added.

...

   o RP2 receives the Register message from RP1, decapsulates it, and
     also sends the packet down the shared-tree to get the packet to
     receiver R2.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dino Farinacci | 9 Jun 2004 04:08

Re: WG Last Call - draft-ietf-pim-anycast-rp-01

    Pekka, et al, my responses inline. I have updated the draft and will 
    release a copy after the last call date (June 16th) so I can aggregate
    changes into the -02 draft.

>> And the aimed category is...?  Proposed Standard?

    I believe PS, but the coauthors should give final say.

>> ==> this doc is missing a security considerations section.  It must be
>> added.

    We added one.

>> ==> This seems to change the model slightly: register-stops are also
>> sent back to the anycast-RPs (not just DRs), which have to be capable
>> of processing them (of course, they are indistinguishable to the RPs).  
>> This spec doesn't mention RP1's processing of a received register-stop
>> at all, or what kind of state RP1 needs to maintain for the register
>> messages it forwards to the other RPs.  This should probably be added.

    I have added text to indicate a Anycast-PIM RP should process Register-
    Stop messages like it would acting as a DR.

>> ==> the draft uses RFC2119 keywords but doesn't define or refer to them. 
>> Add the regular paragraph at the end of section 1 ?
>> 
>> ==> there are a couple of lines longer than 72 chars/line, which is
>> forbidden.
>> 
>> ==> it also seems to be good practice to insert a dummy IANA considerations
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dino Farinacci | 18 Jun 2004 07:43

[mmcbride <at> cisco.com: WG Last Call - draft-ietf-pim-anycast-rp-01]

    We have hit the last-call deadline. I received only one set of comments
    from Pekka. I responded to his email and the enclosed updated draft is
    ready. I will wait one day to repost in the ID directory as the -02
    revision.

Thanks,
Dino

-------------------------------------------------------------------------------

------- Start of forwarded message -------
X-BrightmailFiltered: true
Date: Tue, 1 Jun 2004 23:47:14 -0700 (PDT)
From: Mike McBride <mmcbride <at> cisco.com>
To: pim <at> ietf.org
Subject: [pim] WG Last Call - draft-ietf-pim-anycast-rp-01
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
X-BeenThere: pim <at> ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pim>,
	<mailto:pim-request <at> ietf.org?subject=unsubscribe>
List-Post: <mailto:pim <at> ietf.org>
List-Help: <mailto:pim-request <at> ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pim>,
	<mailto:pim-request <at> ietf.org?subject=subscribe>
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Lingard | 21 Jun 2004 18:19
Favicon

Comments on draft-ietf-pim-sm-bsr-03.txt

Hi,

I have the following comments on the last version of the BSR draft.  I don't
know at what stage of production the next version of the draft is, but I
hope that at least some of my suggestions will be able to make their way
into it.

Since there are rather a lot of comments, I've grouped them into four
categories:

- Major comments
- Other substantial comments
- Editorial comments
- Minor editorial comments (typos, etc.)

If anything is unclear, or if you require any further clarifications, please
let me know.

Thanks,
James.

==========================================================================
Major Comments (in rough order of importance)
==========================================================================

Semantic fragmentation
----------------------

1) The document needs to distinguish more clearly between a single PIM
   control packet of type 4, and the collection of such packets from the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 22 Jun 2004 21:58
Picon
Favicon

I-D ACTION:draft-ietf-pim-anycast-rp-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol Independent Multicast Working Group of the IETF.

	Title		: Anycast-RP using PIM
	Author(s)	: D. Farinacci, Y. Cai
	Filename	: draft-ietf-pim-anycast-rp-02.txt
	Pages		: 9
	Date		: 2004-6-22
	
This specification allows Anycast-RP (Rendezvous Point) to be used
   inside a domain, which runs Protocol Independent Multicast (PIM)
   only. There are no other multicast protocols required to support
   Anycast-RP, such as MSDP, which has been used traditionally to solve
   this problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pim-anycast-rp-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pim-anycast-rp-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Schwendimann | 17 Jun 2004 18:35

Unknown Pim Hello options

Hello,
	I have read the pim spec but cannot find out what a router should do
with an unknown pim hello option.  The spec says I may ignore the
option.  Does that mean the routers should become neighbors or ignore
each others hello messages?

Thanks
Greg
Permalink | Reply | 1 comment |
headers
Tom Pusateri | 23 Jun 2004 21:12
Favicon

Re: Unknown Pim Hello options

I would log the option and then ignore it.
You should still treat the sender as a neighbor.

Tom

In message <1087490128.998.3.camel <at> palm> you write:
>Hello,
>	I have read the pim spec but cannot find out what a router should do
>with an unknown pim hello option.  The spec says I may ignore the
>option.  Does that mean the routers should become neighbors or ignore
>each others hello messages?
>
>
>Thanks
>Greg
>
>
>_______________________________________________
>pim mailing list
>pim <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/pim
Permalink | Reply | 0 comments |
headers
Pavlin Radoslavov | 24 Jun 2004 02:29

Re: Unknown Pim Hello options

> 	I have read the pim spec but cannot find out what a router should do
> with an unknown pim hello option.  The spec says I may ignore the
> option.  Does that mean the routers should become neighbors or ignore
> each others hello messages?

I believe the answer is that if one of the routers includes a Hello
option that the other router(s) don't understand, but the rest of
the message is fine (e.g., it contains the HoldTime option, etc),
then the routers still should become neighbors.

If you have several PIM routers on a LAN and some of them ignore
each other's Hello messages, bad things can happen. E.g., the PIM
Assert messages will be rejected with all negative result of that
(duplicate traffic, etc).

Indeed, the spec doesn't say explicitly that the routers still
should be neighbors, so I'd be interested to know if other people
have different interpretations.

Pavlin
Permalink | Reply | 2 comments |
headers
Christopher Thomas Brown | 24 Jun 2004 17:16

Re: Unknown Pim Hello options

On Thu, 17 Jun 2004 12:35:29 EDT
Greg Schwendimann wrote:
>Hello,
>	I have read the pim spec but cannot find out what a router should do
>with an unknown pim hello option.  The spec says I may ignore the
>option.  Does that mean the routers should become neighbors or ignore
>each others hello messages?

It means the option may be ignored. If an implementation does ignore
such options then yes they would become neighbors. If an implementation
does not ignore such options then it depends on what it does do (eg
drop or log or ???).

Chris
Permalink | Reply | 0 comments |

Gmane