Re: Comments on draft-ietf-udlr-lltunnel-01.txt

[Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr>]

Dave,

>From: Dave Thaler <dthaler@dthaler.microsoft.com>
>Subject: Comments on draft-ietf-udlr-lltunnel-01.txt
>
>1) This draft claims to be a link-layer tunnelling mechanism,
>   and from the title and abstract, I would expect it to
>   work for any layer-3 protocol (IPv4, IPv6, IPX, whatever),
>   like GRE does.  Is it the intent that this should ONLY work 
>   for IP packets?  If so, the abstract should clarify this if the 
>   title doesn't.  If not, then wording in several sections needs 
>   to be cleaned up (6.2.1 is a good example, but there are plenty).

Right, we can encapsulate any layer-3 protocol via the "back-channel". I 
will make this clearer and perform some clean up.


>2) I *think* I figured out the interface model, but I'm not sure.
>   In particular, it's unclear as to whether the tunnels
>   from receivers to feeds, and the tunnels from feeds to 
>   send-only feeds, appear as interfaces themselves or not.  From 
>   the current spec, my guess is they do not (and so they're
>   different from real GRE tunnels), but either way, this could
>   be made more clear.

In *my* point of view/implementation there is no extra "IP
interface". When a feed is detected, a GRE encapsulation is used to send 
packets to it (similar to feed-feed communication).
Even more, GRE is not mandatory, we only need a common encapsulation
between source (receiver or feed) and destination (feed or send-only feed)
In 6.3.1 [Page 10]
!   Tunnel Type (8 bits): tunneling protocol supported by feed,
!     correponds to the type of encapsulation used by receivers to
!     encapsulate packets which are tunneled:
!     47 = GRE [rfc1701] (recommended)
!      x = any other tunneling supporting the UDL MAC packets.


>   (Also, just for my edification, has there been any work on a 
>   UDLR MIB?  What would one see looking at the Interfaces MIB?
>   Should one even see any entries in the IP Tunnel MIB?)

I think at this time it may depend on the implementation, i.e., where the
packets are captured by the tunneling mechanism, 
In our implementation, the interface behaviour is bidirectional, and
the MIB is updated similarly to the MIB of a bidrectional interface.
We have not been working on a specifing unidirectional MIB and on the
IP tunnel MIB (yet ?).


>4) Section 6.3, item 1, says that a receiver must create "a tunnel"
>   (implying exactly one) when a new feed comes up.  6.3.1 then
>   says the feed may include multiple FBIP's, in "preferred order".
>   6.3.4 item 1 then says that "the corresponding FBIP1" is used
>   implying that FBIP2 .. FBIPn are not used.  If exactly one
>   tunnel is created, and it always uses FBIP1, then what are
>   the other addresses for?

The feed announces the list of IP addr that can be used as tunnel
end-point as a proposed 'default' ordered list. The first entry may be
the prefered IP addr according to the feed point of view. However, a
receiver may have very different connectivity characteristics to every
FBIPx. It may take an FBIPx different from FBIP1 (default one) that has
better connectivity.


>5) If a feed is dual-stack IPv4/IPv6, does it send out two HELLO
>   messages, one for IPv4 and one for IPv6?  If so, how does this
>   affect the Interval parameter?  Is it the interval between
>   HELLOs for the same address family, or is it the interval
>   between HELLOs for any address family?

We considered the case where the feed had a single-stack IPv4 or IPv6 on
the UDL therefore a feed sends only one HELLO packet type.
If there is a dual stack IPv4/IPv6 over a single layer-3 link, then we 
each stack will send its own HELLO packet.


>6) Section 6.3 uses "FBIP" before it's defined (later in 6.3.1)
>  
>7) Lots of typos: "administator", "occure", "occures",
>    "encapsultion", "encapsulaton", "Encapsultation", "encapsultate"
>
>8) Figure 3, lines on right edge don't line up

Okay, I will look at it.

Thanks for your comments.

Emmanuel Duros