[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RAM] RE: question about LISP v1



Hi Dino,

I have the following questions and comments on LISP v01.

Section 6.1.1

	What is a CAR? Its description is missing.
	ITR-AFI and CAR-AFI has the same description. How to distinguish
them?
	Why do you set Originating ITR RLOC Address to zero for
UDP-based messages? What are its other possible values?
	What is a Path Vector List? Its description is missing.
	You say LISP Nonce is 6 bytes long, in Map-Request Message
Format it's just 5 bytes. 
	(Why the LISP Nonce is 6 bytes long? Any reasons?)

Section 6.1.3
	How many Locs can be included in each Rec? How to know that
there are many Locs in each Rec? If there is only one Loc in each Rec,
then using Record count and Locator count fields is redundant. If many,
then the Locator count field should be inside Rec. In that case, the
total number of locators would be equal to the summation of number of
Recs multiplied by the number of Locs in each Rec.

Some typos:
----------------------
Section 4.1
(First line )  ... unicast unicast packet flow ... 
(Last para) ... section Section 6 ...
Section 6.1.1
Record count:  ... the a number of times .
Section 6.1.3
Record Count: The number of records in this request message => or reply
message?

Thank you.

Ved Kafle @NICT, Japan


> -----Original Message-----
> From: Dino Farinacci [mailto:dino at cisco.com] 
> Sent: Saturday, July 07, 2007 9:00 AM
> To: marcelo bagnulo braun
> Cc: ram at iab.org
> Subject: [RAM] Re: question about LISP v1
> 
> 
> > How does an initiator node informs the receiver about its multiple
> > RLOCs?
> 
> This has not changed from the -00 draft. the receiver can glean *a*  
> locator from the packet it is decaping (the ETR that is). If the ETR  
> wants the complete set of locators with their associated priorities  
> and weights, it must either 1) send a packet returning with 
> the outer  
> DA equal to the inner DA (I call this a data probe) or 2) if 
> there is  
> a mapping service in place, do a lookup to get the mapping.
> 
> For the later, if LISP-NERD is used, the lookup is local the the ITR  
> since the mappings are pushed. If LISP-CONS is used, a 
> Map-Request is  
> sent by the ITR to it's configured CAR over a TCP connection.
> 
> > I mean, in the described packet flow sequence, the initiator sends
> > a LISP data packet containing its EID and RLOC in the source  
> > address fields of the inner and outer header, and this is how the  
> > receiver ETR learns about the EID-to-RLOC mapping of the 
> initiator.  
> > However, this only conveys a single RLOC, what happens if the  
> > initiator has multiple RLOCs (the most common in a 
> multihomed site)  
> > and wants to inform the receiver ETR about them?
> 
> Right, the ETR has some flexibility here. It can use the single  
> locator to return packets while in parallel send a 
> Map-Request to get  
> the rest of them. When the ITR is sending packets this ETR, the  
> Locoator Reachability bits are continually updated for each packet  
> the ITR encaps to the ETR. So the ETR will know the 
> reachability status.
> 
> There is a detail about which loc-reach-bit to associated with the  
> outer SA but I can tell you about that offline.
> 
> > In the previous version of LISP, it was possible for the initiator
> > to send an unsolicited Map-Reply message containing the whole RLOC  
> > set to the receiver.
> 
> No, it was never unsolicited, because the sender of the Map-Reply  
> would not know where to send it.
> 
> > however, the current version includes the nonce, so Map-reply
> > messages can only be sent as replies to data packets or map 
> request  
> > messages. So, does this means that
> 
> The -01 draft uses both the fact that the Nonce much match as 
> well as  
> the ITR keeping a local cached entry for the EID in a "incomplete"  
> state. Similar to how some ARP implementations are coded.
> 
> > the initiator cannot inform spontaneously of its locator set and
> > must wait for the receiver to ask for it? or there is a mean for  
> > the initiator to send the locator set to the receiver even if the  
> > receiver haven't asked for it?
> 
> The Map-Reply is never sent unsolicited.
> 
> Dino
> 
> _______________________________________________
> RAM mailing list
> RAM at iab.org
> https://www1.ietf.org/mailman/listinfo/ram
> 



_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram