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

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Mar 2011 14:01:53 -0400

Yakov,  I have looked at the ticket, and the email exchange captured below.
Given that the deployment document talks about the scope over which LISP 
TE works;
and given that the LISP documents talk about priority and how that 
affects the steering of traffic;
I do not understand what more you are asking for.  The LISP document 
should not be expected to become a traffic engineering tutorial, even if 
that (TE) is one of the possible uses of LISP.

can you please clarify what you are looking for?

Thank you,
Joel

On 2/21/2011 2:48 PM, Yakov Rekhter wrote:
> Dino,
>
>> 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:
>
> 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.
>
>>
>> (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:
>>
>>> #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
>>> _______________________________________________
>>> lisp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>>
>>
>>
>> _______________________________________________
>> lisp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lisp

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 21 Mar 2011 17:59:10 -0700

Joel,

> can you please clarify what you are looking for?

Given that the use of LISP for TE is documented in the deployment
document, please add a pointer to the deployment document at the end of
the following sentence in Section 4:

                                                             An obvious
   instance of this would be an ISP router that needs to perform traffic
   engineering for packets flowing through its network.

Yakov.