Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 17 Apr 2007 14:55:00 +0530

The document includes suggestions by Bill Fenner regarding TBD
numbering, but otherwise has not changed.

I would like to issue a WG last call on this document.

If you have any comments, please provide them before May 1st (two weeks).

Thanks.
Ian Chakeres

On 4/17/07, [email-masked] <[email-masked]> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.
>
>         Title           : MANET IANA Needs
>         Author(s)       : I. Chakeres
>         Filename        : draft-ietf-manet-iana-01.txt
>         Pages           : 7
>         Date            : 2007-4-16
>
> This document enumerates IANA assignments for immediate use in MANET.
>    Specifically, a UDP port, two link-local multicast group addresses
>    (IPv4 & IPv6), and two site-local multicast group addresses (IPv4 &
>    IPv6).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-manet-iana-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-manet-iana-01.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
>
>

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Apr 2007 12:29:47 +0200

> I would like to issue a WG last call on this document.

I think there's more work with this document, more than just two weeks 
Last Call.

> If you have any comments, please provide them before May 1st (two

Thanks for asking for comments, here are some:

draft:
> MANET routers subscribe to this LL scoped multicast address and use
> it for LL transmissions of routing protocol packets.
...
> For IPv6, a statically assigned, link-local scope multicast address 
> is used.

I think there's a big difference between a router subscribing to a 
multicast address, and statically assigning a multicast address to an 
interface.  In the above paragraphs you're actually saying the two 
should happen, for the same multicast address.

I personally think the link-scoped multicast address should not be 
'statically assigned', but the router should send a MLD message for it, 
and subsequently be subscribed to that group.

For interface-scoped multicast addresses (ff01::smthing) From [email-masked] Wed Apr 18 06:34:27 2007
Date: Wed, 18 Apr 2007 12:29:47 +0200
From: Alexandru Petrescu <[email-masked]>
To: Ian Chakeres <[email-masked]>
Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call
Cc: manet <[email-masked]>

> I would like to issue a WG last call on this document.

I think there's more work with this document, more than just two weeks 
Last Call.

> If you have any comments, please provide them before May 1st (two

Thanks for asking for comments, here are some:

draft:
> MANET routers subscribe to this LL scoped multicast address and use
> it for LL transmissions of routing protocol packets.
...
> For IPv6, a statically assigned, link-local scope multicast address 
> is used.

I think there's a big difference between a router subscribing to a 
multicast address, and statically assigning a multicast address to an 
interface.  In the above paragraphs you're actually saying the two 
should happen, for the same multicast address.

I personally think the link-scoped multicast address should not be 
'statically assigned', but the router should send a MLD message for it, 
and subsequently be subscribed to that group.

For interface-scoped multicast addresses (ff01::smthing) - I think yes, 
they can be statically assigned to an interface.

Another issue is that AUTOCONF WG seems to be looking at address 
auto-configuration means for MANET networks.  Discovery phase of address 
auto-configuration often uses multicast addresses.  _Maybe_ (I say maybe 
because without this then DHCP multicast groups can be used) new 
MANET-AUTOCONF IANA-reserved multicast groups could be reserved by IANA, 
for MANET autoconfiguration purposes.

What do you think?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 18 Apr 2007 17:21:19 +0530

If you look at other routing protocols, they specify a particular
static multicast address for communication. We are simply allocating
the same type of addresses for MANET protocols.

See the IANA lists at

http://www.iana.org/assignments/multicast-addresses
http://www.iana.org/assignments/ipv6-multicast-addresses

Other comments inline.

> I think there's more work with this document, more than just two weeks

There has been little to no change on this document for some time. I
see no reason to delay its publication.

> > For IPv6, a statically assigned, link-local scope multicast address

The purpose of the multicast group is for MANET router communication.
MANET routers MUST  subscribe to receive messages protocol messages on
a particular address and MUST also transmit to the same address to
insure interoperability.

> and subsequently be subscribed to that group.

I think that this proposition could significantly delay routing
convergence and cause many problems in MANET style networks.

>From looking at the AUTOCONF charter
(http://www.ietf.org/html.charters/autoconf-charter.html) and problem
statement, they are working on unicast address auto-configuration for
MANET routers.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Apr 2007 16:03:29 +0200

> the same type of addresses for MANET protocols.

Yes, I agree, but these addresses (eg OSPF's AllSPFRouters ff02::5)
aren't statically assigned, IMHO.  A router must join that group.

Or maybe we have misunderstanding of 'statically assigning'?

>> I think there's more work with this document, more than just two
>> weeks Last Call.
> 

Wait for more review?

>>> MANET routers subscribe to this LL scoped multicast address and
>>> use it for LL transmissions of routing protocol packets.
>> ...
>>> For IPv6, a statically assigned, link-local scope multicast
>>> address is used.
> 
>  MANET routers MUST  subscribe to receive messages protocol messages
> on a particular address

Right, that's what I mean, so they're not 'statically assigned'.

> and MUST also transmit to the same address to insure
> interoperability.

Yes, when a router sends a packet to a multicast address it doesn't 
necessarily have to statically assign that address to a interface, 
neither does it have to join that group.

>> multicast address, and statically assigning a multicast address to
>> an interface.  In the above paragraphs you're actually saying the
>> two should happen, for the same multicast address.
>> 
>> 'statically assigned', but the router should send a MLD message for
>> it, and subsequently be subscribed to that group.
> 

I think there may be an understood multicast way of working for IPv6, 
and doing anything different than that ('assign' multicast addresses 
without subscribing to the respective group) can cause many delays in 
standardizing a novel multicast method for MANET and IPv6.

Underlying linklayers for which MANET protocols have been demonstrated 
(WiFi) have explicit means to subscribe to link-layer multicast groups, 
which work hand in hand with the capability of receiving network-layer 
multicast datagrams.

I don't see any way for a router to receive packets addressed to a group 
other than subscribing, or joining, to that group.  Do you see another?

>> For interface-scoped multicast addresses (ff01::smthing) - I think
>> yes, they can be statically assigned to an interface.
>> 
>> auto-configuration means for MANET networks.  Discovery phase of
>> address auto-configuration often uses multicast addresses.  _Maybe_
>> (I say maybe because without this then DHCP multicast groups can be
>> used) new MANET-AUTOCONF IANA-reserved multicast groups could be
>> reserved by IANA, for MANET autoconfiguration purposes.
> 
>  statement, they are working on unicast address auto-configuration
> for MANET routers.

Does the AUTOCONF Charter forbid the use of known multicast mechanisms 
to auto-configure unicast addresses?  If it doesn't, then AUTOCONF may 
need new well-known multicast addresses, with link or site scope, 
exclusively for the purpose of unicast address auto-configuration.

Alex

---

From: Christophe Jelger <[email-masked]>
Date: Wed, 18 Apr 2007 16:56:24 +0200

Hello Ian/all,

I'm sorry to play the devil's advocate again ;-) but ...

looking back at the debate that took place in mid-March 2005 (2 years 
ago!) on this mailing list I am still not convinved that the WG was in 
favor of having a unique mcast address and port for all MANET protocols. 
This is against the current best practice for assigning mcast addresses 
to routing protocols and as we all know, having a unique address and 
port is mostly driven by the packetbb proposal which was also highly 
debated in July 2006 on the AUTOCONF list.

Note I don't want to trigger yet another debate on this, but I wonder if 
the IESG is ready to validate a proposal that advocates the use of a 
single <mcast address + port> tuple for multiple (different) protocols 
while current best practice is to _not_ do this. Maybe you have had 
promising pre-discussions with IESG people to convince them this is a 
good idea, otherwise the document could have a better motivation section.

More details:

- in section 2 you say "all interoperable MANET routing protocol traffic 
...". I think "interoperable traffic" is very vague and sounds even very 
odd to me: we have interoperable systems, but can (network) traffic be 
interoperable ... I mean does the wording makes sense? Better say that 
all traffic with common format (i.e. packetbb) must be sent to the same 
UDP port?

- reference to packetbb: I'm not sure here, but can you refer to a draft 
in an RFC about to go to IESG?

sorry for raising negative points,
Christophe

-- 
--------------------------------------------------
Dr. Christophe Jelger, University of Basel
Computer Networks Group, http://cn.cs.unibas.ch/
Bernoullistrasse 16, CH-4056 Basel, Switzerland

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 18 Apr 2007 14:07:54 -0400

I agree "statically assigned" is confusing and I think Ian meant a
well-known address is perhaps better. I think some in the MANET community
may be unclear that MLD joins are specified to actually occur for these
link-local well known ranges, except FF02::1 all nodes. Actually I think
this has been a broader problem in some general IPv6 implementations.
Snooping switches,etc being an example of issues.

So it's a really a well-known, link-scoped multicast address that is Ian is
referencing a request for.  And I agree with Alexandru, I was assuming a
join would be occur (RFC2710) although MLD,etc may seem less useful in the
MANET case.  Connecting MANET across filtering L2 technologies is an
example.  I think the efficiency/robustness issues should be looked at more.
-Joe

>-----Original Message-----
>From: Alexandru Petrescu [mailto:[email-masked]] 
>Sent: Wednesday, April 18, 2007 10:03 AM
>To: Ian Chakeres
>Cc: manet
>Yes, I agree, but these addresses (eg OSPF's AllSPFRouters 
>ff02::5) aren't statically assigned, IMHO.  A router must join 
>that group.
>
>Yes, when a router sends a packet to a multicast address it 
>doesn't necessarily have to statically assign that address to 
>a interface, neither does it have to join that group.
>
>I think there may be an understood multicast way of working 
>for IPv6, and doing anything different than that ('assign' 
>multicast addresses without subscribing to the respective 
>group) can cause many delays in standardizing a novel 
>multicast method for MANET and IPv6.
>
>(WiFi) have explicit means to subscribe to link-layer 
>multicast groups, which work hand in hand with the capability 
>of receiving network-layer multicast datagrams.
>
>I don't see any way for a router to receive packets addressed 
>to a group other than subscribing, or joining, to that group.  
>Do you see another?
>
>Does the AUTOCONF Charter forbid the use of known multicast 
>mechanisms to auto-configure unicast addresses?  If it 
>doesn't, then AUTOCONF may need new well-known multicast 
>addresses, with link or site scope, exclusively for the 
>purpose of unicast address auto-configuration.
>
>Alex
>
>

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 18 Apr 2007 14:20:57 -0400

>From: Joe Macker [mailto:[email-masked]] 
>Sent: Wednesday, April 18, 2007 2:08 PM
>To: 'Alexandru Petrescu'; 'Ian Chakeres'
>Cc: 'manet'
>Subject: RE: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = 
>WG Last Call
>
>I agree "statically assigned" is confusing and I think Ian 
>meant a well-known address is perhaps better. I think some in 
>the MANET community may be unclear that MLD joins are 
>specified to actually occur for these link-local well known 
>ranges, except FF02::1 all nodes. Actually I think this has 
>been a broader problem in some general IPv6 implementations.
>So it's a really a well-known, link-scoped multicast address 
>that is Ian is referencing a request for.  And I agree with 
>Alexandru, I was assuming a join would be occur (RFC2710) 
>although MLD,etc may seem less useful in the MANET case.  
>Connecting MANET across filtering L2 technologies is an 
>example.  I think the efficiency/robustness issues should be 

Before I see comments on my logic, I meant to say filtering L2 technologies
is an example when it IS useful.

>looked at more.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Apr 2007 13:56:50 +0200

Joe Macker wrote:
> well-known address is perhaps better.

I agree 'well-known address' is better than 'statically assigned'.

> I think some in the MANET community may be unclear that MLD joins are
> specified to actually occur for these link-local well known ranges,
> except FF02::1 all nodes. Actually I think this has been a broader
> problem in some general IPv6 implementations. Snooping switches,etc
> being an example of issues.

I think indeed a broader set of issues.

But even for all-nodes link-local scope ff02::1 the node must join the 
group.  I think the only addresses for which it is sufficient to 
statically assign (no need to join, no need to set local filters) are 
the multicast addresses with interface-local scope (not site-local, not 
link-local, not global).  Like all-nodes ff01::1 (not ff02::1)	.

Alex

> So it's a really a well-known, link-scoped multicast address that is
> Ian is referencing a request for.  And I agree with Alexandru, I was
> assuming a join would be occur (RFC2710) although MLD,etc may seem
> less useful in the MANET case.  Connecting MANET across filtering L2
> technologies is an example.  I think the efficiency/robustness issues
> should be looked at more. -Joe
> 
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Wednesday, April 18,
>> 2007 10:03 AM To: Ian Chakeres Cc: manet Subject: Re: [manet] I-D
>> ACTION:draft-ietf-manet-iana-01.txt = WG Last Call
>> 
>> Ian Chakeres wrote:
>>>  static multicast address for communication. We are simply
>>> allocating the same type of addresses for MANET protocols.
>>>>> The document includes suggestions by Bill Fenner regarding
>>>>> TBD numbering, but otherwise has not changed.
>>>>> 
>>>> I think there's more work with this document, more than just
>>>> two weeks Last Call.
>>> There has been little to no change on this document for some
>>> time. I see no reason to delay its publication.
>> Wait for more review?
>> 
>>> The purpose of the multicast group is for MANET router
>>> communication. MANET routers MUST  subscribe to receive messages
>>> protocol messages on a particular address
>>>> I think there's a big difference between a router subscribing
>>>> to a multicast address, and statically assigning a multicast
>> address to an
>>>> interface.  In the above paragraphs you're actually saying the
>>>> I personally think the link-scoped multicast address should not
>>>> be 'statically assigned', but the router should send a MLD
>>>> message for it, and subsequently be subscribed to that group.
>> I think there may be an understood multicast way of working for
>> IPv6, and doing anything different than that ('assign' multicast
>> addresses without subscribing to the respective group) can cause
>> many delays in standardizing a novel multicast method for MANET and
>> IPv6.
>> 
>> Underlying linklayers for which MANET protocols have been
>> demonstrated (WiFi) have explicit means to subscribe to link-layer
>>  multicast groups, which work hand in hand with the capability of
>> receiving network-layer multicast datagrams.
>> 
>> I don't see any way for a router to receive packets addressed to a
>> group other than subscribing, or joining, to that group. Do you see
>> another?
>> 
>>>> For interface-scoped multicast addresses (ff01::smthing) - I
>>>> think yes, they can be statically assigned to an interface.
>>>> 
>>>> Another issue is that AUTOCONF WG seems to be looking at
>>>> address auto-configuration means for MANET networks.  Discovery
>>>> phase of address auto-configuration often uses multicast
>>>> addresses.  _Maybe_ (I say maybe because without this then DHCP
>>>> multicast groups can be used) new MANET-AUTOCONF IANA-reserved
>>>> multicast groups could be reserved by IANA, for MANET
>>>> autoconfiguration purposes. From looking at the AUTOCONF
>>>> charter
>> mechanisms to auto-configure unicast addresses?  If it doesn't,
>> then AUTOCONF may need new well-known multicast addresses, with
>> link or site scope, exclusively for the purpose of unicast address
>> auto-configuration.
>> 
>> Alex
>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit 
>> http://www.messagelabs.com/email 
>> _______________________________________________ manet mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/manet
>> 
> 
> 
>

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 20 Apr 2007 09:27:02 +0530

I will updated the draft to as per the discussion below. If anyone has
any other technical, grammatical, or other comments, please let me
know and I will incorporate them into the revision.

Ian Chakeres

---

From: Teco Boot <[email-masked]>
Date: Fri, 20 Apr 2007 09:18:49 +0200

Hi Ian,

I still think the status of MANET drafts is confusing, and the IANA request
confused me again. First of all, I want to know what will happen with
current MANET RFCs. Do they become obsolete? This is the second time I asked
this question, it should not be that hard to answer.

Name:  Rfc:  Protocol:  Port:
AODV   3561             654
OLSR   3626             698
TBRPF  3684             712
DSR    4728  48

The manet-iana I-D is about PacketBB and not for __all__ MANET protocols. I
am sure there will be successors on PacketBB, as the current proposals has
still their problems. And think about other work-in-progress on MANET, like
OSPF-MANET, ideas in 6lowpan/sensornetworks and MANEMO.

Renaming the requested port & addresses to PacketBB solves the __all__ MANET
remark.
And please anser my question what to do with existing MANET protocol RFCs.

Teco

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 20 Apr 2007 18:19:19 +0530

For interoperability between the routing protocol implementations, it
is important that well known port and multicast addresses be assigned.

It was debated long ago that we assign common IANA assignments for all
the current MANET specifications.

Renaming the port to PacketBB sounds like a possible solution to port
naming, but it does not portray the correct intent for the multicast
addresses.

Ian Chakeres

Regarding the status of the existing MANET experimental RFC's, I have
not given any thought to changing their status nor do I see any
urgency to do so.

On 4/20/07, Teco Boot <[email-masked]> wrote:
> DSR    4728  48 o