headers
Tom Pusateri | 1 Nov 2003 01:25
Favicon

Re: some comments to draft-ietf-pim-sm-v2-new-08.txt

In message <200310282247.h9SMl5jP009244 <at> sj-core-1.cisco.com> you write:
>
>>[clarifications]
>>2) Section 4.3.1 (p.30)
>>	"The Interface_Address_List Option SHOULD be included in all
>>	IPv4 Hello messages and MUST be included in all IPv6 Hello
>>	messages. This option advertises all the secondary addresses
>>	associated with the source interface of the router originating
>>	the message."
>>
>>Does it mean that it MUST advertise this option with option-len = 0,
>>even when there's no secondary IPv6 address on a link (i.e. only one
>>link-local address is assigned)?
>>
>>I don't think it's a necessary in such a case, so IMHO it would be
>>better to change this section like this.
>>
>>	The Interface_Address_List Option MUST be included in all
>>	Hello messages. This option advertises all the secondary
>>	addresses associated with the source interface of the router
>>	originating the message.  If there is no secondary address
>>	associated with the source interface, this option MAY be
>>	omitted.
>
>I will change the text in the spec to reflect your comment.

I was thinking it would be great to send the address list hello option
regardless so that it is possible to tell that your neighbors all support it.
This would make it easy to diagnose problems at the border between two
domains.
(Continue reading)

Permalink | Reply | 1 comment |
headers
SUZUKI Shinsuke | 4 Nov 2003 12:55
Picon

Re: some comments to draft-ietf-pim-sm-v2-new-08.txt

Hello,

>>>>> On Fri, 31 Oct 2003 16:25:26 -0800
>>>>> pusateri <at> juniper.net(Tom Pusateri)  said:

> >>	The Interface_Address_List Option MUST be included in all
> >>	Hello messages. This option advertises all the secondary
> >>	addresses associated with the source interface of the router
> >>	originating the message.  If there is no secondary address
> >>	associated with the source interface, this option MAY be
> >>	omitted.
> >
> >I will change the text in the spec to reflect your comment.
>

> I was thinking it would be great to send the address list hello
> option regardless so that it is possible to tell that your neighbors
> all support it.  This would make it easy to diagnose problems at the
> border between two domains.

When there is no secondary address on a link, it is not so useful in
debugging whether some neighbor supports this option or not, since
this option does not affect the protocol behavior in that case.

You can estimate if other vendors carefully read the latest spec from
the Hello message:-)   This may be a reason to always include this
option, but not a reason to mandate it to all PIM-SM implementations...

Am I understanding your intension correctly?
(Continue reading)

Permalink | Reply | 0 comments |
headers
shiroko.nr | 7 Nov 2003 10:09
Picon
Picon

Query regarding the fragmentation for Register message

Hello, 

I have a question regarding the fragmentation for PIM register 
messages defined in the draft draft-ietf-pim-sm-v2-new-08.txt 
Section 4.4.1. 

    If a multicast packet is fragmented on the way into the 
    Register Tunnel, each fragment is encapsulated individually so it 
    contains IP, PIM, and inner IP headers. 

    In IPv6, an ICMP Fragmentation Required message may be sent by the 
    encapsulating DR. 

My understanding is that inner multicast data would be fragmented 
before it is encapsulated with outer IP header and PIM header. 

I want to know the reason to go through the procedure mentioned above. 
Is it wrong procedure that fragmentation is done after a multicast 
packet is encapsulated with outer IP header and PIM header ? 

In IPv6, when an original multicast packet is smaller than 
IPv6 minimum MTU(1280bytes), DR cannot send PACKET_TOO_BIG to sender.  
And DR would have to fragment the packet when it is larger than the 
Path-MTU toward the RP. 
At that time, If original packet was fragmented by the sender, 
DR cannot fragment it anymore, I think. 

Please let me know if I am making any mistake.  

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stig Venaas | 11 Nov 2003 20:29
Picon
Picon

Volunteer for BSR spec

I've been told that you're looking for a volunteer to work on the
spec. I'm unfortunately not at the pim wg meeting.

I would be interested in this. I've been doing some work in this
area and are not quite happy with current spec. I would like to
see spec be improved and moved forward.

Since I'm not at the meeting, I'm not quite sure what you expect
from a volunteer though...

Stig
Permalink | Reply | 0 comments |
headers
Tom Pusateri | 12 Nov 2003 00:37
Favicon

Re: Volunteer for BSR spec

Thanks, we're organizing this work now and we'll definitely get back
to you real soon now on what this would involve.

Thanks,
Tom

In message <20031111192924.GA15859 <at> sverresborg.uninett.no> you write:
>I've been told that you're looking for a volunteer to work on the
>spec. I'm unfortunately not at the pim wg meeting.
>
>I would be interested in this. I've been doing some work in this
>area and are not quite happy with current spec. I would like to
>see spec be improved and moved forward.
>
>Since I'm not at the meeting, I'm not quite sure what you expect
>from a volunteer though...
>
>Stig
>
>
>_______________________________________________
>pim mailing list
>pim <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/pim
Permalink | Reply | 0 comments |
headers
Bill Fenner | 12 Nov 2003 01:01
Picon

Re: Query regarding the fragmentation for Register message


Shiroko,

  You are right; if the MTU of the DR->RP path is 1280 then the DR
may not send an ICMP fragmentation required error.  The idea behind
having the fragmentation occur inside the tunnel is to prevent
the RP from being overloaded with reassembly load.

  One possible way to handle this is that if the DR->RP path MTU is
1288 or less then use fragmentation on the outer packet.  This leaves
the overhead on the end systems if possible and only moves it to the
RP when necessary.  However, it's a little obscure and possibly
confusing.  Anyone have any thoughts on this?

Thanks,
  Bill
Permalink | Reply | 0 comments |
headers
Tom Pusateri | 17 Nov 2003 17:29
Favicon

WG Last Call - PIM Sparse Mode

Today begins a Working Group Last Call for the PIM Sparse Mode Protocol
Specification. The last call runs 2 weeks from Monday, November 17th, 2003
to Monday, December 1st, 2003.

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

If you have previously volunteered as a reviewer for this spec, please
submit your review comments by the end of the Last Call period.

The document can be found at
http://ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-08.txt

Thanks,
Tom & Liming
Permalink | Reply | 0 comments |
headers
srinivas | 19 Nov 2003 12:50
Favicon

Doubt regarding BSR & Bootstrap messages

Hi all,

 Here is my Setup:-

R1<-------->R2
^
|
|
V
R3

In the above setup,
Enable PIM over all interfaces in R1, R2 & R3.
Enable BSR using Interface address in R1, say x.x.x.x, which is 
connected to R2. 
Let the R1 get elected as BSR using x.x.x.x.
Now bring the interface correspnding to x.x.x.x down.
you can note that BSMs are sent to R3 from R1.
But in R3, the BSMs get rejected since there is no route to 
x.x.x.x.

So, is it valid to send out Bootstrap Messages even when the 
corresponding interface is down?
What is the use if at all we are sending it?

Now considering the above scenario, R1 is "Elected" BSR even 
though all its BSMs are getting rejected.
R2 & R3 will not have BSR info. So, it is improper to display R1 
as "Elected" whereas none of the neighboring
routers know about the BSR.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bharat_joshi | 19 Nov 2003 19:33
Favicon

RE: Doubt regarding BSR & Bootstrap messages

 
 Here is my Setup:-
  
R1<-------->R2
^
|
|
V
R3

In the above setup,
Enable PIM over all interfaces in R1, R2 & R3.
Enable BSR using Interface address in R1, say x.x.x.x, which is
connected to R2.
Let the R1 get elected as BSR using x.x.x.x.
Now bring the interface correspnding to x.x.x.x down.
you can note that BSMs are sent to R3 from R1.
But in R3, the BSMs get rejected since there is no route to
x.x.x.x.

So, is it valid to send out Bootstrap Messages even when the
corresponding interface is down?
What is the use if at all we are sending it?

>>> >>>
Bharat:
 
Could you please explain why a swicth/router will keep sending
BSMs even if its interface is down.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Internet-Drafts | 19 Nov 2003 21:28
Picon
Favicon

I-D ACTION:draft-ietf-pim-anycast-rp-00.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
	Filename	: draft-ietf-pim-anycast-rp-00.txt
	Pages		: 7
	Date		: 2003-11-19
	
This proposal allows Anycast-RP to be used inside a domain which runs
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-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-00.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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane