Subject: Re: [lisp] Comments about the LISP header

From: [email-masked] (Noel Chiappa)
Date: Wed, 27 May 2009 11:15:40 -0400 (EDT)

> From: Scott Brim <[email-masked]>

    > What if traffic leaves site A via xTR 1 and enters site B via xTR 2 ...
    > but the return traffic leaves B via xTR 3 and enters A via xTR 4? Then
    > the xTR that sends the reachability request will never see the returned
    > ACK.

Hence my prior comment:

    >> Piggybacking reachability detection on user data traffic is not a
    >> perfect solution, but it seems that it might be a useful tool, when
    >> combined with a number of other techniques.

Before we start fine-tuning the mechanism-set, though, I think we need to
get some practical experience - see how often that scenario happens IRL,
etc.

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 May 2009 11:21:49 -0400

Conversely, this seems to introduce two design problems simultaneously.
1) including a feature we don't know the use for.
2) Having a header with significant difficulty in changing it, when we 
are still experimenting with what needs to be in the header.

Joel

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

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 May 2009 22:33:15 +0200

Noel,
> get some practical experience - see how often that scenario happens IRL,

The RIPE TTM service could be a good way to evaluate the evolution of
reachability among pairs of routers. RIPE TTM implements the
measurements defined by the IPPM wg and the testbox are hosted by ISPs,
mainly in Europe.

RIPE TTM uses one way delay measurements with GPS clocks. Compared to
traditionnal ping measurements, this has the advantage of showing when
one direction between two testbox is working while the other is not.

On IPv4 testboxes, it seems that only one pair suffers from
unidirectionnal failures :
tt7 to tt111 reports 100% losses
http://www.ripe.net/ttm/Plots/plots.cgi?ipv=4&url=map_index.cgi&base=tt111&src=tt07&dst=tt111

while the opposite direction shows only very few losses
http://www.ripe.net/ttm/Plots/plots.cgi?ipv=4&url=map_index.cgi&base=tt07&src=tt111&dst=tt07

Concerning IPv6, the situation is worse and there are more pairs of
tesboxes with unidirectionnal reachability only.

http://www.ripe.net/ttm/Plots/summary.cgi?ipv=6&sortfield=marked+cells&sortkey=relative+change&sortorder=descending&format=html&threshold=+40.0&unit=percent&boxname=tt07&file=weeksummary.xml

This is likely because IPv6 is not currently considered by all owners of
testboxes as a production service like IPv4.

It could be interesting to study the RIPE TTM data to see whether the
failure of a unidirectionnal path is frequent and how long it lasts.

Olivier

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 27 May 2009 14:45:49 -0700

> 2) Having a header with significant difficulty in changing it, when  
> we are still experimenting with what needs to be in the header.

Well, before anyone suggests this, we are not going to TLV the data  
header. So we have to live with changes. Or, conversely, don't make  
any changes.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 28 May 2009 10:37:16 -0400

Hi Dino,

> header. So we have to live with changes. Or, conversely, don't make  

I'm not sure who "we" are in the sentence above...  The WG could  
decide to define a TLV-format header if the WG thought there was a  
good reason to do that.  At the moment, though, I don't think that  
anyone has suggested changing the header to a TLV format.  I think  
that what Joel suggested (indirectly) was that we add a version number  
to the header.

I do think it makes sense to add a version number field to the LISP  
data header, and to all other LISP headers,  so that we will have a  
well-defined way to change the headers later if that is necessary.   
This is, IMO, good engineering practice.  It would also allow us to  
remove the overhead of any fields in the LISP data header that have no  
defined use now, as they could be added in new versions of the header  
later, if/when we decide that we need them for a defined purpose.

The LISP data header is currently fixed-length, so I don't think there  
is any need for a header length field in this version.   A length  
could be added in a future version, though, if we ever decide to  
define a variable-length LISP data header.

Margaret

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 May 2009 08:10:41 -0700

Margaret,

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Thursday, May 28, 2009 7:37 AM
> To: Dino Farinacci
> Cc: [email-masked]
> Subject: Re: [lisp] Comments about the LISP header
> 
> 
> Hi Dino,
> 

Sounds reasonable. If we had only 32 bits to work with,
how many would we need to encode a version number.
Is 2bits enough?

Fred
[email-masked]