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

From: [email-masked] (Noel Chiappa)
Date: Wed, 27 May 2009 09:26:17 -0400 (EDT)

> From: Olivier Bonaventure <[email-masked]>

    > not all fields of the LISP header are useful for both data and control
    > packets. ... there is no utilisation of the Nonce for data encapsulated
    > packets .. except for data probes.
    > ...
    > It might be useful to consider a different structure for the LISP
    > header used in data encapsulated packets and .. in control packets or
    > define some utilisation of the Nonce field in all data encapsulated
    > LISP packets.

There has been some offline discussion about using the nonce field to
piggyback RLOC reachability testing on user data traffic, because detecting
reachability failures is a definite concern.

I.e. just because an ETR E is up, and is exchanging traffic with other nodes,
there may be something in the network - perhaps a misconfigured access
control setting somewhere - that prevents traffic directly from from ITR I to
ETR E from getting to ETR E. This sort of thing would cause mysterious packet
black-holing, if there is a specific mechanism to detect it - but explicit
pinging (such as routers use to detect that their neighbours are up) is felt
to be too much overhead, as the xTR fanout is likely to be much larger.

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.

	Noel

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 06:34:14 -0700

Noel,

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 6:26 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lisp] Comments about the LISP header
> 
> 

Maybe I am misunderstanding, but how can ITR I know that
the path to ETR E is down without testing it? It doesn't
seem feasible that some 3rd party observer could know
anything about I->E path characteristics, for example.

You also cite explicit pinging overhead, but if the
ping is piggybacked on top of ordinary data packets
the overhead is perhaps not so much.

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 27 May 2009 11:09:16 -0400

> reachability failures is a definite concern.

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.

---

From: David Meyer <[email-masked]>
Date: Wed, 27 May 2009 08:52:52 -0700

> the xTR that sends the reachability request will never see the returned ACK.

	There are various ways to solve the "square routing"
	problem (such as observing the ratio of outgoing SYNs to
	ACKs). 

	Dave

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 27 May 2009 18:12:31 +0200

Noel,
> number of other techniques.

I think that another question that we will need to answer also is
whether reachability is sufficient.

For example, consider a site one ITR that is sending packets towards and
EID served by two ETRs : ETR1 and ETR2. Both ETR1 and ETR2 are reachable
from ITR, but the path between ITR and ETR1 is heavily congested or uses
a low quality wireless link, leading to 30% packet losses while the path
towards ETR2 is not congested at all. Will ITR use both paths since they
are reachable or should it try to detect the packet losses and avoid the
lossy path ?

Olivier

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 08:16:49 -0700

> From: Scott Brim [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 8:09 AM
> To: Noel Chiappa
> Cc: [email-masked]

Huh? xTR2 simply sends an ACK back to xTR1 within locator
space (not eid space). The test is unidirectional, but the
network is connected so xTR2 can reach xTR1 along the
reverse path within locator space.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 09:41:45 -0700

Oliver,

> From: Olivier Bonaventure [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 9:13 AM
> To: Noel Chiappa
> Cc: [email-masked]

OK, so here's a good use for the SEAL sequence number. If
the ETR tracks the SEAL sequence numbers it sees from a
particular ITR it can report back the %packet loss when
the ITR asks for an acknowledgement. Would something like
that help?

Fred

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 27 May 2009 10:22:00 -0700

> > For example, consider a site one ITR that is sending packets
towards
> and
> OK, so here's a good use for the SEAL sequence number. If the 
> ETR tracks the SEAL sequence numbers it sees from a 
> particular ITR it can report back the %packet loss when the 
> ITR asks for an acknowledgement. Would something like that help?
> 

I can't see how requiring an ETR to keep state for all the ITRs that
send it data is scalable.  

-Darrel

--------------------------------------------
All IETF attendees have conflicts of interest.  The only difference
between them is that some admit it.  I myself deny it.  --Darrel Lewis
(with apologies to H.L. Mencken)
--------------------------------------------

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Wed, 27 May 2009 10:52:17 -0700

Fred,

> > >
> > > OK, so here's a good use for the SEAL sequence number. If the ETR 
> > > tracks the SEAL sequence numbers it sees from a particular ITR it 
> > > can report back the %packet loss when the ITR asks for an 
> > > acknowledgement. Would something like that help?
> > >
> > 
> This need not be phrased as a requirement; ETRs that can't 
> keep state can simply inform the ITR of this deficiency in its acks.
> 

But sending ack's in the first place implies you kept enoug state to
know who to send the ack to!

-Darrel

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 11:21:15 -0700

Darrel,

> From: Darrel Lewis (darlewis) [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2009 10:52 AM
> To: Templin, Fred L; [email-masked]; Noel Chiappa
> Cc: [email-masked]
> Subject: RE: [lisp] Comments about the LISP header
> 
> Fred,
> 
> > > >
ETR
> know who to send the ack to!

No it doesn't; sending an ack is no different than sending
an ICMP, and all that is needed for that is the packet that
triggered the ICMP.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 May 2009 10:28:11 -0700

Darrel,

> Sent: Wednesday, May 27, 2009 10:22 AM
> > > from ITR, but the path between ITR and ETR1 is heavily congested
or
> > uses
> > > a low quality wireless link, leading to 30% packet losses while
the
> > path
> > > towards ETR2 is not congested at all. Will ITR use both paths
since
> > they
> > > are reachable or should it try to detect the packet losses and
avoid
> > the

This need not be phrased as a requirement; ETRs that
can't keep state can simply inform the ITR of this
deficiency in its acks.

Fred