Subject: Re: [lisp] draft-ietf-lisp #113 (new): inbound traffic engineering support with LISP

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 15 Feb 2011 18:45:45 -0000

#113: inbound traffic engineering support with LISP

Comment(by yakov@…):

 To add to the above, there should be a detailed description of how TE-xTR
 perform traffic engineering. This description should be sufficient to
 address the questions I raised in my e-mail to the LISP WG mailing list on
 6/1/2010.

-- 
------------------------------+---------------------------------------------
Reporter:  yakov@…            |       Owner:                 
    Type:  technical          |      Status:  new            
Priority:  major              |   Component:  draft-ietf-lisp
Severity:  -                  |    Keywords:                 
------------------------------+---------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/113#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 17 Feb 2011 23:48:06 -0800

So we believe the usage guide will be a good place to put  
configuration details on how to use LISP for traffic engineering  
purposes.

Having said that, we have these detailed references in draft-ietf- 
lisp-09.txt:

(1) In the section describing priority and weight values in Map-Reply  
messages for both unicast and
     multicast flows:

    Priority:  each RLOC is assigned a unicast priority.  Lower values
       are more preferable.  When multiple RLOCs have the same priority,
       they may be used in a load-split fashion.  A value of 255 means
       the RLOC MUST NOT be used for unicast forwarding.

    Weight:  when priorities are the same for multiple RLOCs, the weight
       indicates how to balance unicast traffic between them.  Weight is
       encoded as a relative weight of total unicast packets that match
       the mapping entry.  If a non-zero weight value is used for any
       RLOC, then all RLOCs MUST use a non-zero weight value and then  
the
       sum of all weight values MUST equal 100.  If a zero value is used
       for any RLOC weight, then all weights MUST be zero and the
       receiver of the Map-Reply will decide how to load-split traffic.
       See Section 6.5 for a suggested hash algorithm to distribute load
       across locators with same priority and equal weight values.

(2) In the Routing Locator Selection section:

    Both client-side and server-side may need control over the selection
    of RLOCs for conversations between them.  This control is achieved  
by
    manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
    messages.  Alternatively, RLOC information may be gleaned from
    received tunneled packets or EID-to-RLOC Map-Request messages.

    The following enumerates different scenarios for choosing RLOCs and
    the controls that are available:

[there are 5 bullet paragraphs that follow, see the spec since there  
is too much text to incorporate here].

(3) This paragrapgh in the Deployment Scenarios section 8:

    o  Recursive tunneling is when tunneled traffic is again further
       encapsulated in another tunnel, either to implement VPNs or to
       perform Traffic Engineering.  When doing VPN-based tunneling, the
       site has some control since the site is prepending a new tunnel
       header.  In the case of TE-based tunneling, the site may have
       control if it is prepending a new tunnel header, but if the  
site's
       ISP is doing the TE, then the site has no control.  Recursive
       tunneling generally will result in suboptimal paths but at the
       benefit of steering traffic to resource available parts of the
       network.

Using tunnels with stretch greater than 1 can avoid congestion on the  
shortest paths. Much like repair LSPs in MPLS.

Dino

On Feb 15, 2011, at 10:45 AM, lisp issue tracker wrote:

> ------------------------------ 
> +---------------------------------------------
> ------------------------------ 
> +---------------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/113#comment:1 
> >
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Stefano Secci <[email-masked]>
Date: Fri, 18 Feb 2011 16:05:20 +0100

FYI - here are academic papers about coordinated RLOC weight setting for edge2edge traffic engineering (via ranking of transit paths):
http://www-phare.lip6.fr/~secci/papers/SeLiRaJa-ICC11.pdf 
http://www-phare.lip6.fr/~secci/papers/E2E-TE.pdf (practical aspects in sect. VII)

Stefano

Le 18 févr. 2011 à 08:48, Dino Farinacci a écrit :

> So we believe the usage guide will be a good place to put configuration details on how to use LISP for traffic engineering purposes.
> 
> Having said that, we have these detailed references in draft-ietf-lisp-09.txt:
> 
> (1) In the section describing priority and weight values in Map-Reply messages for both unicast and
>    multicast flows:
> 
>      RLOC, then all RLOCs MUST use a non-zero weight value and then the
>   of RLOCs for conversations between them.  This control is achieved by
> [there are 5 bullet paragraphs that follow, see the spec since there is too much text to incorporate here].
> 
>      control if it is prepending a new tunnel header, but if the site's
> Using tunnels with stretch greater than 1 can avoid congestion on the shortest paths. Much like repair LSPs in MPLS.
> 
> Dino
> 

-- 
Stefano Secci
Associate Professor
PHARE - LIP6 - UPMC - Sorbonne Universités
Bureau 25-26/318, Boite Courrier 169
4 place Jussieu, 75005 Paris, France
Tel:  +33 (0) 1 4427 3678
Fax:  +33 (0) 1 4427 8783
http://www-phare.lip6.fr/~secci/

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 21 Feb 2011 11:48:12 -0800

Dino,

> Having said that, we have these detailed references in draft-ietf- 

This is all fine. But as I said in my comment, I'd like to see
*detailed* answers to the questions I raised in my e-mail to the
LISP WG mailing  list on 6/1/2010. Having "these detailed references"
is not sufficient.

Yakov.

> > address the questions I raised in my e-mail to the LISP WG mailing  
> > list on 6/1/2010.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Feb 2011 16:08:04 -0800

> LISP WG mailing  list on 6/1/2010. Having "these detailed references"

There were a lot of references. Please call them out in a reply to  
this email. That would make it easier to know what you are referring to.

Dino