Subject: Empty Bootstrap Message

From: [email-masked]
Date: Thu, 11 Feb 1999 11:52:22 -0500

Request comments on the following subject:

The PIM-SM bootstrap mechanism requires the sending of bootstrap messages
for RP-set distribution AND to properly "elect" a BSR.  If a router has
been configured as a CBSR and is not configured as a CRP, then initially
this router has no RPs in its local RP-set.  Lets say that router is also
the highest priority CBSR.  How do the CRPs ever learn of this CBSR for
sending C-RP-Adv messages?

One way to guarantee the Bootstrap mechanism election process works for all
combinations of CBSR and CRP configurations of a network is to have the
RP-set empty CBSR build an empty Bootstrap message upon the expiration of
the bootstrap timeout, if it transitions to or is in ELECTED BSR state.
There is no group count defined in the current PIM-SM Bootstrap message
format, so packet length must be used to determine if the message is empty
(and I hope all message parsers won't go belly up).

Is this empty bootstrap message valid?  If not, how does one get the
non-CRP CBSR router to participate in the BSR election process?

Thanks,

Garry M. Kump
[email-masked]
(919) 254-2395

---

From: Shahzad Ali <[email-masked]>
Date: Thu, 11 Feb 1999 13:09:39 -0500 (EST)

> non-CRP CBSR router to participate in the BSR election process?

Hi,

I think this is a valid concern and was raised some time ago on this
mailing list.  Rusty, I think, pointed out that the spec doesnt say that
you dont send out the empty BSR message and so that is the right thing to
do.  However, we figured out that one of the implementations (Cisco's)
doesnt do this at all which was also pointed out. 

Thanks,

Shahzad Ali
EE Grad, University of Delaware.
Software Engineer, Torrent Networking Technologies.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 11 Feb 1999 13:29:44 -0500 (EST)

I'll give an answer from memory, and if I'm wrong perhaps someone else
will correct me :)

> non-CRP CBSR router to participate in the BSR election process?

Yes, a Bootstrap message with no RPset is legal.
This will especially occur when the first CBSR is first turned on,
and is not a CRP.

It should not occur when a backup CBSR takes over after the loss of
the highest priority CBSR... in this case the CBSR should include the
RPset which it last heard from the previous BSR.

-Dave

---

From: Nair Venugopal <[email-masked]>
Date: Thu, 11 Feb 1999 12:23:00 -0800 (PST)

I have a question regarding the metric preference values used in Asserts.

1) If different PIM-SM implementations exist on a multi-access
network, how is one assured that all the boxes use the same metric
preference for various unicast routing protocols? 

2) Is there a well-known list of values for various unicast protocols?

3) If this is a known issue, tips on how various implementations work
   around this would be appreciated. :-)

Thanks.
--Venu

--------------------------------------------------------------------
Nair Venugopal  --- [email-masked] --- 3Com EWD Engineering

---

From: Pavlin Ivanov Radoslavov <[email-masked]>
Date: Thu, 11 Feb 1999 12:47:51 -0800

> preference for various unicast routing protocols? 

Some time ago Kurt Windisch raised the same question, but it did not
get resolved.

> 2) Is there a well-known list of values for various unicast protocols?

I am not aware of such list, but please let me know if you find one.

>    around this would be appreciated. :-)

In pimd it is configurable in pimd.conf and has the default low
priority value of 1024. The problem is that the UN*X kernel does not
provide reliable route metric. If the same box is running gated or
some other unicast routing daemon, then that daemon can provide the
PIM-SM module with some appropriate metric (presumably consistent
across the same implementation, but not necessary true across
different vendors/implementations).

Pavlin

---

From: Ahmed A-G Helmy <[email-masked]>
Date: Thu, 11 Feb 1999 12:55:21 -0800 (PST)

> I am not aware of such list, but please let me know if you find one.

I belive I saw such a list some time back ... I am surprised it's not 
part of the spec ... but it's basically part of the configuration...
perhaps someone at cisco has it (Dino or Liming ?!),

Regs,
-A

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 11 Feb 1999 13:07:09 -0800 (PST)

>> perhaps someone at cisco has it (Dino or Liming ?!),

    It is not in the spec because many would think it is proprietary. Here
    are the defaults cisco uses for Assert metric preferences:

Connected                 0
DVMRP                     0
Static                    1
EIGRP-Summary             5    
[M]BGP-External	          20  
EIGRP                     90
IGRP                      100
OSPF                      110
ISIS                      115
RIP                       120
EGP                       140
[M]EIGRP-External         170  
[M]BGP-Local              200
[M]BGP-Internal	          200
Infinity (no route found) 255

Dino

---

From: Bill Fenner <[email-masked]>
Date: Thu, 11 Feb 1999 13:22:38 PST

In message <[email-masked]>you writ
>preference for various unicast routing protocols? 

Luck, or administrative configuration.

>2) Is there a well-known list of values for various unicast protocols?

There's Cisco's defaults (all of which can be administratively
configured, on a per-protocol and/or per-route basis); see
http://sandbox.parc.xerox.com/~fenner/mcast/mbgp/route_selection.html
for a table.

>   around this would be appreciated. :-)

We hope that administrators configure all the routers on the same
subnet with the same distances.  Failing to do this can definitely
cause serious problems; I've lost count of the number of times that
black holes have deveopled at the shared-medium multicast interconnects
because of Assert problems.

  Bill

---

From: Nair Venugopal <[email-masked]>
Date: Thu, 11 Feb 1999 15:04:13 -0800 (PST)

Thanks for the prompt responses, everyone.

I have a followup question. Assume that BGP is the winning unicast routing
protocol in the "metric preference" computation. Would the value in the
PIM-Assert "metric" field be the degree of preference (DOP) of the BGP
route? 

--venu

---

From: Hugh LaMaster <[email-masked]>
Date: Thu, 11 Feb 1999 15:19:42 -0800 (PST)

> preference for various unicast routing protocols? 

"Coordination".  Or, "Management".

> 2) Is there a well-known list of values for various unicast protocols?

There is a well-known list that Cisco uses for default "distance".
But, since these get reconfigured sometimes, at best it could
only be a "recommendation".  In particular, this is something
that absolutely has to be configurable on a per-router basis.

>    around this would be appreciated. :-)

The first step is to remember that PIM is not a multicast
routing protocol ;-) it is a protocol for building a multicast
forwarding tree.  PIM uses "whatever" routes that happen
to be available.  I know that this is obvious, but, it is
easy to forget in the context of, e.g. multiple adjacent 
exchange LANs, or, an exchange LAN and an internal LAN.

Some of these routes, but not all, are multicast-specific,
such as BGP4+ "nlri multicast" ("only") routes, and DVMRP routes, 
but, PIM can also use unicast routes, including BGP4, OSPF, 
static, and directly-connected routes.  Again, stating the obvious, 
but, ...

If you are anticipating a configuration issue, you are correct.
In general, the problem is only acute when you have adjacent
broadcast media (a router with interfaces on two different
broadcast LANs).  The same set of metric preference values/
distances may not be appropriate for all interfaces.  

Regardless, longest-match is not a cure-all for this,
because you don't necessarily want the most-specific 
unicast route in preference to a less-specific 
multicast-only route, or cases where a less-specific
BGP4+ route is to be preferred to a more-specific DVMRP
route or whatever.  PIM assert functionality can also 
make it problematic to configure route redistribution 
[e.g. DVMRP -> BGP4+] in a router which has PIM LAN 
interfaces.

I guess the bottom line is, you really need the configurability
that "metric preference"/"distance" gives you, and even then, 
there are just too many situations where the unicast path and
the multicast path diverge for some, but not all, various 
assorted routes, for the configuration to be trivial.

Corrections/additions/deletions welcome.

--
 Hugh LaMaster, M/S 233-21,    ASCII Email: [email-masked]
 NASA Ames Research Center     Or:          [email-masked]
 Moffett Field, CA 94035-1000  No Junkmail: USC 18 section 2701
 Phone: 650/604-1056           Disclaimer:  Unofficial, personal *opinion*.

---

From: Nair Venugopal <[email-masked]>
Date: Thu, 11 Feb 1999 18:23:11 -0800 (PST)

There may perhaps be another issue which could create confusion in
shared-medium multicast interconnects when the best unicast route is a
BGP route.
 
To the best of my (limited) knowledge, BGP uses a  4-byte integer value
(DOP, degree of preference) to decide on the best route to a destination. 
Also, in BGP, a bigger degree of preference value indicates a better
route. 
 
With PIM asserts, even if everyone uses consistent values for "metric
preference", there could be a potential issue when the preferred route is
a BGP route. 
 
1) Different implementations could end up using different mechanisms to
   convert the 4 byte integer value for the Degree of Preference (where  
   bigger is better) to a 2 byte integer value for Assert Metric (where
   smaller is better).
 
2) If the above reasoning is correct, is there a "de-facto" standard
   mechanism to convert the DOP to a 2 byte metric.

Would appreciate comments on this.  As Hugh mentioned, perhaps highly
granular static configuration is the the only solution.

--venu

---

From: Hugh LaMaster <[email-masked]>
Date: Fri, 12 Feb 1999 11:13:34 -0800 (PST)

> granular static configuration is the the only solution.

Sorry to be obtuse, but, I'm not sure exactly what you mean by
"highly granular static configuration".

Re-stating my position sans examples, I think that it is
essential that the metric preference (distance) for each
type of route be configurable per-router, per-route-type, 
because, my operational experience is that it is necessary 
to change the defaults on occasion.

The examples in the previous message were intended to illustrate
why that is so.  Apologies for being so verbose.

---

From: Nair Venugopal <[email-masked]>
Date: Fri, 12 Feb 1999 14:59:40 -0800 (PST)

On Fri, 12 Feb 1999, Hugh LaMaster wrote:

> I'm not sure exactly what you mean by

Sorry for being vague. I was refering to exactly what you say below.  My
concern was related to interoperability when implementations were using
(different) default values for metric preferences and metrics in Asserts.

--Venu

---

From: Liming Wei <[email-masked]>
Date: Fri, 12 Feb 1999 15:05:39 -0800 (PST)

Sorry for the late reply. I must have missed the earlier message from
Rusty on this thread. A candidate bootstrap router who thinks
itself as the bootstrap router should emit bootstrap messages even if
it does not have any RP-set. The cisco image that exhibited this
behavior had a bug. It is fixed in the later 12.0 versions.

-Liming
--------
> From: Shahzad Ali <[email-masked]>
>