[RAM] Re: question about LISP v1

[Dino Farinacci <dino at cisco.com>]

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

CAR is defined in the CONS reference. Will fix the typo. Nice find.

> 	Why do you set Originating ITR RLOC Address to zero for
> UDP-based messages? What are its other possible values?

Because in LISP 1.5 the Map-Request is being originated by the ITR  
itself. In CONS, the ITR sends the Map-Request over a TCP connection  
to the CAR and when the CAR receives the Map-Reply back it needs to  
route the Map-Reply to the originating ITR.

Hence we have to preserve the identity of the ITR.

> 	What is a Path Vector List? Its description is missing.

See the CONS reference. I will make sure I refer to it in this spec.

> 	You say LISP Nonce is 6 bytes long, in Map-Request Message
> Format it's just 5 bytes.

The description says it is 6 bytes even though it looks like it is  
drawn as 5 bytes. The intent is 6 bytes. I will fix the packet format  
illustration.

> 	(Why the LISP Nonce is 6 bytes long? Any reasons?)

Wanted it longer than 32-bits and didn't see a need for 64-bits.

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

The 'Locator Count' field 8 bits in width per EID-prefix record.

> then using Record count and Locator count fields is redundant. If  
> many,

Record count is there to allow you encode multiple mappings, each  
mapping has one EID-prefix associated with a locator-set. The number  
of locators in a locator-set is determined by the 'Locator Count' field.

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

No, not true.

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

Thanks for the careful reading. I have fixed all of the above  
occurrences and will be reflected in the -02 update of the draft.

> Thank you.
>
> Ved Kafle @NICT, Japan

Thank you,
Dino

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