Re: I-D Action: draft-ietf-6man-6lobac-01.txt

[Alexandru Petrescu <[e-mail]>]

Le 13/03/2012 19:51, Kerry Lynn a écrit :
> Hi Alex,
>
> Thanks for your comment.
>
> I was following the method of generating IIDs used by 6LoWPAN [RFC
> 4944].
>
> I note that RFC 4291 states in section 2.5.1 "For all unicast
> addresses, except those that start with the binary value 000,
> Interface IDs are required to be 64 bits long and to be constructed
> in Modified EUI-64 format."

That would mean that addresses prefixed by 000 (instead of 001) could
have interface ids with lengths larger than 64, no?

That RFC says "There are a number of types of links that have link-layer
interface identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs.
Examples include LocalTalk and Arcnet."

Is MS/TP a link with IEEE tag on it now or in the future?

(if not then one would be free to have Interface IDs wiht lengths
shorter than 64 and thus maybe with an easier to implement one-to-one
mapping between the link address and the IP address).

> Technically, locally assigned MS/TP IIDs could be shorter than 64
> bits. However, if EUI-64s become popular for MS/TP devices there
> might then be a situation where some devices have 64-bit IIDs and
> others have shorter.

Yes, I listen to that.  I do not know about that tendency, maybe you see
whether EUI-64s are becoming popular for MS/TP.

> I am also not sure how a numbering scheme that uses prefixes longer
> than 64 bits would work in the general case (given that many other
> data links use 64-bit IIDs).

I believe it may work with DHCP and RAs.  Off of the top of my head I'd
say that implementations don't impose this prefix length max 64 for
assigned prefix, or for interface identifier.

Alex

>
> -K-
>
> On Tue, Mar 13, 2012 at 1:54 PM, Alexandru Petrescu
> <[e-mail]>  wrote:
>> HEllo,
>>
>> A side note about this.  It is not a request for modification,
>> just a thought.
>>
>> I wonder why do we want the Interface Identifier to be of length
>> 64 when the MS/TP node address seems to be 8bit only.
>>
>> In a sense, it may be because SLAAC over Ethernet (802) is used to
>> use 64bit IIDs.
>>
>> But in another sense, this is not Ethernet and hence the IID could
>> be of length 8bit of MS/TP, right?
>>
>> I am asking this because of other contexts (non-MS/TP) whereby the
>>  link-layer addresses are shorter than 48bit and yet the Interface
>> ID is still 64bit, "to make SLAAC work".
>>
>> In some contexts too, the ISP delivers a 64bit prefix to a leaf
>> network and if that IID is almost always 64bit it means that it's
>> hard next to impossible to form sub-prefixes of that ISP 64bit
>> prefix and still use SLAAC.
>>
>> In a sense, it would be better to define the IIDs of MS/TP (or
>> other link) to be of length 8, allow the ISP to assign 64bit
>> prefix to leaf network, and let the gateway in between to derive
>> prefixes out of that 64bit (up to 120) and still use SLAAC.
>>
>> This is just a thought, not a request to modify.
>>
>> Yours,
>>
>> Alex
>>
>> Le 13/03/2012 12:47, Kerry Lynn a écrit :
>>
>>> Greetings,
>>>
>>> The main changes to the WG version of this draft are: a) tweaks
>>> that resulted from the initial public review of the BACnet MS/TP
>>> change proposal, the most significant being the COBS encoding of
>>> data and data crc fields to remove preamble sequences; and b)
>>> addition of two informative appendices to provide code examples
>>> for the data crc and COBS encoder/decoder.  These appendices are
>>> insufficient to implement the data link, but are provided e.g.
>>> for those writing Wireshark dissectors or otherwise wanting more
>>> detail about over- the-wire format.
>>>
>>> I'd like to solicit specific comments on what is needed to move
>>> this draft forward - IOW, what would you like to see added in
>>> order for this draft to be ready for WGLC?
>>>
>>> For anyone who'd like to view the details of data link state
>>> machines, etc., I can provide the relevant clause (9) of the
>>> ASHRAE 135-2010 (BACnet) spec, as well as the MS/TP change
>>> proposal (Addendum an).
>>>
>>> Thanks, -K-
>>>
>>>
>>> On Mon, Mar 12, 2012 at 1:06 PM,<[e-mail]>
>>> wrote:
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories. This draft is a work item of the
>>>> IPv6 Maintenance Working Group of the IETF.
>>>>
>>>> Title           : Transmission of IPv6 over MS/TP Networks
>>>> Author(s)       : Kerry Lynn Jerry Martocci Carl Neilson Stuart
>>>> Donaldson Filename        : draft-ietf-6man-6lobac-01.txt Pages
>>>> : 20 Date            : 2012-03-12
>>>>
>>>> MS/TP (Master-Slave/Token-Passing) is a contention-free access
>>>>  method for the RS-485 physical layer that is used extensively
>>>> in building automation networks.  This document describes the
>>>> frame format for transmission of IPv6 packets and the method
>>>> of forming link-local and statelessly autoconfigured IPv6
>>>> addresses on MS/TP networks.
>>>>
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt
>>>>
>>>>
>>>>
>>>>
Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> This Internet-Draft can be retrieved at:
>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-6lobac-01.txt
>>>>
>>>>
>>>>
>>>>
--------------------------------------------------------------------
>>>>
>>>>
>> IETF IPv6 working group mailing list
>>>>
>>>> [e-mail] Administrative Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>>>
>>>>
>>
>>>>
>>>>
--------------------------------------------------------------------
>>>
>>> IETF IPv6 working group mailing list [e-mail] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>>
>>>
>>>
--------------------------------------------------------------------
>> IETF IPv6 working group mailing list [e-mail] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------