Subject: Re: [lisp] #113: inbound traffic engineering support with LISP

From: Yakov Rekhter <[email-masked]>
Date: Tue, 1 Jun 2010 08:23:24 -0700

Olivier,

> Yakov,
> 
> > #113: inbound traffic engineering support with LISP
> > ------------------------------+--------------------------------------------
-
> > Reporter:  yakov@…            |       Owner:                 
> >     Type:  technical          |      Status:  new            
> > Priority:  major              |   Component:  draft-ietf-lisp
> > Severity:  -                  |    Keywords:                 
> > ------------------------------+--------------------------------------------
> >  From Section 2:
> > 
> >     4.  Traffic engineering capabilities that can be performed by
> >      network elements and do not depend on injecting additional
> >      state into the routing system.  This will fall out of the
> >      mechanism that is use to implement the EID/RLOC split (see Section 4).
> > 
> >  What is described in Section 4 is the use of LISP for outbound/forward
> >  traffic engineering. There is nothing in Section 4 that describes how LISP
> >  could be used to support inbound/return traffic engineering.Either (a) the
> >  draft should add specific details on how LISP supports inbound/return
> >  traffic engineering, or (b) the draft has to explicitly state that LISP
> >  support for traffic engineering is limited to the outbound/forward traffic
> >  only.
> 
> AFAIK, the BGP specification does not explain how to perform traffic
> engineering. For LISP, I propose to add a reference to a paper that
> describes one possible solution for both inbound and outbound te
> 
> http://inl.info.ucl.ac.be/publications/interdomain-traffic-engineering-locato
ridentifier-separation-context
> 
> This reference could close this ticket.

Consider the following scenario:

   EID1 --- xTR1 ---PE--TE-xTR....             xTR2---EID2
                                                     /
                                                 xTR3
      Site1          ISP-1     Internet   ISP2   Site 2

EID1 sends a packet to EID2. xTR1, which belongs to Site1 (the same
site that contains EID1), issues Map-Request for EID2, and ultimately
gets Map-Reply with xTR2 and xTR3 as the RLOCs. xTR1 selects xTR2,
so xTR1 encapsulates the packet with the LISP header and the xTR2
as the Dest RLOC.

ISP-1 deploys TE-xTR for the purpose of inbound traffic engineering.
This TE-xTR is an ASBR that connects ISP-1 to some other ISP.
Specifically the function of TE-xTR is to make sure that the return
traffic (from EID2 to EID1) enters ISP-1 through this TE-xTR.

Please describe *in details* how this could be accomplished for 
the following two cases:

(1) return traffic from EID2 to EID1 goes via xTR2 
(2) return traffic from EID2 to EID1 goes via xTR3.

Also, keep in mind that Site1 could be multi-homed to two ISPs
(the second ISP is not shown in the above example).

Yakov.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 01 Jun 2010 12:07:37 -0400

I think that this may ask the quesiton in a way that makes it hard to 
answer, without being mroe clear.

Policies about EIDs, and traffic based on EIDs, are up to the sites 
using those EIDs.
Policies about RLOCs, and transiting traffic using those RLOCs, is the 
business of the ISPs providing that transit.

So the ISP policy can be about traffic (in either direction) between 
RLOC1 and RLOC2 or RLOC3.
The ISP does not have policies about, nor visiblity to, the EIDs used by 
the sites.

This same confusion has come up in other multi-homing contexts. 
Basically, one of the useful sideffects of cleanly supporting 
multi-homing and separating it from connectivity is that the customer 
gets to decide which access he uses, and the ISP gets to decide what 
path is used to deliver traffic to / within the ISP relative to that access.

Yours,
Joel

Yakov Rekhter wrote:
....
> ------------------------------------------------------------------------
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 03 Jun 2010 23:57:37 +0200

Yakov,
> so xTR1 encapsulates the packet with the LISP header and the xTR2

The current lisp-7 draft mentions the possibility of using a
TE-ITR/TE-ETR with an additional level of encapuslation, but the details
are not specified. I think that with a single level of encapsulation we
can already provide lots of TE capabilities for both inbound and
outbound flows.

> traffic (from EID2 to EID1) enters ISP-1 through this TE-xTR.

In LISP, Site1 controls its incoming flow by changing the weights,
preferences and possibly replying with different Map-Reply for
differrent EIDs or different xTRs. This already gives a lot of
flexibility to the sites and far better TE capabilities from both a
dynamicity viewpoint and a scalability viewpoint than the existing
BGP-based traffic engineering techniques.

In this example, ISP1's objective is to carry the packets to and from
xTR1. If necessary, it can use the existing TE capabilities (BGP, MPLS,
...). I don't think that ISP1's traffic engineering should depend on the
source or the destination EID of the encapsulated packets that it carries.

> (2) return traffic from EID2 to EID1 goes via xTR3.

Site1, even if it is multihomed, can force the packets coming from xTR2
and xTR3 to return via xTR1 and not another xTR by sending a specific
Map-Reply to both xTR2 and xTR3.

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 4 Jun 2010 09:13:17 -0700

Olivier,

> are not specified. 

That is precisely the problem that is raised in the comment.

> I think that with a single level of encapsulation we

In this example ISP1's objective is to carry the traffic going to
Site 1 via TE-xTR. ISP1 can certainly use the existing TE capabilities,
but (stating the obvious) these are *not* LISP's TE capabilities.

Yakov.