Subject: RE: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.txt

From: "bharat_joshi" <[email-masked]>
Date: Thu, 9 Feb 2006 21:11:49 +0530

Hi All,

    This is the first time I am reviewing this draft and I have
following questions: [There might be some question which has already
been discussed so if something have been decided, please let me know]

In "Overview" section:
* In statement, "The RP address, or a prefix that covers the RP address,
is injected", I think RP address we are referring to is Anycast RP
address. Right? Can we make it explicit?

* Also the injection of unicast route is supposed to be done in all RPs
in the Anycast RP set. Right? Can we add this here?

In "Mechanism" section:
* Can we change "now" in statement "If RP2 decides not to wait, the
Register-Stop is sent now" to "immediately".

* In point "RP3 creates (S1,G) state so when a receiver joins after S1
starts sending, RP3 can join quickly to the source-tree for S1", does
this mean that the multicast traffic for "G" will flow till RP3 even
when there are no listeners. Is it correct? Why would we want to do
that?

In "Observations and Guidelines about this Proposal" section:
* In the first point, its mentioned that TTL must be copied from
register message received to what the router generates towards other RPs
in Anycast RP set. Should not we decrement the TTL before copying it?
This is how it should have happened in Unicast Routing of Register
message.

* Can we add an advantage by suppressing "Register NULL" messages?

In section 5.1:
* In paragraph 4, it's mentioned that "if a data register or NULL
register was received from either a DR or another Anycast-RP. That is,
they would send Registers to the other members of the Anycast-RP set." I
think this will be done when the Data or NULL register is not not
received from a RP in the Anycast RPset. Am I correct?

* In paragraph 5, It's mentioned that "Register messages are sent only
to those members who does not have MSDP peering". So is there a way to
find out if a RP in Anycast RPSet has MSDP peering or not?

* Will the Group-RP-Mapping of a group to an Anycast RP address is
achieved by static, BSR mechanism etc?

Thanks & Regards,
Bharat

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, February 07, 2006 2:20 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [pim] I-D ACTION:draft-ietf-pim-anycast-rp-06.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-06.txt
> 	Pages		: 12
> 	Date		: 2006-2-6
>
> This specification allows Anycast-RP (Rendezvous Point) to be used
>    inside a domain that 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-06.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] 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-06.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pim-anycast-rp-06.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 10 Feb 2006 00:19:32 -0800

>> address. Right? Can we make it explicit?

    Yes.

>> in the Anycast RP set. Right? Can we add this here?

    That is implicit or else there would be no reachability to the RP.

>> Register-Stop is sent now" to "immediately".

    I think it's too late to make changes. Last call has past.

>> when there are no listeners. Is it correct? Why would we want to do

    No it doesn't. when the Regiser is received and there is no (*,G) state,
    or there is (*,G) state with an empty oif-list, a Join is *not* sent
    towards S1.
   
>> This is how it should have happened in Unicast Routing of Register

    Yes, it is assumed to be decrmented in the IP layer when it was received.

>> * Can we add an advantage by suppressing "Register NULL" messages?

    This was suggested before. We decided to not do this.

>> received from a RP in the Anycast RPset. Am I correct?

    What the paragraph and the one before it is saying if if all anycast RPs
    do not have external MSDP peering connections, then the ones that don't
    will get packets via a Register from the ones that do have extenral 
    MSDP peering connections. This needs to be configured before if there is
    more than one, you don't want duplicate packets to go to all anycast-RPs
    (the ones without the MSDP peerings).

>> find out if a RP in Anycast RPSet has MSDP peering or not?

    Well, you could if there were active sources in the domain. That is, the
    source that registers to one RP, which would send an SA for, would be  
    seen by the other RP, from it's external MSDP peering. It would see that
    the SA came from it's own AS.

>> achieved by static, BSR mechanism etc?

    Any of static, BSR, or Auto-RP.

Thanks for you comments,
Dino

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 10 Feb 2006 14:21:02 +0530

Hi Dino,

   Thanks for your response.

   I am really sorry that I did not get time to review it before the
last call. Anyway If you feel that the changes suggested below will help
in improving the readability of the document than you can do it.

   Please see my answers in line.

Thanks & Regards,
Bharat

> >> address. Right? Can we make it explicit?

So would you want to make it explicit? This will help reader and
reviewer of this document.

>     That is implicit or else there would be no reachability to the RP.

Ok.

>     I think it's too late to make changes. Last call has past.

But if it make things easier, I think it should be done. Anyway its your
call.

>     or there is (*,G) state with an empty oif-list, a Join is *not* sent

Ok.

>     Yes, it is assumed to be decrmented in the IP layer when it was received.

I think we should make it more explicit in the document.

>     This was suggested before. We decided to not do this.

Was there any specific reason for not to do this?

>     (the ones without the MSDP peerings).

You mean to say that this information [whether a RP have external MSDP
peering] needs to be configured statically on each RPs in the Anycast RP
set. If yes, can we add this information to the document?

>     the SA came from it's own AS.

As you mentioned above, this information can be configured on the RPs?

>     Any of static, BSR, or Auto-RP.

Can we add this as well to the document?