Subject: [lisp] last call for draft-ietf-lisp-map-versioning-01

From: Terry Manderson <[email-masked]>
Date: Sun, 1 May 2011 17:07:58 -0700

All,

The authors of draft-ietf-lisp-map-versioning-01 have requested a work group
last call.

Here starts the last call for this document, Joel and I will end the last
call on Monday the 16th May, 2011.

Please review the draft and provide any last comments.

Cheers
Terry

---

From: John Scudder <[email-masked]>
Date: Mon, 2 May 2011 14:15:01 -0700

Terry, Joel,

I realize I haven't been a frequent contributor but as you know, last calls tend to bring out infrequent contributors.  

I'm very surprised to see a last call issued for seven different documents, all to end the same day two weeks from now.  It's clearly impractical to review all seven in the time provided.  I don't think I've ever seen this kind of WGLC onslaught before -- the customary thing is to stagger the last calls to reflect a more reasonable workload.

May I suggest you revise the schedule you've proposed?

Thanks,

--John

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 02 May 2011 17:23:02 -0400

Since the documents are related to each other, it would be very hard to 
define any particular staggering that would work well for all readers. 
(I have seen other working groups do much the same thing.)

I will note that the changes made in the last several versions of these 
documents have been entirely editorial.  And we have been clear that the 
last call was coming.

Still, if folks actually comment on some of the documents, and request 
longer to look at the rest, the chairs will of course consider extending 
the last call.  The goal is to make sure meaningful issues are 
addressed.  We would very much like to end these last calls, and prepare 
to bury our AD in material, as soon as possible.

Yours,
Joel

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 May 2011 18:14:02 -0400

I think this draft is in good shape.  Enclosed are my comments and questions:

a) Sec 7. last paragraph: I think that the sentences after the first
one (given below) reflect old draft state and isn't necessary with the
versions that are being last-called.
   "Furthermore, existing and future mapping distribution protocol
   (e.g., ALT [I-D.ietf-lisp-alt]) are able to carry version numbers
   without needing any modification.  The same applies to the LISP Map
   Server ([I-D.ietf-lisp-ms]), which will still work without any
   change since reserved bits are simply ignored."

Those may have been reserved bits, but they no longer are in [LISP]
and neither the [ALT] or [MS] define the packet format or refer to
those bits as being reserved.

b) Sec 8.5 "what proposed in the present section is just a case study
   and MUST NOT be considered as specification for a lightweight LISP
   implementation."

This does seem very useful to me.  What does its status as a case
study mean in the context of all the drafts being experimental??

Is this because supporting Map Versioning is optional?

c) How are ETRs expected to coordinate their Map-Version Number?

Looking forward to your responses,
Alia

On Sun, May 1, 2011 at 8:07 PM, Terry Manderson
<[email-masked]> wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 16 May 2011 18:30:22 -0400

Joel,

More time would certainly be useful.  While I have reviewed and
provided feedback
on the drafts, I do not think I've had sufficient time to think
through all the implications
and scenarios of interest.

Thanks,
Alia

On Mon, May 2, 2011 at 5:23 PM, Joel M. Halpern <[email-masked]> wrote:
> define any particular staggering that would work well for all readers. (I
> have seen other working groups do much the same thing.)
>
> longer to look at the rest, the chairs will of course consider extending the
> last call.  The goal is to make sure meaningful issues are addressed.  We
> would very much like to end these last calls, and prepare to bury our AD in
> material, as soon as possible.
>
> Yours,
> Joel
>
>> I realize I haven't been a frequent contributor but as you know, last
>> calls tend to bring out infrequent contributors.
>>
>> I'm very surprised to see a last call issued for seven different
>> documents, all to end the same day two weeks from now.  It's clearly
>> impractical to review all seven in the time provided.  I don't think I've
>> ever seen this kind of WGLC onslaught before -- the customary thing is to
>> stagger the last calls to reflect a more reasonable workload.
>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 May 2011 15:35:20 -0700

Awesome review comments Alia. Thanks so much for putting the huge  
effort in. We will get responses back to you.

Dino

On May 16, 2011, at 3:30 PM, Alia Atlas wrote:

>>>> The authors of draft-ietf-lisp-map-versioning-01 have requested a  
>>>> work
>>>> group
>>>> last call.
>>>>

---

From: Terry Manderson <[email-masked]>
Date: Mon, 16 May 2011 22:50:56 -0700

Hi Alia,

Joel and I have spoken and given that you have put in substantive effort in
reviewing the documents (and it is appreciated) we will extend the last call
on the LISP-* documents until midnight Friday 20th May to ensure sufficient
time is given to think through, as you put it, the implications and
scenarios of interest.

Cheers
Terry

---

From: Uma Devi Bandaru <[email-masked]>
Date: Tue, 17 May 2011 10:54:18 -0700

While I was going through the main LISP spec, I have noticed that the 
length of the Source EID address, as specified in the Map-request 
message format is 16 bytes. Shouldn't it be 32 bytes even for an IP V4 
address? And the same is true with the ITR-RLoc address. I might be 
missing something here. Can any one clarify this for me?

Thanks,
Uma Bandaru,

On 5/16/2011 10:50 PM, Terry Manderson wrote:
> On 17/05/11 8:30 AM, "Alia Atlas"<[email-masked]>  wrote:
>
>> Joel,
>>
>> On Mon, May 2, 2011 at 5:23 PM, Joel M. Halpern<[email-masked]>  wrote:

-- 
Thanks,
Uma Bandaru

---

From: Uma Devi Bandaru <[email-masked]>
Date: Tue, 17 May 2011 11:17:09 -0700

Sorry, my apologies. Changing the subject to address fields.

I basically have two questions:

How is the source AFI populated for a given address field (Ipv4 / 
IPv6)?  In other words, how to determine the address family (IPv4 or 
IPv6) from the source AFI field?
And secondly, the length of Source EID address is specified as only 16 
bits in the Map-request message. So how does one encode the 32 bit (or 
128 bit for IPv6) address into  the 16 bit field? And the same is true 
with ITR- RLoc AFI and ITR-RLoc address.

I apologize for the typo (byte instead of bit) in my previous email.

Thanks,

Uma Bandaru.

-- 
Thanks,
Uma Bandaru

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 17 May 2011 11:26:15 -0700

> IPv6) from the source AFI field?

It is based on the IANA AFI assignments from:

http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xml

Those values determine the length of the address fields.

> And secondly, the length of Source EID address is specified as only  
> 16 bits in the Map-request message. So

You will see a "Source EID Address ..." in the field. That means the  
field is variable length and the length is determined from the Source- 
EID-AFI value.

> how does one encode the 32 bit (or 128 bit for IPv6) address into   
> the 16 bit field? And the same is true with ITR- RLoc AFI and ITR- 
> RLoc address.
>

Hope I answered your question.

Dino

>> While I was going through the main LISP spec, I have noticed that  
>> the length of the Source EID address, as specified in the Map- 
>> request message format is 16 bytes. Shouldn't it be 32 bytes even  
>> for an IP V4 address? And the same is true with the ITR-RLoc  
>> address. I might be missing something here. Can any one clarify  
>> this for me?
>
> -- 
> Thanks,
> Uma Bandaru
>

---

From: Uma Devi Bandaru <[email-masked]>
Date: Tue, 17 May 2011 11:31:05 -0700

Thanks for the clarifications.

On 5/17/2011 11:26 AM, Dino Farinacci wrote:
> field is variable length and the length is determined from the 
> Source-EID-AFI value.
>
>> the 16 bit field? And the same is true with ITR- RLoc AFI and 
>> ITR-RLoc address.
>>
>>> the length of the Source EID address, as specified in the 
>>> Map-request message format is 16 bytes. Shouldn't it be 32 bytes 
>>> even for an IP V4 address? And the same is true with the ITR-RLoc 
>>> address. I might be missing something here. Can any one clarify this 
>>> for me?
>>
>> -- 
>> Thanks,
>> Uma Bandaru
>>

-- 
Thanks,
Uma Bandaru

---

From: Alia Atlas <[email-masked]>
Date: Fri, 20 May 2011 17:48:06 -0400

Thanks for the extra time.

In addition to my detailed comments focused by the text, I'd say my
high-level concerns are
as follows:

a) I think we need very clear discussion of the rules around claiming
EID-prefixes and managing
more specific prefixes.  Ron Bonica asked a number of questions around
this and it isn't clear
to me either.  One issue is around the need/desire/expectation of
optimal routing.  Even in an
all LISP environment, it is possible for an ETR to claim a large
EID-prefix but other ETRs to have
better routes to longer more specific prefixes.  A concern is
how/why/when an ITR would know to
ask for a better mapping.

I am sure that this has been thought through - but the correct
behavior and timing are not clear to
me and make me worry about interoperability.

b) I am quite concerned about whether and how different
implementations could actually interoperate.
I am NOT looking for interoperable implementations created without
communication - that's not reasonable
at this stage.  What I AM looking for is that the drafts specify what
MUST be implemented and what
MAY be implemented.

There are a number of under-specified pieces and behaviors - I tried
to point them out as I noticed them.
What I find going back is that having read and let the drafts sit  in
my head, if I try and explain how something
works, to get details I am making assumptions that aren't in the draft.

As documents that describe general ideas and basic architectural
options, the drafts do a reasonable job (modulo
my various comments) but as specifications that can be implemented
without differing assumptions, I am
dubious.  An example is even today's conversation about the behavior
of an Map-Resolver and Map-Server.

c) At a time when we are moving towards more reliability in packet
forwarding, I am concerned that LISP
introduces more packet loss and unreliability - whether due to cache
churn, ITR failure, etc.  I realize that
some of this is due to architectural decisions made long ago - and I'm
not trying to change them.  It would be
appropriate, however, to discuss forwarding-affecting events and how
they are resolved.  I know that some pieces are scattered around, but
parts of this aren't clear nor is how to handle/resolve those
cases.

Given the state of the drafts, I'm not bothering to comment on my
general architectural concerns for LISP.

Please let me know if you want those too.

Alia