Subject: [MBONED] Well-known multicast group for ssmping/asmping?

From: Stig Venaas <[email-masked]>
Date: Tue, 25 Nov 2008 10:16:46 +0100

In Minneapolis we discussed whether there should be some well-known
multicast group for ssmping/asmping, or I should perhaps say, for the
protocol specified in draft-ietf-mboned-ssmping-06.

I see two benefits in having a dedicated well-known ASM group:

o Avoiding conflicts with other multicast usage
  If server administrators or implementations just pick some groups or
  group ranges, these may conflict with other usage. The draft says that
  there should generally be a rate limit to 1pps, but this could still
  be an issue.

o Easier management
  Server administrators do not need to configure the servers (although
  I would still recommend it, see drawbacks below). Network
  administrators may know that certain multicast traffic is this
  protocol from the group address.

The drawback I see is:

Anyone using this well-known group for asmping, will join the same
group and receive everyone else's replies. With ASM this may even be
replies coming from multiple servers. Since the client source port is
not fixed and there also is a client ID, the issue is really bandwidth
and not that the user will see the wrong replies in the application.
Hence I would still suggest that administrators can configure a larger
range (hoping those who do know what they are doing). Administrators
may also want to configure site-local ranges etc.

Please speak up if you have any thoughts on this.

If we do this for ASM, then I think one should also get a well-known
group for SSM. For SSM the problem of receiving multiple replies is
smaller, and it still simplifies management. Comments?

Stig
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinFrom [email-masked]  Tue Nov 25 01:16:52 2008
Date: Tue, 25 Nov 2008 10:16:46 +0100
From: Stig Venaas <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [MBONED] Well-known multicast group for ssmping/asmping?
Sender: [email-masked]

In Minneapolis we discussed whether there should be some well-known
multicast group for ssmping/asmping, or I should perhaps say, for the
protocol specified in draft-ietf-mboned-ssmping-06.

I see two benefits in having a dedicated well-known ASM group:

o Avoiding conflicts with other multicast usage
  If server administrators or implementations just pick some groups or
  group ranges, these may conflict with other usage. The draft says that
  there should generally be a rate limit to 1pps, but this could still
  be an issue.

o Easier management
  Server administrators do not need to configure the servers (although
  I would still recommend it, see drawbacks below). Network
  administrators may know that certain multicast traffic is this
  protocol from the group address.

The drawback I see is:

Anyone using this well-known group for asmping, will join the same
group and receive everyone else's replies. With ASM this may even be
replies coming from multiple servers. Since the client source port is
not fixed and there also is a client ID, the issue is really bandwidth
and not that the user will see the wrong replies in the application.
Hence I would still suggest that administrators can configure a larger
range (hoping those who do know what they are doing). Administrators
may also want to configure site-local ranges etc.

Please speak up if you have any thoughts on this.

If we do this for ASM, then I think one should also get a well-known
group for SSM. For SSM the problem of receiving multiple replies is
smaller, and it still simplifies management. Comments?

Stig
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfofo/mboned

/mboned

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Nov 2008 13:01:42 +0200 (EET)

My 5c,

One benefit of asm/ssmping is that you can use it to debug the 
specific group you're having problems with.  If you're forced to use a 
well-known address, that benefit disappears.

So, if we have a well-known group, it should only be used by default 
(unless a group is explicitly specified), but clients and servers 
should still be able to test an arbitrary group as well.

In the interest of not getting stuck with this issue and still 
debating it in the next IETF, I'd be inclined to argue that we just 
forget about the well-known group, even as a non-mandatory default. 
It could be incorporated in version 2 of the protocol if it is deemed 
useful.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Nov 2008 13:01:42 +0200 (EET)

My 5c,

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 25 Nov 2008 10:20:37 -0500

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Tuesday, November 25, 2008 6:02 AM
> To: Stig Venaas
> Cc: [email-masked]
> Subject: Re: [MBONED] Well-known multicast group for ssmping/asmping?
> 
> My 5c,
> 

He took the words right out of my keyboard.

> It could be incorporated in version 2 of the protocol if it is deemed 

And unicast ping doesn't have a default address either.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 25 Nov 2008 10:20:37 -0500

Bert

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 25 Nov 2008 21:38:29 +0530

Hi Stig,

> smaller, and it still simplifies management. Comments?

I guess using this well-known multicast group for ssmping/asmping should be used only if a user wants ssmping server/client to choose a particular group address. But it should still provide an option where user can do ssmping/asmping for any group address.

Thanks,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 25 Nov 2008 21:38:29 +0530

Hi Stig,

Thanks,
Bharat

---

From: Stig Venaas <[email-masked]>
Date: Wed, 26 Nov 2008 09:43:59 +0100

Pekka Savola wrote:
> My 5c,
> 
> One benefit of asm/ssmping is that you can use it to debug the specific
> group you're having problems with.  If you're forced to use a well-known
> address, that benefit disappears.
> 
> (unless a group is explicitly specified), but clients and servers should
> still be able to test an arbitrary group as well.
> 
> In the interest of not getting stuck with this issue and still debating
> it in the next IETF, I'd be inclined to argue that we just forget about
> the well-known group, even as a non-mandatory default. It could be
> incorporated in version 2 of the protocol if it is deemed useful.
> 

My opinion is pretty much what you wrote above. I am trying to get a
feel for what the wg wants though. I think we're pretty much done.
Whether there is a default group doesn't really change the protocol, and
I'm hoping we can conclude on this by the end of this week.

In either case I'm planning yet another revision with minor changes. I
plan to do this in just a few days.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 26 Nov 2008 09:43:59 +0100

Stig