Subject: Pim-SM Join Prune packet fromat

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 16 Sep 1999 13:41:49 -0400

I have few doubts on the format of Join/Prune packet. I would appreciate 
it if you could point me to right place in the spec or provide any
clarifications.

1. a) Could a given Join/Prune message contain information pertaining
      to more than one nbr?
   
   b) If yes, is it required that Join/Prunes for all the groups related 
      to a given nbr be at one place (i.e contiguous).

2. For a Join/Prune message sent to a nbr, is it required that all the
   Join/Prunes related to a given group be contiguous (or could the same
   group be repeated more than once in the same message).

Thanks.
- Ravi Shekhar.

---

From: Desikan Saravanan <[email-masked]>
Date: Thu, 16 Sep 1999 11:10:43 -0700

-----Original Message-----
From: Shekhar, Ravi [mailto:[email-masked]]
Sent: Thursday, September 16, 1999 10:42 AM
To: [email-masked]
Subject: Pim-SM Join Prune packet fromat

>> NO. I dont think the format specified in the spec allows it.

>> Though the spec doesnt say clearly about this, I would say dont do that.
It increases the packet size.

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 16 Sep 1999 14:18:37 -0400

> It increases the packet size. 

I agree. And I am not doing either of those two as far as generating
messages
are concerned. My concern is more from the receiving side.
I just want to make sure that I won't receive such a message
(especially the same nbr being mentioned multiple times in the packet) ...;)
 
- Ravi Shekhar.

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 16 Sep 1999 14:30:54 -0400

> >> NO. I dont think the format specified in the spec allows it.

Sorry, I missed that comment earlier. It seems like that from the
picture in the spec. Is it also mentioned somewhere?
It would be good to have it textually mentioned (to bar ones 
urge to reduce the number of messages generated on a subnet by 
including multiple nbrs).. ;)

Thanks.
- Ravi Shekhar.

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 16 Sep 1999 16:08:11 -0400

> You should not add random fields to these packets.  You can't repeat
> fields that don't say they can be repeated.  You should 
> properly handle IP
> packets received with IP options.  You should not pick your 
> own encoding
> of values instead of using the ones defined in the spec.
> 
> How are we going to think of all of the things that people are going
> to want to have specified?  I was told by one vendor that it was my

 Apologies if it sounded like that. My intentions werent those. Neither do I
 want, am insisting or expecting authors to specify all those unrelated
useless 
 things like dont include "junk" in the packet. 
     If you look at the picture in the spec, its only couple of vertical
dots
 which denote whether there are multiple such occurences of a field or not.
Or
 for that matter EncodedUnicastUpstreamNbrAddresses /
 [Reserved|NumGroups|HoldTime] seem to be all 4 byte aligned in the picture,

 but thats not true. Its very easy to misinterpret the picture. Putting some

 of it in words could possibly prevent that. Hope I havent made my point any
 more sore.

 - Ravi Shekhar.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 16 Sep 1999 13:20:30 -0700

Sorry for picking on you, Ravi.  "The picture is misleading" is a
perfectly valid complaint, and although I personally disagree that it's
hard to tell which fields are repeated and which aren't, I probably have
a somewhat skewed viewpoint having been reading that picture for 5 years
now =)  However, I definitely agree that it's a little misleading
to show any of the Encoded-*-Addresses in the same manner as 4-byte
quantities are normally represented.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 16 Sep 1999 12:36:49 -0700

>including multiple nbrs).. ;)

I'm sorry, but this feels to me like saying that RFC793 should say that
you can't include several TCP packets in a single IP packet.  I feel
like there's a trend towards requiring specification of everything that
you shouldn't do, or everything that should be implicit.  Should we add
a section like:

You should not add random fields to these packets.  You can't repeat
fields that don't say they can be repeated.  You should properly handle IP
packets received with IP options.  You should not pick your own encoding
of values instead of using the ones defined in the spec.

How are we going to think of all of the things that people are going
to want to have specified?  I was told by one vendor that it was my
fault that their mtrace implementation couldn't handle IP packets with
options, since the mtrace spec didn't mention IP options.  That concept
was unbelievable to me - it's IP, so it can have IP options, since those
are a part of IP.

Geez, this has turned into a rant; I guess this is a sore spot with me
=)  I'll stop now.

  Bill

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 16 Sep 1999 18:18:06 -0400

No problem.
No offense meant, but now that you pointed out the
multiple-TCP-segments-in-IP
over-specification, I ask this genuinely out of interest.

Are multiple Join/Prune messages allowed in a single IP packet?

  Multiple J/Ps in the same IP packet seem to be parse-able in its current
format as specified in the spec, unlike the TCP example where multiple TCP
segments in the same IP packet may not be parse-able as each TCP segemnt 
doesnt store its individual data legth and relies on IPs length field.
 
Also, it seems to be a logical thing to bundle Join/Prunes of multiple 
nbrs in the same IP packet as the packet is multicast to all the nbrs
and "already" required to be parsed by every nbr on the subnet to override
prunes.

In the worst case, a single sensible Join/Prune message could be carrying 
only 34 bytes of data with 20 or more bytes of IP header (~ 40% overhead). 

Regards.
  - Ravi Shekhar.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 16 Sep 1999 15:53:38 -0700

>Are multiple Join/Prune messages allowed in a single IP packet?

Not in the strict sense that a "Join/Prune" message includes the PIM
version, type, checksum, etc.

A Join/Prune message may include multiple groups and multiple joined or
pruned sources for each group.  There are no provisions for including
multiple neighbors and some definite compatability issues with extending
the message format to allow this.

  Bill

---

From: "Shekhar, Ravi" <[email-masked]>
Date: Thu, 16 Sep 1999 20:02:02 -0400

> version, type, checksum, etc.

 I meant even those fields are repeated. That is the whole of Join-Prune
 message structure that is defined in section 4.5 - Join/Prune message - 
 of the spec. (as opposed to just repeating the nbr info, which, as you 
 stated, has compatibility issues and is not allowed by the picture in the
 spec).

 At the risk of overclarifying, assume two such full structures (each one
 having its own Ver/Type/checksum etc.), back-to-back in the same IP packet.
 Since the end of each one is determinable without requiring any extra
field,
 they can be separated even if they are in the same IP packet.  

 - Ravi Shekhar.