Subject: AW: AW: AW: ifStackTable layering in L2TP

From: Klausberger Walter <[email-masked]>
Date: Tue, 12 Dec 2000 00:43:29 +0100

-----Originalnachricht-----
Von: Evan Caves
An: Klausberger Walter
Cc: 'Dave Thaler '; [email-masked] '; [email-masked] '
Gesendet: 11.12.00 22:49
Betreff: Re: AW: AW: ifStackTable layering in L2TP

>> Klausberger Walter wrote:
>> 
>> Hi all,
>> 
>> sorry for my absence, but I was on a short vacation and now I'm in San
>> Diego. I must admit, I'm a little confused and I'm not shure if
>> everyone understands it the way Dave does.
>> 
>> Are there any responses from already existing implementations?
>> 
>> I do not fully agree to the argument that a forwarder (like IP router)
>> is the same as a multiplexer (like MLP). A multiplexer normally works
>> with a fixed set of connections (well I know they can be teared on and
>> so on). It multiplexes packets comming from a higher layer to several
>> lower layers or the other way round. A forwarder just takes packets
>> from a lower layer and puts them to another lower layer depending on
>> some rules. In my opinion Daves approach shows new aspects. I hope all
>> others see ist the same way!?
>> 
>> On the other hand I agree with Dave that a tunnel can be seen as a
>> virtual interface.
>> 
>> So in L2TP case the tunnel IF would sit on top of an invisible
>> forwarder and PPP would be the forwarding layer (in LAC case), e.g.
>> 
>>         ------PPP-------
>>         |              |
>>     DS0(phys. IF)    tunnel
>>                        |
>>              (IP router, invisible)
>>                        |
>>                     ethernet

>This is what is currently presented in the MIB except in its model
>we do not call the forwarding layer a 'PPP forwarding layer', it
>is modeled as a switching element. The reason being that on the LAC
>side one could argue that PPP isn't really there anymore once the 
>tunnel is up (it sort of steps aside).

ok, I agree with you on that

>> 
>> or should it be
>> 
>>        PPP               tunnel
>>         |                   |
>>     DS0(phys. IF) (IP router, invisible)
>>                             |
>>                          ethernet
>> 
>> or anything else?

>I would argue against this. And besides in this picture how do PPP
>packets end up in the tunnel?

agreed

>> 
>> We are loosing the context between the physical interface, where the
>> PPP session comes in (DS0) and the tunnel this session goes to. This
>> information is now provided with the L2TP MIB only.

>Yup. Just like you need the CIDR MIB (or whatever it is called now)
>to dump your routing tables.

agreed

>> 
>> As PPP now is the forwarding layer should it be visible on top of the
>> DS0 layer, or only if the PPP connection is not tunneled.

>PPP isn't even in the picture on the LAC in my model. If it was
>you would expect to be able to manage it like any other PPP interface
>(which is definitely not the case).

A LAC does not necessarily tunnel a PPP session (you might say it is not a
LAC then, but that's how it's written in the L2TP RFC). If a PPP session is
terminated in a LAC shouldn't the PPP layer be visible?

Thinking about all this, I have concerns about the stack layering MIB. When
I have an AAL5 layer (assume PPP over AAL5), I know by informations from the
L2TP MIB that a PPP session is coming from the AAL5 interface and going into
a certain tunnel.

How do I know if IP packets come from that tunnel? To me there is something
missing, or does the CIDR MIB provide enough information (I'm not so
familiar with this MIB)?

>> 
>> >In the multipath example, the tunnel would be layered over ALL
>> >the interfaces which have potential routes over them.  In this
>> >sense, it's very analogous to multilink PPP, among other
>> >things.
>> 
>> Dave, do I understand it correct that regardless of the routing entry
>> a tunnel IF should sit on all possible interfaces it may be routed
>> over? That would also be a new aspect to me.
>> 
>> I think these are quite basic questions and I'm unsure how to proceed.
>> Maybe there should be a clarification in the L2TP MIB draft(I don't
>> want to change the tunnel MIB RFC, though it would be a good idea to
>> add a clarification in case of a new version)
>> 

>And I don't think that the L2TP MIB should be describing how the IP 
>Tunnel MIB works (but I will probably loose that argument).

I think it could be an issue, otherwise there might be a lot of other people
asking the same questions later, but I agree it is a matter of the Tunnel
MIB description...

Walter
-

---

From: Evan Caves <[email-masked]>
Date: Wed, 13 Dec 2000 08:26:32 -0800

> A LAC does not necessarily tunnel a PPP session (you might say it is
> not a LAC then, but that's how it's written in the L2TP RFC). If a PPP
> session is terminated in a LAC shouldn't the PPP layer be visible?

I would think the PPP interface is visible in the ifStackTable and
ifTable
on the LAC until it gets tunneled. At the time a tunneling decision is 
made it disappears (and should show up on the LNS). At this point you
can use the l2tpSessionMapTable to see which interfaces (the interface
that was below PPP before tunneling occurred) are having their packets
switched to and from a particular tunnel/session.

> 
> Thinking about all this, I have concerns about the stack layering MIB.
> When I have an AAL5 layer (assume PPP over AAL5), I know by
> informations from the L2TP MIB that a PPP session is coming from the
> AAL5 interface and going into a certain tunnel.
> 
> How do I know if IP packets come from that tunnel? To me there is
> something missing, or does the CIDR MIB provide enough information
> (I'm not so familiar with this MIB)?

I am not sure what you mean. If you are asking whether PPP/IP packets
are being tunneled the only way you can tell is by querying the
LNS using the IPCP MIB. The CIDR MIB has nothing to do with this. It
is used to manage the route table on a device.

evan
-

> I think it could be an issue, otherwise there might be a lot of other
> people asking the same questions later, but I agree it is a matter of
> the Tunnel MIB description...
> 
> Walter
> -