Subject: RE: (ngtrans) Re: reconsidering the Tunnel Setup Protocol (TSP) a s anngtrans project

From: Jung Cyndi-ACJ099 <[email-masked]>
Date: Fri, 4 Jan 2002 11:40:22 -0600

Sorry, I just got "back" from the holidays and missed this entire thread.

I suppose I should defend 6over4.  Or perhaps I should defend IPv4 multicast,
which seems to be the problem with 6over4, the complete dependency that the
6over4 method has on IPv4 multicast.  But it isn't the failure of inter-domain
IP multicast, as Francis pointed out, since 6over4 is bounded by administratively
constrained multicast, and will never span multiple domains (if the boundaries
are clearly defined, which may prove to be too difficult for your average IT operator).

However separate 6over4 is from any inter-domain multicast deployment problems, the
mess at the global level has evidently cast a dark cloud over the deployment of 
multicast at the enterprise level.  It sounds as though the claims of success of 
multicast in the enterprise are false.

Cyndi

-----Original Message-----
From: Fred L. Templin [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 9:38 AM
To: Francis Dupont
Cc: NGtrans List; [email-masked]
Subject: Re: (ngtrans) Re: reconsidering the Tunnel Setup Protocol (TSP)
as anngtrans project

Francis,

I am just back from the holidays. As to one point in your 12/22/01 message:

Francis Dupont wrote:
>    Obviously, other details would need to be worked (i.e. when to use
>    IPv6-in-IPv4 multicast vs. when to use NBMA unicast.) But, I claim the
>    core mechanism I described above is at least as elegant as 6to4.
> 
> => 6to4? If this is a typo in 6over4 you have nothing to do for multicast,
> i.e. you get it for free... and you have no usage of it.

Yes, the '6to4' was an unfortunate typo - thanks for pointing it out. My
comments were relative to 6over4 and ISATAP only.

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 04 Jan 2002 10:57:12 -0800

Cyndi,

One assertion that Francis seemed to be making which I do not fully agree
with is that further consideration of multicast is unimportant. (Sorry if
this is not what you were trying to infer, Francis.) On the contrary, I
think it may be advantageous to leverage multicast for enterprises that
support it - but, not to the full extent specified by 6over4. I will
explain what I mean by this below.

There seems to be agreement in the community that requiring multicast in
the site would exclude transition mechanism deployment for a large number of
cases. Thus, the NBMA mechanisms specified by ISATAP are required. But, ISATAP
currently makes no provisions for multicast-enabled sites. I would like to
propose the following simple extension to ISATAP that will increase efficiency
for multicast-enabled sites while requiring NO changes to the current NBMA
mechanisms:

  1. As a configurable option (disabled by default), ISATAP routers MAY send
     periodic unsolicited router advertisements to the 'All-nodes-multicast'
     address (as specified in RFC 2461) on their ISATAP interface, which will
     map the messages to IPv4 multicast (as specified in RFC 2529 and with
     reference to RFC 2365).

  2. Upon receiving periodic unsolicited router advertisments sent by one or
     more ISATAP routers as described in 1., ISATAP hosts SHOULD suppress the
     periodic unicast router solicitation process described in the ISATAP
     draft - unless and until periodic unsolicited router advertisments
     cease and/or default router lifetimes expire.

The reason to present this extension as a configurable option is to allow
an informed administrative decision of when/when not to enable it. Presumably,
a site administrator will enable the option only if he has knowledge of the
existence of a (complete or partial) IPv4 multicast deployment within the
sitee. Thus, unicast router solicitation (and corresponding soliciated router
advertisment) traffic is minimized for multicast-enabled sites while no
penalty is paid for non-multicast sites. 

Please note that I am specifically NOT suggesting a configurable option for
ISATAP that would allow ISATAP hosts to send router solicitations to the 'All-routers-multicast'
address and allow their ISATAP interface to map
them to IPv4 multicast. I believe the NBMA mechanisms already specified
by ISATAP are more efficient for this purpose even when the site supports
IPv4 multicast. The reason is that messages send to the 'All-routers-multicast'
address are sent only to the link-local scope in the IPv6 domain, thus only
the local link is affected for native IPv6 interfaces. But, when the IPv4
site infrastructure is treated as a link layer as in 6over4 and ISATAP,
'All-routers-multicast' messages may travel over multiple IPv4 hops. So,
if router solicitations were mapped to IPv4 multicast, they could potentially
disturb *every* subnet in the multicast-enabled site. Conversely, the unicast
mapping currently specified by ISATAP disturbs only the directed path between
the ISATAP host and the nearest router that configures the ISATAP service
unicast address.

Comments?

Fred Templin
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Fri, 04 Jan 2002 15:16:06 -0800

I've change the subject of this thread as
it has really changed.

Now to asnwer Fred, I would like to object the temptation
to make Isatap more complex than it really needs to be.
Keep It Simple.

This is an early transition mechanism, it has to be simple,
and IMHO, it's absolutly OK if it is not 100% optimized
to take advantage of the hypothetical presence of IPv4 multicast.
Isatap does not need to address every single corner case.
(As a side note, my personal take is that if sites were able to deploy multicast,
deploying IPv6 internally is not much more complex and they could probably
do so without Isatap.)

I would rather like to see a simple and complete ISATAP spec out Really Soon Now,
as there are still open issues, like Isatap router discovery.

    - Alain.

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 07 Jan 2002 10:29:29 -0800

Alain,

> deploying IPv6 internally is not much more complex and they could probably

I am happy to table further discussion of proposed multicast extensions for
ISATAP until such a time that the NGTRANS WG chairs might deem it appropriate.
 
> as there are still open issues, like Isatap router discovery.

I very much agree, and would like to see the same thing happen. In my 12/15/01
message to the NGTRANS mailing list entitled: "Clarification of ISATAP Router
Discovery issues" I proposed solutions for all aspects of the router discovery
issue that have been brought to my attention. I further invited comments and
open discussion from the community on the proposed solutions, but none
materialized. I am still hopeful that the community will provide timely
feedback, since this is the last issue I am aware of for arriving at the
complete ISATAP spec you seek. 

Fred
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Jan 2002 13:45:46 -0500

> the mess at the global level has evidently cast a dark cloud over the
> deployment of multicast at the enterprise level.

I'm not sure it's just the mess at the global level that has cast the
cloud. I'd also consider the widespread deployment of Ethernet-like
media (switches etc) that don't simulate the Ethernet model of multicast 
correctly, to be part of the picture.

a few years ago local multicast would often "just work" because
the underlying media supported it.  That is no longer the case.

Keith