Subject: Re: ifStackTable layering in L2TP

From: Evan Caves <[email-masked]>
Date: Fri, 01 Dec 2000 15:37:08 -0800

Klausberger Walter wrote:
> 
> Hi everybody,
> 
> I started to read the new L2TP-MIB draft and I already have several
> questions...
> 
> As I understood stacking should be made visible up to the 'forwarding
> layer'(e.g. IP). When looking at common ifStackTables I never saw an IP
> layer until yet. 

Not sure what you mean by 'saw'.

> So there should be no layer above Ethernet when
> transporting IP packets...

Unless you have a tunnel sourced from that ethernet interface.

> 
> As an example in <draft-ietf-l2tpext-l2tp-mib-01.txt> the tunnel interface
> in the LNS is set on top of an Ethernet interface. But L2TP is never set
> directly above Ethernet, but will be transported via UDP/IP. So there is no
> direct context. The connection depends on the routing table.

There is always a direct context. Every L2TP packet has a source address
that corresponds to one of the L2TP devices configured IP addresses.
That IP 
address is associated with a particular ifStack on the device of which
the L2TP tunnel interface then gets layered on.

> 
> Assume there is an LNS with an Ethernet and an unnumbered Frame Relay
> interface. First the tunnel is setup via Ethernet IF. Due to the entries in
> the routing table, the tunnel IF is set on top of the ethernet IF.

Not sure what your saying here but I assume you mean "we will choose the
source IP address based on which egress interface is closest to the
tunnel endpoint".

> Now a
> problem occurs in the backbone and the connection is switched over to the
> unnumbered Frame Relay IF (same IP address). Would this need a change in the
> ifStackTable?

The layering model (at least from the tunnel I/F on down) is straight
from
the "IP Tunnel MIB". I agree that in pratice tunnel packets could be
routed
out of a different egress interface based on shortest path routing. As a
result of that the layering model as depicted breaks (inconsistant
statistics
and possibly state). I am cc'ing Dave Thaler to see if he can provide
some
input into this matter.

> 
> It is possible to transport L2TP directly over ATM or via UDP/IP/ATM. 

Yes.

> Would
> there be no difference in the ifStackTable?

There should not be.

> 
> In case of LAC it is even more unclear to me how the ifStackTable will look
> like. In former L2TP-MIB drafts it was stated that the tunnel IF sits on top
> of the interfaces that forward the PPP packets (e.g. DS0). 

It was changed because conceptually there has to be a switching decision
made to move packets from an 'ingress' interface (the DS0 for example)
to 
an 'egress' interface (the L2TP tunnel interface). This seemed to make
the 
most sense otherwise you end up layering egress interfaces on top of
ingress
interfaces in the ifStackTable (which I personally have never seen 
before).

> Now there is a
> reference to the tunnel MIB (RFC 2667) and everything seems to be different
> now. 

There has always been a reference to the "IP Tunnel MIB".

> Do we have a problem here with unnumbered IP interfaces, 

I don't think it is just a problem with unnumbered interfaces. If
topology
changes you can still route a packet out a numbered egress interface
while
the source address of the packet has an IP address of another interface.
 
> because...
>    Tunnels are handled by creating a logical interface (ifEntry) for each
> tunnel. These are then correlated, using the ifStack table of the Interfaces
> MIB, to those interfaces on which the local IPv4 addresses of the tunnels
> are configured.
> ...or do I have to take the numbered Ethernet IF for the ifStackTable, even
> if the tunnel is connected via Frame Relay IF?

No. That would not make sense.

> Or am I totally wrong?

Nope. I think you have brought up a legitimate concern but to resolve it
we have to consult with the IP Tunnel MIB folks.

> 
> just some questions, I hope someone can answer...

Sorry for the delay (I have just moved to a different employer). Give me
some more time to think on it and hopefully Dave will have some
suggestions.

cheers,

evan
-

> with best regards
> Walter

---

From: Evan Caves <[email-masked]>
Date: Wed, 06 Dec 2000 11:51:52 -0800

Dave,

Dave Thaler wrote:

>[snip...]
> > -----Original Message-----
> > From: Klausberger Walter [mailto:[email-masked]]
> > Sent: Wednesday, November 29, 2000 2:06 AM
> > To: [email-masked]
> > Subject: ifStackTable layering in L2TP
> >
> > Hi everybody,
> >
> > layer until yet. So there should be no layer above Ethernet when
> Correct.

??? Then why in the tunnel mib is their a tunnel interface on top of
a physical interface (ie: ethernet).

> Correct.

The tunnel mib infers that there is a direct context (ie: the 
tunnel sits on top of the ifStack associated with one of the 
devices locally configured IP addresses) and completely ignores
any discussion on ifStack layering issues based on destination 
route lookups.

As an aside it would seem that, at least to me, the tunnel
interface should be at the bottom of the ifStack (after all it is
a virtual wire to a remote network). Attempting to stack the tunnel
I/F on ifStacks based on the current topology to me is problematic
(especially if their are multiple paths to a particular destination
which means an understanding of how the forwarder is choosing nexthops
for tunneled packets) and provides little or no benefit. Is their
something in the ifStack architecture that says the bottom of every
stack must terminate at a physical interface?

> > the routing table, the tunnel IF is set on top of the
> > ethernet IF. Now a
> Yes.  Keep in mind that the ifStackTable is only a logical
> table.  It doesn't necessarily correspond to any state in
> the device.

I do not understand this statement. Of course it represents the
state of the device at the time of the query.

> It just means that if you query the ifStackTable,
> that the agent can at least determind which IF the tunnel
> is currently being routed over.

This could be many.

> 
> > It is possible to transport L2TP directly over ATM or via
> > UDP/IP/ATM. Would
> No difference.  There would be a difference in the
> addresses used on either end of the tunnel though
> (for the outer header), as in one case they're IP addresses
> and in the other case they're not.
> 
> > now. Do we have a problem here with unnumbered IP interfaces,
> > because...
> The correlation should be to the interface used to reach
> the remote address, which is not necessarily the one
> which has the local IPv4 address assigned to it.

This statement is completely missing from the tunnel mib, and if 
you ask me, a very important one because as the mib reads today it
is describing a very different layering model.

evan
-

---

From: Evan Caves <[email-masked]>
Date: Wed, 06 Dec 2000 19:54:42 -0800

Dave Thaler wrote:
> > From: Evan Caves [mailto:[email-masked]]
> > Sent: Wednesday, December 06, 2000 11:52 AM
> > To: Dave Thaler
> > Cc: Klausberger Walter; [email-masked]; [email-masked]
> > Subject: Re: AW: ifStackTable layering in L2TP
> >
> >
> > Dave,
> >
> > Dave Thaler wrote:
> > 
> Because a tunnel isn't an IP packet (e.g. a TCP or UDP packet).
> It's a Foo-over-IP packet (e.g. IP inside IP).  There's no
> interface corresponding to the IP or TDP or UDP layers
> when you just send IP packets over an Ethernet.
> 
> When you run a tunnel, then you have another interface.

I don't think this answers either my or Walters question.

> There's no object called an "ifStack".  

Huh? "ifStack" in the above sentence means "interface stack".

> An ifStackEntry corresponds
> to a particular combination of one specific interface being layered
> over another.
> 
> Yes, read RFC 2233.  For example, "where the bottom of the stack is a
> physical interface (ifConnectorPresent has the value 'true')"

Unfortunalely I was looking at its predecessor rfc1573. This paragragh 
seems to have been added in this later version. Do you know why this has 
to be the case?

> 
> What you say is "problematic" is not problematic and the ability
> to handle that situation is one of the features of the ifStackTable
> as discussed in RFC 2233 (e.g. "An example of upward multiplexing is MLP
> (Multi-Link-Procedure) which provides load-sharing over several
> serial lines by appearing as a single point-to-point link to the
> sub-layer(s) above.")

OK let me try again. In traditional ifStacks there is a well defined 
boundary or service interface between interface sub-layers where each 
sub-layer does its protocol processing and forwards 'foo' to the next 
sub-layer. We could model an ifStack up to a fowarder as

		   Forwarder
                -----------------
		I/F sub-layer n		(PPP)
		-----------------
		I/F sub-layer n-1	(HDLC)
		-----------------
		I/F sub-layer n-2	(RS232)
		-----------------

In the IP tunnel case the picture looks more like
		
		-----------------
		 I/F sub-layer n	(Tunnel)
		-----------------
		   Forwarder
                -----------------
		I/F sub-layer n-1	(PPP)
		-----------------
		I/F sub-layer n-2	(HDLC)
		-----------------
		I/F sub-layer n-3	(RS232)
		-----------------

in which case the fowarder is not part of any interface sub-layer.
So the client to layer n-1 is a fowarder and the service provided 
to layer n is a forwarder. The policies implemented by the forwarder
are not known by either layer so it becomes difficult to determine
who is below layer n without actually forwarding a tunneled packet
as the packet contents will determine how the packet is forwarded
(based on the forwarders local policies like filters, multipath
criteria, QOS and route table lookups).

[snip...]
> > is describing a very different layering model.

Don't you think that this should be described in the tunnel mib?

evan
-

---

From: Klausberger Walter <[email-masked]>
Date: Thu, 14 Dec 2000 17:47:20 +0100

evan wrote:

>walter wrote:

>> Sorry, this was a mistype. I meant 'How do I know if IP packets come
>> from that AAL5 interface?'. I only see an interface.
>> 
>> - In case of PPP packets coming from this interface, I find an entry
>> in the L2TP MIB (in case of tunneling)
>> 
>> - In case of IP packets coming from this interface, do I get the
>> information via routing table (there should be a route to this IP
>> interface)?

>The ipAddrTable (RFC 1213) will tell you what ifEntries have an IP
>address configured on them.

Not in case of unnumbered IP interfaces (like ATM/AAL5,...).

walter
-