Subject: [magma] MRD note

From: Toerless Eckert <[email-masked]>
Date: Mon, 8 Apr 2002 12:03:02 -0700

a) Just a nice idea that VRRP introduced to even more ensure that
   local scope packets are not forwarded, and if they are give the
   ability to detect this better:

     Send the packet with a TTL of 255 and demand from implementation to
     only accept TTL=255 packets.
   
     This of course is on top of RA and effectively enables you to always
     detect if a packet was forwarded by an incorrect router and/or sent by
     an incorrect host.
   
   Not sure - has anybody already implemented MRD and/or is it up for last
   call already ? If not, then i would propose to use this method also for
   MRD packets.

b) I have an issue with the large number of timing parameters
   in section 3.6: There are 5 variables that as far as the current text
   spec goes can all be configured individually, and there is no
   discussion what effects this would have on LAN behavior, especially
   in the face of:

      - multiple routers with different configured parameters
      - switches in the middle trying to guess what's going on
	without actually knowing any of those parameters

   I personally think that there should be a minimum number of configurable
   parameters, that these parameters must be transmitted as part of 
   annuncement packets, and that all other parameters must be calculable
   from those. I don't say i know all details necessary, but i think it
   must be simpler than it is right now. For example, 3.6.5 is such
   a variable: as soon as it is not 3 * MaxAdvertisementInterval, you
   MUST configure it consistently and there is NO way for the protocol
   to determine if this consistency actually exists in the network. That's
   another typical case of a dangerous-deployable protocol because it requires
   too much configuration coordination beforehand.

c) With all the work invested into MRD, it would be good, if it could be
   used as a multicast router keepalive protocol. While this certainly is
   somewhat within the target range of MRD, i don't think that the
   currently defined minimum interval of 2 seconds is good enough for that
   purpose. Two ideas here:

     I) We could define the Ad.Interval in the packet to have a 
	better suited granularity:

	0..127   - time in 1/100 second [0.00 sec ... 1.27 seconds ]
	128..255 - time in sec + 127    [1 sec ... 128 seconds ]
     
     II)We should/might consider the question on how to use a different
	address instead of the all-systems address. I particularily don't
	think that hosts should be bothered with MRD messages unless
	they really want to listen in on that "routing control crap" ;-)

d) I think we should allow for advertisement/termination messages to
   be sent with a source ip address of 0.0.0.0. This would for switches
   to send out these messages without being required to have an ip
   address assigned (which if they support lot's of VLANs often is an
   issue). Why would switches want to send out MRD messages ? Well, for
   the default options, it may not be too useful, but for example if you
   consider that a switch may want to actually control for example the
   SSM range or other optional features in the network, then it makes
   sense for the switch to be able to intercept and regenerate such
   options into packets sent by itself.

Cheers
	Toerless

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 19 Apr 2002 12:23:45 +0100

I thought this may be a useful place to give a few comments/questions on
 -01 of the draft <draft-wu-rgmp-01.txt> :

1) Section 3.1 para 5.
If I understand paragraph 4 correctly, then a router MUST not
send a RGMP leave message for a group which it previously sent a 
RGMP join for,  if **IT** determines there is a MAC multicast 
address overlap with another group which **IT** has also issued a 
RGMP join message for.  I think the condition therefore also
applies in the simple case, as well as for "undesired" multicast traffic
case.

2) Section 3.2
In section 1, the draft says "PIM is an Example" of a protocol that can use
RGMP. Yet later the draft indicates that a "PIM HELLO" is used to indicate
the presence of a multicast router - other drafts seem to suggest we should
use MRD. perhaps you should say whether MRD is / is not sufficient??
- is this because only SM routing protocols can be used?
- I wondered here what should be the case for BGMP...

3) Section 3.2
My main worry is what happens when you have an intermediate switch / shared
LAN which is not RGMP enabled. I note the draft says this is illegal.

  +------+                   +------+    +------+
  |RGMPsw|                   |Recv 1|    |Recv 2|
  +------+                   +------+    +------+
      |                          |           |
      |                          |           |
      ---------------------------+-----------|

 - I still wonder whether such events could arise due, e.g., to:
    (i) misconfiguration of a switch port which was intended to run RGMP
    (ii) network patch errors
    (iii) debugging activity where another switch is inserted in the path.

At the moment, the implication is that the two routers sharing the switch
port fight to suppress each other's traffic using RGMP Leaves.  If I
understand that right, that may produce rather confusing packet loss
patterns... Making it hard to debug the group form a remote site!

In this case, the routers should see each others RGMP requests - as will
the switch - do you think it would be possible to insert a few rules that
say that in this case the interface should IGNORE RGMP and promiscuously
forward? - Straight forward congestion (if it happens) would seem much
easier to debug.

Section 6.

The above (routers with a shared switch port) may also be a security issue,
since it can lead to accidental/intentional denial of service in situations
where RGMP should not really have been used.

----

I also found the following NiTs which you may like to fix in the next rev:

"ip" is used as well as "IP"

section 3.2
"support routers not support PIM"
- should be "support routers not supporting PIM"

section 4.1 para 1 line 3
"to to" delete duplicate word.

you probably should add an IANA Assignments section...

----

Best wishes,

Gorry Fairhurst

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 19 Apr 2002 13:14:28 -0700

Gorry, thanks for the feedback, comments inline.

> applies in the simple case, as well as for "undesired" multicast traffic

No, the router does not need to determine MAC overlap, in RGMP this
is the job of the switch - bascially because switches may be more
intelligent than just MAC based forwarding anyhow. I'd hoped for the text
to be clear on this. Can you tell me which piece of 3.1 made you think
the router should do MAC based comparison ?

> use MRD. perhaps you should say whether MRD is / is not sufficient??

For best operational compatibility, RGMP must require PIM Hello messages
to be recognized to indicate the presence of a router on a port. MRD is
certainly the best upcoming protocol to recognize presence of a multicast
router, but i would not want to require it at this point in time in
RGMP because of the interdependencies this would create. If MRD itself
would be an RFC very quickly, i would be happy though to add a
"SHOULD support MRD to recognize router ports" to the RGMP text - but
if MRD is not an RFC, then this text would stall RGMP itself becoming an
RFC, so i think it's not worth it - in any event, MRD itself already
says that it is the destined standards protocol to determine where multicast
routers are, so by pure merit of a switch supporting MRD, it already seems
logical to me that a switch that supports MRD and RGMP would then have
to use MRD to recognize router ports for RGMP operations - i.e.: i
don't think this really requires further text (further text in the IETF
just creates these ugly stalling chains of publishing ;-)

> - I wondered here what should be the case for BGMP...

Gee, well, RGMP was developed to solve a deployment problem, not to
be the saviour of L2 for all upcoming and not really worked out protocols.
But it's quite simple: as long as you have a join-based protocol, you
can use RGMP. Once you have a flood based protocol (dense-mode, etc..)
you would need to extend RGMP - and we thought that that wasn't too 
much worth it at this point in time.

> LAN which is not RGMP enabled. I note the draft says this is illegal.

Not really. Here's the point: RGMP is meant to be used to provide 
throughput performance improvement when this is needed in a switched
network - otherwise why bother to use it. Now when somebody is physically
misconfiguring the network and makes this performance improvement impossible,
how would you best want to have the network react to quickly get this
physical misconfiguration resolved ? I don't think that soft failback to
non-performance improvement is the right approach, because it's less
likely to be detected than the possible blackholing that we have now.

In general: Never ever design a multicast protocol that will
generate more traffic in the error case - we've been there with dense-mode
and DVMRP, it was fun while it lasted, and everybody likes to hear
MBone story over a good beer, but please keep it there ;-)

> where RGMP should not really have been used.

This is not a protocol caused DoS attack, this is a physical
misconfiguration caused DoS problem. I was not under the impression
that physical misconfiguration caused issues needed to be mentioned
in the security concerns, but yes, if they need to be, i am happy
to mention it - and see above: I love blackholing rather than flooding ;-))

> you probably should add an IANA Assignments section...

For the address, right. Thanks a lot for those, i'll add them.

Cheers
	Toerless

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 Apr 2002 10:53:57 +0100

See in-line comments...

> the router should do MAC based comparison ?

Here's the paragraph:

"   If undesired multicast packets are received at a router from a 
   switch, the router may send an RGMP Leave message to the switch.
   This message should be rate-limited.  Before the RGMP Leave message
   is sent in this situation, a 

*** router ***

	should check that the data is 
   not needed for the group and any other groups that share the same
   MAC layer multicast destination address.  This MAC/IP multicast 
   address ambiguity is described in RFC1112 [6]."

- I thought that meant that the router did the check - I'd rather the
switch did this, because there are different ways in which multicast
addresses can be handled depending on the level at which filtering 
takes place :-)

> router, 

The point was "Is MRD going to be ***SUFFICIENT*** to configure RGMP?",
or does the switch need to also know that only sparse mode routing is
used? 

For a router -> switch communication, the router KNOWS if it is
running a sparse mode routing protocol, and then CAN send RGMP messages.

In 4.1, for a switch -> switch, or switch -> router, there is a
mention of sending RGMP messages from switches, how do the switches
know whether to use RGMP on the router ports? 

or do they only send RGMP for groups which they receive RGMP messages
for?... 

This is what doesn't seem to be so clear.

> but i would not want to require it at this point in time in

Understood :-)

> can use RGMP. 

OK.

> Once you have a flood based protocol (dense-mode, etc..)

OK. As you say, perhaps not an immediate problem...

> likely to be detected than the possible blackholing that we have now.

Do I understand this correct?
It seems this isn't just blackholing, as in dropping all packets for
a group, but seems to be intermittent forwarding of packets for the group
as the L2 control plane thrashes backwards and forwards between the 
forwarding (joins received from a router that wants a group) and 
filtering (leaves received from a router that does not want the
same group). 

Have you thought about this?

Apart from the intermittent traffic - which is a pain to debug, is 
there also a question of the additional L2 control processing load?

> MBone story over a good beer, but please keep it there ;-)

Well, as you say, the MBone is an interesting story. But, that's a network
level issue - to do with traffic flowing around the Internet.  So, this
is quite different. It's a subnetwork optimisation.  We're not talking
about whether extra traffic is flooded to remote interfaces of a router,
but just how to better manage traffic between two points in a L2
subnetwork.

I guess a switch that receives two different HELLO messages on the same
port is aware of the problem - so what SHOULD/MUST it do. At the moment
the ID seems to suggest a switch discards the second "HELLO"???

> to mention it - and see above: I love blackholing rather than flooding ;-))

OK.

---

From: Ishan Wu <[email-masked]>
Date: Mon, 22 Apr 2002 14:58:49 -0700 (PDT)

Gorry,

Thanks for the review/comments, response in-line.

>addresses can be handled depending on the level at which filtering

Routers do not need to determine MAC overlap before sending the RGMP
Join/Leave messages.  In the case of re-sending RGMP Leaves to
suppress undesired multicast packets, checking for MAC address overlap
is an optimization, not a required feature.  The idea is, if the RGMP
Leave will be ignored at the switch, this optimization will prevent
the router from sending it in the first place.

Maybe the text could be clarified to say "...in this situation, a router

  SHOULD check that the data is not needed for the group, and
  MAY check that the data is not needed for any other groups
  that share the same MAC layer multicast destination address."

>This is what doesn't seem to be so clear.

A switch doesn't need to know whether to use RGMP on the router ports
or not.  4.1. said that sending RGMP messages from the switch is
outside the scope of this specification.  In case a router does
receive an RGMP message sent to 224.0.0.25, it MUST be ignored.

>there also a question of the additional L2 control processing load?

Toerless probably meant "intermittent blackholing". :-)
As you said, it is really "intermittent traffic".
Toerless is currently on vacation, he can clarify it further
when he is back next week.

>the ID seems to suggest a switch discards the second "HELLO"???

I don't think the ID said anything about how switches will handle
the RGMP Hello from a second router on a port.  Could you tell us
which part of the ID suggested a switch should discard the second
RGMP Hello?

Defining some rules for the switches in this event seems to be a good
idea for identifying the misconfiguration.  If this is properly
addressed in ID for the switches, it could remedy your concern for
the "intermittent traffic" problem, agree?

Ishan