Subject: [pim] What is the value of 'infinity'

From: John Zwiebel <[email-masked]>
Date: Tue, 18 Apr 2006 13:27:48 -0700

It may seem like a silly question, but I've found some interop
problems for bidir DF-elections where some have selected 'infinity'
to be 0x7fffffff and some have selected it to be 0xffffffff.

Given the info below, what is "infinity"?

The PIM RFCs (2117 and 2362) have the following statements -

   3.5.1 Sending Asserts
      ...
      If route is not found, use metric preference of 0x7fffffff
      and metric 0xffffffff.

the new PIM sparse-mode spec says:

   assert_metric
     infinite_assert_metric() {
     return {1,infinity,infinity,0}
   }

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

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Tue, 18 Apr 2006 16:59:08 -0400

>     return {1,infinity,infinity,0}

In PIM-SM the infinity value for metric preference is 31-bit so its
0x7fffffff. Since the BiDir specification makes reference to the PIM-SM
specification on comparison, I'd say that implies it should be a 31-bit
value.  If left to stand as is, I think this will continue cause confusion.
Perhaps, the BiDir authors should clarify this in the BiDir spec.

Chris

---

From: John Zwiebel <[email-masked]>
Date: Tue, 18 Apr 2006 14:21:04 -0700

On Apr 18, 2006, at 1:59 PM, Christopher Thomas Brown wrote:

> 0x7fffffff.

Only in the old spec which is replaced by the new which doesn't say.

And since the old spec doesn't give a clue as to why 31 bits vs 32
or even vs only 8, I'm looking for a concensus to make the pronouncement
"official".

FWIW: I believe that in most cases its isn't going to matter.
And in the bidir interop problem I found, there are some fairly
obvious work-arounds.  But in the end, it would be better if
we all agreed.

When the new PIM-SM replaces 2362, it is kind of harsh to expect
new implementations to comply with an obsolete spec.

---

From: John Zwiebel <[email-masked]>
Date: Tue, 18 Apr 2006 14:35:03 -0700

Aha, 'scuse me for being so dumb.
This is from the new spec...

4.9.6. AssertMessage Format

0 1 2 3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  | Reserved    |       Checksum                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Group Address (Encoded-Group format)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Address (Encoded-Unicast format)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|             Metric Preference                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Metric                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: John Zwiebel <[email-masked]>
Date: Tue, 18 Apr 2006 14:45:58 -0700

But last thing on this:

In the bidir spec, the DF-election packet formats don't have an R-bit
So infinity there would be 32-bits of 1.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver|  Type |Subtype|  Rsvd |       Checksum                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Encoded-Unicast-RP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|                 Sender Metric Preference                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sender Metric                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Tue, 18 Apr 2006 17:56:27 -0400

> Only in the old spec which is replaced by the new which doesn't say.

There is only 31-bits in the preference field in the assert message.
The 32cd bit is the RPT bit. So preference is a 31-bit value.
Look at the preference field in the assert message in the PIM-SM
specification.

> or even vs only 8, I'm looking for a concensus to make the pronouncement

This is conjecture on my part. Some routing protocols can have large
metrics. ISIS, for example, has extended metrics that can be up to 29 or
so bits. I don't know of the timing between when that was added to ISIS
and the PIM assert message was designed. Perhaps it was forward looking
or it was known.

So, with the metric field being 32-bits it makes sense to add another
32-bits to the message size to preserve 32-bit alignment. One bit was
used for the RPT bit. That leaves 31-bits for preference. As to why 31
over 16 or 8, perhaps because some routing implementations have
preferences that are that large.

> new implementations to comply with an obsolete spec.

I think PIM-SM is mostly clear although I think it would have been
better if the spec spelled out the actual value of inifinity for both
metric and preference instead of relying on implication from the size of
the fields in the assert message.

I'm not a fan of a spec just waving its hands and say look here.
Especially for something that is just a paragraph or two of text.  IMHO,
the bidir spec should just spell out how to do the comparison.

Chris

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Tue, 18 Apr 2006 17:59:28 -0400

> So infinity there would be 32-bits of 1.

Right. Which is why I think the bidir spec should not say do the
comparison like PIM-SM which is probably where the confusion originates
and instead just spell it out itself.

Chris