Subject: [pim] Registry for PIM message types

From: Stig Venaas <[email-masked]>
Date: Wed, 18 Nov 2009 16:42:49 -0800

It turns out there is no registry for PIM message types. The only thing
we got is PIMv1 types as part of the IGMP registry.

There is an almost complete list of message types in the sparse mode and
dense mode RFCs, but none of them actually define a registry. This means
there is no IANA list of PIM message types, and there are no rules for
how to define new ones.

I've just submitted a very simple draft that defines such a registry,
see http://www.ietf.org/id/draft-venaas-pim-registry-00.txt

Below are the types it defines (have I missed any?).

It also says that IETF review is needed for new message types. That
means an RFC is needed and it must go through IETF last call (which
means that standards track RFCs are automatically qualified, but also
other RFCs if we do an IETF last call). Do you think that is too strict?

Message types in draft:

    Type   Name                          Reference
    ----  ----------------------------  ---------------------
      0    Hello                         [RFC3973] [RFC4601]
      1    Register                      [RFC4601]
      2    Register Stop                 [RFC4601]
      3    Join/Prune                    [RFC3973] [RFC4601]
      4    Bootstrap                     [RFC4601]
      5    Assert                        [RFC3973] [RFC4601]
      6    Graft                         [RFC3973]
      7    Graft-Ack                     [RFC3973]
      8    Candidate RP Advertisement    [RFC4601]
      9    State Refresh                 [RFC3973]
     10    DF Election                   [RFC5015]

Stig

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 18 Nov 2009 16:58:45 -0800

Preparing for next IETF 'spring cleaning' ? ;-) Nice draft.

I would probably reserve 'F' for a TBD RFC standardizing how to define
additional message types (by using the following 8 reserved bits, or however).
That way we would have 4 more types that could be assigned and we would also
not need to worry too much about running out of type codes and would likely
easier allocate the next 4 when needed.

Ok, so we have not been using up PIM mesage types up fast recently, but
PIM is now uhmm... about 16 years old, so you never know what happens when
teens get close to drinking age ;-)

Cheers
    Toerless

P.S.:

I for once would definitely like to see any form of mtracev2 to
use PIM rather than IGMP message type before standardizing it (that
would allow to make PIM the only protocol type of interest on transit
subnets and would simplify filtering).

On Wed, Nov 18, 2009 at 04:42:49PM -0800, Stig Venaas wrote:
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
"The strategy is what you do, not what you write" - Wesley Clark
"Vision without ressources is hallucination" - James L. Jones

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 19 Nov 2009 09:19:02 +0100 (CET)

Hi,

> subnets and would simplify filtering).

Answering for your P.S. part, the current mtracev2 does not use IGMP
but UDP.
http://tools.ietf.org/html/draft-ietf-mboned-mtrace-v2-05

Regards,
--
Hitoshi Asaeda

---

From: "Prashant Jhingran (pjhingra)" <[email-masked]>
Date: Thu, 19 Nov 2009 18:06:19 +0530

Hi Stig,

Perhaps there is not much room for comments :-) 

If appropriate you may add pointers like, recommended/MUST TTL values,
Destination & Source address (v4/v6) for respective mesg.
 
Regards,
Prashant Jhingran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stig Venaas
Sent: Thursday, November 19, 2009 6:13 AM
To: [email-masked]
Subject: [pim] Registry for PIM message types

Message types in draft:

    Type   Name                          Reference

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 19 Nov 2009 07:58:31 -0800

> Destination & Source address (v4/v6) for respective mesg.

This is only a registry. All it does is show which values are in use and
where they are defined. One should see the reference for the details.
This draft is really just a formality to get IANA to create the
registry. More important are the rules for creating new PIM types
though.

I think Toerless made a good point about reserving value 15 for
possible extensions though. We may not need it, but I think I
should add that in a new revision. Just saying

15   Reserved, may be used for extending the value space

Just so that we or someone remember in the future that this should
be considered. We may never have a need for it...

Stig