Subject: [lisp] #32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review

From: "lisp issue tracker" <[email-masked]>
Date: Tue, 20 Apr 2010 07:38:34 -0000

#32: Editorial Issues Section 6 of draft-ietf-lisp-06.txt raised by Dimitri
Papadimitriou in his review
------------------------------------------+---------------------------------
Reporter:  luigi@…                        |       Owner:                 
    Type:  editorial                      |      Status:  new            
Priority:  trivial                        |   Component:  draft-ietf-lisp
Severity:  -                              |    Keywords:                 
------------------------------------------+---------------------------------
 Section 6.2 introduces the terms client-side and server-side where are
 these terms defined ? without such definition readability of the
 section is low.

 Section 6.2 RLOC reachability can determined and selected but there is
 no description on how the EID-to-RLOC selection is performed.

 Section 6.3.2 states “RLOC Probing can also provide RTT estimates
 between a pair of locators which can be useful for network management
 purposes as well as for selecting low delay paths.” If the exchanges
 are performed in the control plane it is not clear how such RTT/delay
 values can be derived for the forwarding path ? Can authors explain ?
 Authors should also check the accuracy of the estimate vs overhead
 generated by such technique.

 Section 6.5 the section does not actually explain which messages are
 used to update the list of Loc-Reach or Loc-Status bits. If it is data
 traffic-driven then the mechanism is again dependent on the symmetry
 of the reverse path and the packet rate but also packet differential
 delays between packets. In the latter case, it is not clear how ITR
 could retrieve the correct RLOCs to be used if a sequence of 8 packets
 sent from ETR to ITR indicates 0,0,0,0,0,0,0,1 for a given RLOC
 (indicated as available at arrival of the 8th packet) is received as
 1,0,0,0,0,0,0,0. The section makes a long digression on ordering
 locator set this is not the issue without a sequence number it will
 never be possible for the receiving ITR to determine the actual state
 of the EID-to-RLOC mappings at ETRs. This is even if ETR do not keep
 track of who requested mappings upon communication they should tell
 the state of their mapping but also their transition.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/lisp/trac/ticket/32>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 07:37:24 -0000

Comment(by luigi@…):

 '''Yakov Rekhter raises a related question in his review of draft-ietf-
 lisp-06.txt (part 2):'''

 Section 6.2

 This section uses "client-side" and "server-side" extensively without
 defining the terms. They seem to be the same as "ITR" and "ETR" in the
 rest of the document. Terminology should be defined or harmonized with
 the rest of the document.

-- 
Ticket URL: <http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/32#comment:1>
lisp <http://tools.ietf.org/lisp/>
LISP WG document issues

---

From: "lisp issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 12:42:59 -0000

> the state of their mapping but also their transition.

New description:

--

Comment(by luigi@…):

 '''Yakov Rekhter raises related editorial issues in his review of draft-
 ietf-lisp-06.txt (part 2):'''

 Section 6.3.2

  cached by the ITR or PTR. The ITR or PTR may include a mapping data
  record for its own database mapping information.

 What exactly is "its own database mapping information" ?

 Section 6.4

  Note that when a packet is LISP encapsulated, the source port number
  in the outer UDP header needs to be set. Selecting a random value
  allows core routers which are attached to Link Aggregation Groups
  (LAGs) to load-split the encapsulated packets across member links of
  such LAGs. Otherwise, core routers would see a single flow, since
  packets have a source address of the ITR, for packets which are
  originated by different EIDs at the source site. A suggested setting
  for the source port number computed by an ITR is a 5-tuple hash
  function on the inner header, as described above.

 "Random" in the second sentence is contradicted by the last sentence.

 Also, it is not clear why the paragraph restricts itself to talking
 about LAGs. Load balancing is used plenty of other places.

 Section 6.5

 As a general comment, this section is in need of some editing to make
 the prose more readable.

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

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 21 Apr 2010 22:59:06 +0200

Hi Luigi,

Some comments classified as "editorial" often translate
under-specification (or specification that is difficult to understand);
so, conservative approach consisted in asking clarification(s).

An example: in Section 6.5 clearly states that mappings maintenance and
processing is traffic driven (whereas EID processing is configuration
driven and RLOC reachability is topology driven). EID and RLOC follows
traffic between TR that "hosts" them. Synchronizing EID and RLOC based
on traffic leads to selection of mappings that are invalid in case of
change in EID and RLOC as long as source ITR are not made not aware of
these changes by means of arrival of traffic (thus, such changes may
never be received by source ITR due to either unidirectional or
asymmetric path) or solicited cached entries replacement/time-out. 

Hence, the question related to Section 6.2/6.3 concerning the
association of the RLOC to the RLOC part of the mapping (and the
association of the EID to the EID part of the mapping in Section 6.1)
knowing the strong condition imposed by Section 6.5: RLOC reachability
is driven by topology and controlled by ITR and EID-to-RLOC mapping is
driven by  traffic and controlled by ETR -> how the association between
received EID-to-RLOC mapping and RLOC local information is performed,
maintained over time at the ITR and how selection is actually performed
among multiple locators ?

Thanks,
-dimitri.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of lisp issue tracker
> Sent: Wednesday, April 21, 2010 9:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lisp] #32: Editorial Issues Section 6 of 
> draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review
> 
> Reporter:  luigi@...                        |       Owner:      
>            
> Comment(by luigi@...):
> Ticket URL: 
> <http://zinfandel.levkowetz.com/wg/lisp/trac/ticket/32#comment:1>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 22 Apr 2010 13:30:12 +0200

Hi Dimitri,

Issue #32 has been modified yesterday and split in several technical issues, so that each one can be discussed separately.

Ciao

Luigi

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 12:05:41 -0000

Comment(by luigi@…):

 Replying to [comment:1 luigi@…]:

 '''This is part of Comment 26 of Rekhter's review'''

 lisp-06.txt (part 2):'''

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 12:15:48 -0000

Comment(by luigi@…):

 Replying to [comment:2 luigi@…]:

 ''' This is Comment 30 of Rekhter's review'''

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 12:17:07 -0000

Comment(by luigi@…):

 '''This is Comment 31 of Rekhter's review'''

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

---

From: "lisp issue tracker" <[email-masked]>
Date: Thu, 22 Apr 2010 12:18:40 -0000

Comment(by luigi@…):

 '''This is part of Comment 32 of Rekhter's review'''

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