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

From: [email-masked] (Noel Chiappa)
Date: Wed, 21 Apr 2010 17:48:08 -0400 (EDT)

> From: "PAPADIMITRIOU Dimitri" <[email-masked]>

    > EID processing is configuration driven

Sorry, what is "EID processing"?

    > EID and RLOC follows traffic between TR that "hosts" them.

Do you mean 'EID->RLOC mappings'? EIDs and RLOCs by themselves don't move
anywhere, so they can't "follow" anything to anywhere.

    > Synchronizing EID and RLOC based on traffic

Sorry, I simply do not understand what you mean here. 

    > in case of change in EID and RLOC

Do you mean 'a change in EID->RLOC mappings'?

    > 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)

If you mean what I am guessing you mean, that's why user data packets carry
the 'mapping version number' (of the mapping being used by the source ITR for
that destination EID) in the header (in some packets), so that the
destination ETR can detect that the source ITR is using an old mapping. The
destination ETR can then notify the source ITR that it needs to update its
mapping.

    > 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 ?

Again, I am having a hard time understanding clearly what you mean here,
which makes it hard for me to answer.

	Noel

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 22 Apr 2010 00:35:50 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Noel Chiappa
> Sent: Wednesday, April 21, 2010 11:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lisp] #32: Editorial Issues Section 6 
> ofdraft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review
> 
> 
>     > From: "PAPADIMITRIOU Dimitri" 
> <[email-masked]>
> 

EID allocation.
 
> anywhere, so they can't "follow" anything to anywhere.

"follows" means here that traffic flows drive information received by
ITR about changes in EID(-to-RLOC) and RLOC values.

> Do you mean 'a change in EID->RLOC mappings'?

"Synchronizing EID(-to-RLOC) and RLOC based on traffic leads to
selection of mappings..."

> destination ETR can then notify the source ITR that it needs 

If and only if, the source ITR receives traffic back from the ETR to
which this ITR sends traffic. Secondly, any selection of an alternate
ETR may bring a "older version" of the mapping (as "ETRs do not keep
track of who requested its mappings").

> which makes it hard for me to answer.

Even if RLOC reachability can be maintained by means of a set of
existing mechanisms it is still does not tell anything about the
associated EID-to-RLOC. The only updated information about EID-to-RLOC
is the one driven by traffic flows. Reconciling both remains unadressed
in this document.

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