RE: misconfiguring the tunnel source address [mech-v2-04]

["Follen, Stephen" <sfollen@enterasys.com>]

>> The Enterasys implementation also does not check the tunnel source 
>> address at tunnel configuration time, primarily because to do so
would 
>> be overly restrictive to the admin in terms of order of
configuration; 
>> The admin is allowed the flexibility to configure the tunnel first
and 
>> then configure the IPv4 interface if (s)he wants to - but that's just

>> an implementation detail.
>
> This so called "flexibility" to configure a tunnel without the
existence a
> IPv4 interface, basically indicates that the box allows the creation
of a
> virtual point to point link, and route(s) that are using it, when
there is no
> physical connectivity to provide the basis for that link (and routes)
to exist.
>
> I do not see the advantage to the user, but can certainly see the
headaches...

The virtual point to point link's (the tunnel's) oper status is held
down until there is an interface configured with the source address,
also until there is a route to the remote v4 destination, etc.
I'm not trying to debate the fine points of a particular implementation
here; my point was only that these are implementation details.

>> 
>> IMHO this sort of stuff is not important enough to go into an RFC. 

> The spec promises a virtual point to point link between two nodes to
the user.
> Configuring the tunnel following the spec, and getting a tunnel that
does not
> work, is a spec bug.

There are lots of way one can follow most any spec and still not have
things work properly - misconfiguration is always possible.

>> It
>> seems obvious that if the tunnel source address does not exist on the

>> device, or if there is no route to the remote v4 destination, or ... 
>> the tunnel won't work.
>> 

> Specifications state often the obvious things to those who are
knowledgeable.
> That does not mean they should not contain what could be obvious to
some.

I agree, but specifications never do, and never can, state everything.
The question is where to draw the line. IETF specs, in general, do
assume some level of networking knowledge.
It's certainly not wrong to clearly state that the tunnel's source
address must an address configured on the device, I just don't think its
necessary to do so, especially at this late stage in the development of
this particular spec; others, of course, can have differing opinions.