Re: [16NG] Re: multicast and IPv6 over ETHCS

[Alexandru Petrescu <[e-mail]>]

Max, thanks for your comments.  It seems our disagreement is larger than
I thought :-)

In another mail I've tried to suggest that there is value in text that
doesn't specify new behaviour (ie IPv6 runs over ETHCS as usual, no new
behaviour) while you think that a new behaviour should be specified
(albeit link-layer).

I think there are other people on the list who agree that this document
should not specify link-layer behaviour.

Riegel, Maximilian wrote:
> Hi Alex,
> 
> Your text on the behavior of the IPv6 stack on handling multicast 
> looks like standard IPv6 behavior.

Yes, it is standard behaviour of IPv6 stack over a link-layer multicast
capable link, nothing new, that's the intention.

> If this is true, than your text may be added for informational 
> purposes but do not add anything to the normative part of the 
> specification.

Well if it's standard behaviour then it can't be informational, right?

It should be formulated such as to not tresspass the main documents
specifying this (2464, 2461, dhcp, etc) and to _recommend_ them - I agree.

> If your text is defining special IPv6 behavior, i.e. changing 
> standard IPv6 behavior, then it is not acceptable for the IPoETH-CS 
> solution.

I agree if it were so.  But no the text doesn't change standard IPv6
behaviour, far from my intention.  At some point it gets a little more
than standard behaviour: it requires the SS to put link-layer multicast
addresses in the  link-layer header, something that current RFCs don't
require, but implementations do.

If you need, I can change that formulation to not tresspass at all, ie
to say  that implementations MAY use link-layer multicast addresses in
link-layer header fields.  Do you want me to do that?

> The IPoETH solution does not allow any change to the standard 
> behavior of the IP stack, when sending IP packets over Ethernet, but 
> implements IP specific extensions in the Ethernet layer to make the 
> transmission of IP over Ethernet more 'wireless friendly'.

I think this Proposed Standards document is not the place to specify
link-layer behaviour.

> RFC4541 is an example of such an extension to the Ethernet layer.

YEs, and it's INFORMATIONAL at IETF.  Do you think this IPv6-over-ETHCS
document should be INFORMATIONAL?

> There is a real-world reason behind: an IP host may be connected by 
> an Ethernet cable to an IEEE802.16 bridge device. The host does not 
> have any awareness that its IP over Ethernet packets are transferred
>  over an IEEE802.16 radio link. All the IP specific optimization must
>  take place in the Ethernet layer over IEEE802.16.

Sounds reasonable to me.  But how that happens shouldn't be specified here.

> Bye Max BTW: Link layer multicast is not provided by the Ethernet 
> Convergence Layer but by a bridge device in the system deploying the 
> ETH-CS for transmitting Ethernet frames over IEEE802.16.

Thanks for this clarification.  So one is tempted to call the document
"IP over bridge device in the system deploying the ETH-CS for
transmitting Ethernet frames over IEEE 802.16".   A terminology issue.

I can re-formulate the multicast phrases in my text to say the the
link-layer multicast goals MAY be implemented by the bridge device in
the system deploying the ETH-CS for transmitting Ethernet frames over
IEEE 802.16.  Do you agree that I re-formulate it that way?

Do you or co-authors accept to introduce my text in the draft?

If yes - where?

I'm not pushing to do it now - please take the time - but if you or
co-authors do, and when you do, please let me know.  Once I know we have
agreement to include the multicast text in the draft I can modify it
according to all suggestions raised on the list.

Alex


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng