[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [16NG] Re: multicast and IPv6 over ETHCS
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
16NG at ietf.org
https://www1.ietf.org/mailman/listinfo/16ng