Subject: [L2tpext] Defining a certain port of an LNS for the route back to LAC

From: "Reich, Christian" <[email-masked]>
Date: Wed, 3 Jul 2002 18:26:50 +0200

Hi,
L2TP relies on the functionality of ip-routing in an open internet. In some cases there is the desire to use a certain path.
For example if an ISP (ISP 1) collects the traffic via a special accessnetwork for an other ISP (ISP 2) it is necessary to define the path for that traffic.
In this case the LNS, or numberous LNS, is a kind of gateway between the two AS of these ISPs.
Because they are ISPs they have also existing peerings with other ISPs (f.ex. ISP 3).
Via these peerings the traffic could also be routed. These peerings are sometimes very expensive for ISP 1 and so there should be a way to avoid the usage.

Could it be possible to add a suggestion into the L2TP RFC that a LNS should have a feature like policy based routing in that way that it uses the same physical port than the SCCRQ gets into the LNS and as destination address the source address of the SCCRQ? Without defining a static route to the LAC.

                              __________                 ___________
                             |          |               |           |
               [LAC]---------| ISP 1    |-----[LNS]-----|  ISP 2    |
                 |           |__________|               |           |
            _____|_____          |                      |___________|
           |           |         |expensive peering           |
           |  ADSL     |         |               _________    |peering
 [Remote]--|  access   |         |______________|         |___|
 [System]  |  network  |                        |  ISP 3  |
           |___________|                        |_________|

Any comments or other suggestions?

Thanks

Regards

Christian Reich

---

From: Vipin Jain <[email-masked]>
Date: Wed, 3 Jul 2002 13:22:51 -0700 (PDT)

Reich,

Thought not very encouraging, one might use l2tp-tunnel-switching
to achieve what you call as policy routing l2tp sessions/tunnels;
Now this could happen on a per tunnel basis as per the draft.
However, IP TE/policy-routing would determine what happens to the the
actual outgoing IP packets on the intermediate node.
http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-tunnel-switching-02.txt

thanks,
-- vipin

--- "Reich, Christian" <[email-masked]> wrote:
> Hi,
> L2TP relies on the functionality of ip-routing in an open internet. In some
> cases there is the desire to use a certain path.
> For example if an ISP (ISP 1) collects the traffic via a special
> accessnetwork for an other ISP (ISP 2) it is necessary to define the path for
> that traffic.
> Via these peerings the traffic could also be routed. These peerings are
> sometimes very expensive for ISP 1 and so there should be a way to avoid the
> usage.
> 
> Could it be possible to add a suggestion into the L2TP RFC that a LNS should
> have a feature like policy based routing in that way that it uses the same
> physical port than the SCCRQ gets into the LNS and as destination address the
> source address of the SCCRQ? Without defining a static route to the LAC.
> 
>                                                  
>                      
>                               __________                 ___________
>                              |          |               |           |

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "Ian Calderbank" <[email-masked]>
Date: Thu, 4 Jul 2002 08:34:46 +0100

Christian,

I think you can solve the problem with appropriate network design and
implementation without changing the RFC.

if your LNS doesn't support Virtual Routers:
- put a route on the LNS so there's a more specific route to the LAC via
the interface to ISP1 than via ISP2. You say you don't like this as
statics, but it does make logical sense to separate the traffic with
routing. You maybe could do it with bgp with a specific community for
the LAC prefixes set by ISP1.

if your LNS does support Virtual Routers
- define one virtual router with a default route to ISP1, and no
connectivity to ISP2. This has the job of terminating all tunnels from
ISP1 and handling all L2TP. 
- define a second virtual router to face ISP2, with a default route to
ISP2, no connectivity to ISP1. All user traffic coming out of the
tunnels should be mapped into this second virtual router. This is still
effectively routing separation, but now you don't have to care what the
LAC prefix-range is.

cheers,
Ian