Re: comments on draft-lynn-6man-6lobac-01 "IPv6 over MS/TP" (was: comments on ipv6-over-mstp)

[Alexandru Petrescu <[e-mail]>]

Hello Kerry,

Sorry for late reply.

I do agree with your comments and my comments below are non-blocking on
the advancement of this draft.  I support advancement of this
draft.

> On Tue, Jul 26, 2011 at 6:03 PM, Alexandru Petrescu
> <alexandru.petrescu at gmail.com> wrote:
>>
>> Comments on draft  draft-lynn-6man-6lobac-00:
>>
>> - needs a section on multicast address mapping; it may not be
>> straightforward: it may need to _not_ send all ip-multicasted
>> messages to 255 link-layer address: the solicited-node multicast
>> address includes the octet address (as opposed to eg ethernet
>> 6octets) hence it could send it to that octet address (not 255).
>
> The current version is -01; see section 9

Yes, I mistakenly looked at -00 because that's how it was announced by
the url in the meeting agenda - I just clicked on it.  -01 addresses my
initial comment of needing a multicast section.

> It is a non-goal (perhaps this should be stated explicitly in the
> I-D) to modify the current MS/TP state machines (other than the
> extension for larger data frames already proposed in BACnet).

I agree, it sounds difficult to modify the MS/TP state machines and I do
not suggest that.  I suggest modifications to the IP stack, instead.

> The only currently available option is 255 (all-nodes).  We *could*
> look at MS/TP as a multicast challenged data link and support
> functions like NS via RFC 4861 extensions as discussed in IPv6 ND
> Optimization for Energy-aware Devices.

sure, one could.

> Plan B would be to look at using the 128-254 address range for
> multicast mapping, but then we diverge from co-existence and
> possibly need to modify state machines.

Right, no, I don't suggest modify state machines below IP, but modify IP
stack to better support broadcast of MS/TP yes.

When the IP stack sends an NS to the solicited node multicast address it
puts the last byte of the dst field of the IP header as a value 1..127.
  Then it builds the MAC header.  What should be the dst address in that
MAC header? (it is the IP stack who sets this field).  Then

draft-lynn-6man-6lobac-01 says:
> MS/TP does not support multicast, therefore IPv6-level multicast
> packets MUST be carried as link-layer broadcast frames in MS/TP
> networks.

This means that the dst field of the MAC header is 255 to answer the
question.

I think this unnecessarily sends a IP-multicast packet to everyone else
on the link (255).  This is probably not necessary.  The IP stack knows
the link-layer address (that one octet) and it should use it rather than
255 as the dst field of the MAC header.

Typically NS with a sol-node IP dst address is used during DAD: try to
see whether somebody else uses IP same address.  For Ethernet, only 3
out of 6 bytes of the mac address are present in the IP sol-node
address, hence it is necessary on Ethernet to have dst of the MAC header
to be the multicast MAC address (or sometimes broadcast on Ethernet).

But for MS/TP it seems only one octet is the unicast address, and that
does fit in the IP sol-node address, and hence could be reused to be put
in the dst address of the MAC header.

Finally, this is just to make things smart, not necessarily a blocking
point.

>> - 1 Poll for Master - sounds as RS, why not mapping one into
>> another? 2 Reply to Poll for Master sounds as RA, same.
>
> These are MAC control frames that are part of token generation (or
> recovery from a lost token).  Again, modification of the MS/TP MAC
> is a non-goal.  See section 2 for MS/TP MAC requirements.

I agree modifying MS/TP MAC is a non-goal.

Making a stack work ok on some link involves often address mapping but
sometimes also message mapping, i.e. send an RS, and send "Poll for
Master" at the same time.  This is what some implementations (not MS/TP,
other link) do, and this is what implementer needs to know.

Message sending mapping is a rule like this:

"Send RS MUST trigger Send "Poll for Master"."

>> - MLD mapping could be as well useful.
>
>
>
> Can you say more about this?

MLD is Multicast Listener Discovery protocol used typically to make
multicast work on links, and sometimes on links not supporting
link-layer multicast.  Multicast to work ok is absolutely necessary for ND.

In a similar vein as "send RS trigger send PFM", one could write rules
like "send MLD REPORT to joing group of MASTERS prior to send PFM".

These last two comments on message mapping and MLD are again just
comments, non blocking.

I look forward to advancement of this draft.

Alex


>
> Thanks, -K-