[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments to UDRL draft
Some comments to draft-ietf-udlr-lltunnel-01.txt
Section 6 says:
> This mechanism has been designed to work for
> any topology regardless of the number of feeds and
> receivers. In particular, the special case of
> a single send-only feed and multiple receivers
> is among the topologies supported.
I would claim, that it is not supported in
particularly scalable way. In Section 8.1 it
is assumed, that normal (ethernet)style ARP
is used in broacast feed.
This implies, that if there is large number
of receivers in one feed (that seems to be
possible in 27 Mbits DVB link), huge amount
of ARP traffic is generated and must be
processed by all receivers ?
(DVB links can be devided to smaller
virtual links, but that is other issue)
Section 6.1 says:
& 4) an IP address different from the previous cases
& (any IP address): the datagram is discarded.
& Packets whose destination does not belong to
& the unidirectional link are discared. Routing
& is not allowed, see Section 8.2.
Why discarded ?
I guess it is job of routing protocols to
affect to routing tables so, that these
packets are not send to tunnel, if that
is what is wanted (as is said in 8.2 ).
And, if this approach is selected, as well you
should NOT send via tunnel unicast packets that
belong to the unidirectional network, because
obviously they are routed there anyway, even if
they are not send via tunnel.
Section 8.2 says
& However, routing protocols MUST be configured
& to take into account the link unidirectionality.
& IP routing must match the real topology of the
& Internet at network level. It is not the aim of
& the tunneling mechanism to forward the IP traffic,
& it MUST only be used to forward routing protocol
& messages from receivers to feeds. Routing protocols
& at the receivers MUST prevent IP traffic from being
& forwarded to their receive-only interface.
Sometimes, like in Mobile IP it is requirement to
tunnel all "return traffic" back to "home subnet".
Why it is denied here ?
Section 7.1 says:
> In our case, only the support of the MAC addressing
> scheme of the unidirectional link MUST be implemented.
> Note, this MAC level packet can carry an IP packet or
> an ARP packet.
What is ment here ? Somehow this sentence is
contradigting with previous Section (7.) ?
Section 7.2 says:
> An alternative is to encapsultate the MAC level packet
> within IP. The protocol field in the IP datagram is
> then set to the MAC level type of the unidirectional link.
IP protocol = MAC level type ?
What are these MAC level types ?
--
Harri.Hakulinen
@research.nokia.com Play the Snake
Visual Communications http://www.nokia.com/snake/
Tampere/Finland