Subject: RE: RFC2461bis: Multicast capable vs Multicast Service [was RE: C omments for rc2461bis]

From: "Elwyn Davies" <[email-masked]>
Date: Wed, 27 Oct 2004 10:51:01 +0200

looking back at the text in S2.2, the reason for using multicast-capable
rather than just multicast was that multicast-capable was (i think) supposed
to cover both multicast links which have native support and point-to-point
links which do multicast degenerately.  i think that my problem could be
solved by adding a sentence (or separate definition) in 2.2 to say just that
i.e.

multicast-capable link - a link which is either point-to-point or multicast
type

then i think the substitution s/multicast/multicast-capable/ elsewhere works
fine.

the remark that 'all link types are expected to provide multicast services
for IP' really deserves some exploration other than in 2461bis.  if this is
really a requirement for *all* scopes of multicast service then it is
manifestly not being met by most IPv6 implementations.  for ND all we need
is multicast at the link level. DHCPv6 may need it at the site level.  but
what should we expect from a general implementation in the way of multicast
services?  there is really a considerable amount of vagueness about this
across all the specifications.

Regards,
Elwyn

-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]] 
Sent: 26 October 2004 15:39
To: Davies, Elwyn [HAL02:0S00:EXCH]
Cc: [email-masked]
Subject: RE: RFC2461bis: Multicast capable vs Multicast Service [was RE:
Comments for rc2461bis]

Your mail server forgot ;)

=> Grr! Hate, hate.

Using the term 'multicast services' around this area is confusing.  If the
link MUST provide multicast services maybe that is something that should be
in the basic definition of IPv6 (it isn't stated explicitly in RFC2460)
rather than in 2461bis. 

Expanding on what I said originally, one reasonable interpretation of the
requirement that all links support multicast services is that they are in
some sense 'multicast capable': if you take this view then *all* links are
necessarily multicast capable.
So I think the problem is that the language doesn't properly convey what I
think is the intention: I believe we are trying to distinguish between:
- links that provide multicast *as a Layer 2 capability* ('The hardware does
multicast') 
- links that don't, so that the multicast services have to be provided as an
overlay  
=> Exactly.  I guess our difference is that I get the distinction from the
spec when
I read it now (with "multicsat capable" replacing "multicsat" in 2.2). Is
that a sufficient
change ? Let me know if you think another change is needed. 
Hesham

Hope this clarifies my point. 
Regards, 
Elwyn 
Original Message 
================ 
S2.2 and S3: 
The note after the NBMA definition says that '...all link types (including
NBMA) are expected to provide multicast service for IP...'.
A naive interpretation of the phrase in S3 'On multicast-capable links...'
(just after the Redirect bullet) in conjunction with the previous note might
take it that actually all links are multicast-capable.  The term should be
explicitly defined so as to explicitly exclude NBMA and any other sort of
links that this phrase is not supposed to apply to - or to allow it to be
done optionally on this sort of link - the current wordings are too vague.
This is also related to the comment on 6.2.1 below. 
=> I'm not sure I see the problem you see (and I looked at the 2462 thread).
We can make the 
link definition for multicast, a definition for "multicast capable". But
apart from that the current 
spec states refers to other docs in the introduction when it discusses NBMA
links. 
The text you refer to above is talking about multicast services, which is a
different issue. 
So for now, I'll s/multicast/multicast capable in 2.2 and that should do the
job IMO. 

----------------------------------------------------------------------------
------ 
Elwyn B Davies 
        Routing and Addressing Strategy Prime & IPv6 Core Team Leader 
        CTO Office, Portfolio Integration               Solutions Ready

        Nortel Networks plc                     Email:
[email-masked] 
        Harlow Laboratories                             ESN
6-742-5498 
        London Road, Harlow,                            Direct Line
+44-1279-405498 
        Essex, CM17 9NA, UK                     Fax
+44-1279-402047 
        Registered Office:                      Maidenhead Office Park,
Westacott Way, 
        Company No. 3937799                     Maidenhead, Berkshire, SSL6
3QH 
----------------------------------------------------------------------------

This message may contain information proprietary to Nortel Networks plc so
any 
unauthorised disclosure, copying or distribution of its contents is strictly
prohibited. 
----------------------------------------------------------------------------

"The Folly is mostly mine" 
and the opinions are mine and not those of my employer. 
============================================================================
====== 

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------