Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci]

Right. Agree with your interpretation. I hope authors can make this clear based 
on your suggestions. 

Thanks,
Dino

> On Jan 17, 2017, at 7:06 PM, Dale R. Worley  wrote:
> 
> Dino Farinacci  writes:
>>> Both of these servers process Map-Request messages, albeit with
>>> different semantics.  Hence the D bit in Map-Request messages is needed
>>> to differentiate which server is to process a given Map-Request message.
>> 
>> The reason I explained the above was that the D-bit tells the receiver
>> of a Map-Request what type of message to return regardless of the
>> colocation status of the servers.
> 
> OK, that's close to the distinction I was making.  The defining text is
> probably from section 5:
> 
>   D: The "DDT-originated" flag.  It is set by a DDT client to indicate
>  that the receiver SHOULD return Map-Referral messages as
>  appropriate.  Use of the flag is further described in
>  Section 7.3.1.  This bit is allocated from LISP message header
>  bits marked as Reserved in [RFC6830].
> 
> But when I read it, the phrase "the receiver SHOULD return Map-Referral
> messages as appropriate" wasn't at all clear.  I assume now that what it
> means is, "should return Map-Referral messages *as described in this
> document*, whereas D=0 means it should be processed as described in RFC
> 6833".  The defining characteristic isn't the type of messages to be
> returned but which processing to apply, as a DDT server and a Map-Server
> are very different things (defined in different RFCs!).
> 
> Dale

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dale R. Worley]

Dino Farinacci  writes:
>> Both of these servers process Map-Request messages, albeit with
>> different semantics.  Hence the D bit in Map-Request messages is needed
>> to differentiate which server is to process a given Map-Request message.
>
> The reason I explained the above was that the D-bit tells the receiver
> of a Map-Request what type of message to return regardless of the
> colocation status of the servers.

OK, that's close to the distinction I was making.  The defining text is
probably from section 5:

   D: The "DDT-originated" flag.  It is set by a DDT client to indicate
  that the receiver SHOULD return Map-Referral messages as
  appropriate.  Use of the flag is further described in
  Section 7.3.1.  This bit is allocated from LISP message header
  bits marked as Reserved in [RFC6830].

But when I read it, the phrase "the receiver SHOULD return Map-Referral
messages as appropriate" wasn't at all clear.  I assume now that what it
means is, "should return Map-Referral messages *as described in this
document*, whereas D=0 means it should be processed as described in RFC
6833".  The defining characteristic isn't the type of messages to be
returned but which processing to apply, as a DDT server and a Map-Server
are very different things (defined in different RFCs!).

Dale

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci]

> I reviewed draft-ietf-lisp-ddt-08, and my memory is that the only
> significant technical question was regarding the "D" bit in Map-Request
> messages.

Let me try to make this more clear for you Dale. Thanks for the comment.

> Thinking back on it, I believe that the difficulty I was having was with
> the explanation of the D bit, not its functionality.  In particular, a
> DDT server can share a node and a listening port with a Map-Server.

Yes, every Map-Server that is part of a child referral from a DDT-node is also 
a DDT-node. But the DDT-node does not process D=0 Map-Requests but does D=1 
Map-Requests by responding with Map-Referral messages. A Map-Server sends 
Map-Referrals too. And usually a D=0 Map-Request is forwarded by Map-Servers to 
ETRs so they send Map-Replies.

> Both of these servers process Map-Request messages, albeit with
> different semantics.  Hence the D bit in Map-Request messages is needed
> to differentiate which server is to process a given Map-Request message.

The reason I explained the above was that the D-bit tells the receiver of a 
Map-Request what type of message to return regardless of the colocation status 
of the servers.

> My suggestion is that the document define the D bit in this way.  Once
> that is done, it's obvious for a particular client sending a particular
> message whether the D bit should be set.  Compare with the current

Well depending on what type of device you are referring to as a “client”. 
Map-Resolvers are part of infrastructure and they are typically the only 
devices that send D=1 Map-Requests. And they are sending them because they know 
the Map-Request is going to a DDT node and that they want a Map-Referral as a 
response.

> description, which speaks of the D bit as if it is a classification of
> the sender of the Map-Request, which leads to conceptual problems

It is not the classification of the sender.

> because it requires the document to define the classification and ensure
> that all possible clients are properly classified.
> 
> (Ideally, I would advocate that a DDT Map-Request should have a
> different type code than a Map-Server Map-Request.  But I'm sure that it
> is too late to put that fix into existing deployments.)

They both have the exact same information, one just solicits a Map-Referral and 
D=0 doesn’t.

Dino



___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dale R. Worley]

I reviewed draft-ietf-lisp-ddt-08, and my memory is that the only
significant technical question was regarding the "D" bit in Map-Request
messages.

Thinking back on it, I believe that the difficulty I was having was with
the explanation of the D bit, not its functionality.  In particular, a
DDT server can share a node and a listening port with a Map-Server.
Both of these servers process Map-Request messages, albeit with
different semantics.  Hence the D bit in Map-Request messages is needed
to differentiate which server is to process a given Map-Request message.

My suggestion is that the document define the D bit in this way.  Once
that is done, it's obvious for a particular client sending a particular
message whether the D bit should be set.  Compare with the current
description, which speaks of the D bit as if it is a classification of
the sender of the Map-Request, which leads to conceptual problems
because it requires the document to define the classification and ensure
that all possible clients are properly classified.

(Ideally, I would advocate that a DDT Map-Request should have a
different type code than a Map-Server Map-Request.  But I'm sure that it
is too late to put that fix into existing deployments.)

Dale

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci]

Is there any status on the draft-ietf-lisp-ddt? This document is blocking many 
other documents in the RFC editor queue.

Dino

> On Nov 4, 2016, at 10:24 AM, Dino Farinacci  wrote:
> 
> Okay, thanks for the effort.
> 
> Dino
> 
>> On Nov 4, 2016, at 9:15 AM, Anton Smirnov  wrote:
>> 
>>  Hi Dino,
>> 
>>  given the scope of comments and need for review between authors it may be 
>> difficult. We will make an effort to achieve this date but right now I can't 
>> guarantee this.
>> 
>> Anton
>> 
>> On Tuesday 01 November 2016 22:55, Dino Farinacci wrote:
>>> Great to hear. Is the goal to publish the new draft on Monday of IETF week?
>>> 
>>> Dino
>>> 
 On Nov 1, 2016, at 11:47 AM, Anton Smirnov  wrote:
 
  Hello Dino,
 
  thanks for taking time to answer these concerns. Authors will work on the 
 revised text to incorporate those points.
 
 Anton
 
 On Sunday 16 October 2016 22:43, Dino Farinacci wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> .
>> 
>> Document: draft-ietf-lisp-ddt-08
>> Reviewer: Dale R. Worley
>> Review Date: 2016-10-09
>> IETF LC End Date: 2016-10-17
>> IESG Telechat date: 2016-10-27
>> 
>> Summary: This draft is on the right track but has open issues,
>> described in the review.
> Thanks for the review Dale. Your comments are outstanding! And your 
> suggestions even better.  ;-)
> 
> I am not an author but was involved in the LISP-DDT design early on so I 
> would like to respond to some of your comments. Where I think text should 
> change, I will suggest that to help the authors. To clarify 
> understanding, I will comment inline.
> 
> One of the authors will make the changes.
> 
>> * In regard to XEIDs:  The concept of XEID unifies the treatment of
>> DBID, IID, AFI, and EID.  Essentially all of the processing in the
>> draft is simplified by expressing processing in terms of XEIDs.  For
>> instance, delegation based on DBID, IID, or AF becomes just a special
>> case of delegation based on XEID-prefix.  However, it's not clear to
>> me whether this concept is followed in the text.  For example:
> Yes, you interpreted the defintion of an extended-EID correctly. It is a 
> multi-tuple entity that has hierarchy so we can delegate any tuple, as 
> well as the tuple itself, downward on the tree.
> 
>> In section 3, definition "XEID-prefix" seems to assume that an
>> XEID-prefix will always contain a complete DBID, IID, and AFI.
> For a lookup yes. For a delegation, it can be any part of it as I 
> explained above.
> 
>> In section 4.2.1:
>> 
>>  The root DDT node is the logical "top" of the database hierarchy:
>>  DBID=0, IID=0, AFI=0, EID-prefix=0/0.
>> 
>> But really, the condition of a root node is that it's authoritative
>> for the *empty* XEID-prefix.
> Well it is authoriative for everything, by default, but a Map-Referral 
> return code will tell you exactly what it is authoritative for if 
> configured for specficy XEIDs.
> 
>> There is also the suggestion here that an AFI of 0 is somehow a
>> wildcard match for any AFI value.  That is a special case that can be
>> eliminated by considering the entire XEID to be prefixable.
> Right, if a delegation is configured with solely the 2-tuple (DBID=0, 
> IID=0), it would be the delegation represents all prefixes in all address 
> families.
> 
> We should clarify that in the text.
> 
>> On the other hand, this text in 7.3.1 suggests that there is a "null
>> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:
>> 
>>  the "referral XEID-prefix" is also initialized to the null value
>>  since no referral has yet been received.
> I think we don’t need to say how its initialized IMO. We should change 
> text here.
> 
>> * In regard to the special fields in XEID, viz., DBID, IID, and AFI,
>> those need to be described in a way that doesn't leave loose ends, by
>> either describing how they are expected to be used or referring to a
>> document that does so.  In this document, a lot of that information is
>> bundled into the definitions of "Extended EID (XEID)" and
>> "XEID-prefix" in section 3.  It would be best if this information
>> appeared in its own paragraphs.
> Agree. We should make this change.
> 
>> It appears to me that it is expected that DBID will always be zero
>> (see definition "XEID-prefix"), but the machinery is defined so that
>> other values can b

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci]

Okay, thanks for the effort.

Dino

> On Nov 4, 2016, at 9:15 AM, Anton Smirnov  wrote:
> 
>   Hi Dino,
> 
>   given the scope of comments and need for review between authors it may be 
> difficult. We will make an effort to achieve this date but right now I can't 
> guarantee this.
> 
> Anton
> 
> On Tuesday 01 November 2016 22:55, Dino Farinacci wrote:
>> Great to hear. Is the goal to publish the new draft on Monday of IETF week?
>> 
>> Dino
>> 
>>> On Nov 1, 2016, at 11:47 AM, Anton Smirnov  wrote:
>>> 
>>>   Hello Dino,
>>> 
>>>   thanks for taking time to answer these concerns. Authors will work on the 
>>> revised text to incorporate those points.
>>> 
>>> Anton
>>> 
>>> On Sunday 16 October 2016 22:43, Dino Farinacci wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-lisp-ddt-08
> Reviewer: Dale R. Worley
> Review Date: 2016-10-09
> IETF LC End Date: 2016-10-17
> IESG Telechat date: 2016-10-27
> 
> Summary: This draft is on the right track but has open issues,
> described in the review.
 Thanks for the review Dale. Your comments are outstanding! And your 
 suggestions even better.  ;-)
 
 I am not an author but was involved in the LISP-DDT design early on so I 
 would like to respond to some of your comments. Where I think text should 
 change, I will suggest that to help the authors. To clarify understanding, 
 I will comment inline.
 
 One of the authors will make the changes.
 
> * In regard to XEIDs:  The concept of XEID unifies the treatment of
> DBID, IID, AFI, and EID.  Essentially all of the processing in the
> draft is simplified by expressing processing in terms of XEIDs.  For
> instance, delegation based on DBID, IID, or AF becomes just a special
> case of delegation based on XEID-prefix.  However, it's not clear to
> me whether this concept is followed in the text.  For example:
 Yes, you interpreted the defintion of an extended-EID correctly. It is a 
 multi-tuple entity that has hierarchy so we can delegate any tuple, as 
 well as the tuple itself, downward on the tree.
 
> In section 3, definition "XEID-prefix" seems to assume that an
> XEID-prefix will always contain a complete DBID, IID, and AFI.
 For a lookup yes. For a delegation, it can be any part of it as I 
 explained above.
 
> In section 4.2.1:
> 
>   The root DDT node is the logical "top" of the database hierarchy:
>   DBID=0, IID=0, AFI=0, EID-prefix=0/0.
> 
> But really, the condition of a root node is that it's authoritative
> for the *empty* XEID-prefix.
 Well it is authoriative for everything, by default, but a Map-Referral 
 return code will tell you exactly what it is authoritative for if 
 configured for specficy XEIDs.
 
> There is also the suggestion here that an AFI of 0 is somehow a
> wildcard match for any AFI value.  That is a special case that can be
> eliminated by considering the entire XEID to be prefixable.
 Right, if a delegation is configured with solely the 2-tuple (DBID=0, 
 IID=0), it would be the delegation represents all prefixes in all address 
 families.
 
 We should clarify that in the text.
 
> On the other hand, this text in 7.3.1 suggests that there is a "null
> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:
> 
>   the "referral XEID-prefix" is also initialized to the null value
>   since no referral has yet been received.
 I think we don’t need to say how its initialized IMO. We should change 
 text here.
 
> * In regard to the special fields in XEID, viz., DBID, IID, and AFI,
> those need to be described in a way that doesn't leave loose ends, by
> either describing how they are expected to be used or referring to a
> document that does so.  In this document, a lot of that information is
> bundled into the definitions of "Extended EID (XEID)" and
> "XEID-prefix" in section 3.  It would be best if this information
> appeared in its own paragraphs.
 Agree. We should make this change.
 
> It appears to me that it is expected that DBID will always be zero
> (see definition "XEID-prefix"), but the machinery is defined so that
> other values can be used.
 Experience has showed us that running parallel mapping databases will be 
 useful. They really don’t need to be numbered or identified because there 
 will be distinct roots and xTRs can connect to one or multiple of them.
 
 And right now, we do not have an enc

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Anton Smirnov]

   Hi Dino,

   given the scope of comments and need for review between authors it 
may be difficult. We will make an effort to achieve this date but right 
now I can't guarantee this.


Anton

On Tuesday 01 November 2016 22:55, Dino Farinacci wrote:

Great to hear. Is the goal to publish the new draft on Monday of IETF week?

Dino


On Nov 1, 2016, at 11:47 AM, Anton Smirnov  wrote:

   Hello Dino,

   thanks for taking time to answer these concerns. Authors will work on the 
revised text to incorporate those points.

Anton

On Sunday 16 October 2016 22:43, Dino Farinacci wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-lisp-ddt-08
Reviewer: Dale R. Worley
Review Date: 2016-10-09
IETF LC End Date: 2016-10-17
IESG Telechat date: 2016-10-27

Summary: This draft is on the right track but has open issues,
described in the review.

Thanks for the review Dale. Your comments are outstanding! And your suggestions 
even better.  ;-)

I am not an author but was involved in the LISP-DDT design early on so I would 
like to respond to some of your comments. Where I think text should change, I 
will suggest that to help the authors. To clarify understanding, I will comment 
inline.

One of the authors will make the changes.


* In regard to XEIDs:  The concept of XEID unifies the treatment of
DBID, IID, AFI, and EID.  Essentially all of the processing in the
draft is simplified by expressing processing in terms of XEIDs.  For
instance, delegation based on DBID, IID, or AF becomes just a special
case of delegation based on XEID-prefix.  However, it's not clear to
me whether this concept is followed in the text.  For example:

Yes, you interpreted the defintion of an extended-EID correctly. It is a 
multi-tuple entity that has hierarchy so we can delegate any tuple, as well as 
the tuple itself, downward on the tree.


In section 3, definition "XEID-prefix" seems to assume that an
XEID-prefix will always contain a complete DBID, IID, and AFI.

For a lookup yes. For a delegation, it can be any part of it as I explained 
above.


In section 4.2.1:

   The root DDT node is the logical "top" of the database hierarchy:
   DBID=0, IID=0, AFI=0, EID-prefix=0/0.

But really, the condition of a root node is that it's authoritative
for the *empty* XEID-prefix.

Well it is authoriative for everything, by default, but a Map-Referral return 
code will tell you exactly what it is authoritative for if configured for 
specficy XEIDs.


There is also the suggestion here that an AFI of 0 is somehow a
wildcard match for any AFI value.  That is a special case that can be
eliminated by considering the entire XEID to be prefixable.

Right, if a delegation is configured with solely the 2-tuple (DBID=0, IID=0), 
it would be the delegation represents all prefixes in all address families.

We should clarify that in the text.


On the other hand, this text in 7.3.1 suggests that there is a "null
prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:

   the "referral XEID-prefix" is also initialized to the null value
   since no referral has yet been received.

I think we don’t need to say how its initialized IMO. We should change text 
here.


* In regard to the special fields in XEID, viz., DBID, IID, and AFI,
those need to be described in a way that doesn't leave loose ends, by
either describing how they are expected to be used or referring to a
document that does so.  In this document, a lot of that information is
bundled into the definitions of "Extended EID (XEID)" and
"XEID-prefix" in section 3.  It would be best if this information
appeared in its own paragraphs.

Agree. We should make this change.


It appears to me that it is expected that DBID will always be zero
(see definition "XEID-prefix"), but the machinery is defined so that
other values can be used.

Experience has showed us that running parallel mapping databases will be 
useful. They really don’t need to be numbered or identified because there will 
be distinct roots and xTRs can connect to one or multiple of them.

And right now, we do not have an encoding for a DBID that can be sent in a 
Map-Register or Map-Request. So I am agreeing with you.


IID is presumably expected to be zero except when VPNs are used.  (see
definition "Extended EID (XEID)")

Note that definition "Extended EID (XEID)" says "optionally extended
with a non-zero Instance ID".  Read literally, that means that zero
IIDs aren't included in the XEID, which would be insanity.  The text
needs to clarify that IID is always present in the XEID, but is
normally zero.

Well no, not insane, if we required IID for every register and request, then 
the XEID would have the same set of tuples fo

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci]

Great to hear. Is the goal to publish the new draft on Monday of IETF week?

Dino

> On Nov 1, 2016, at 11:47 AM, Anton Smirnov  wrote:
> 
>   Hello Dino,
> 
>   thanks for taking time to answer these concerns. Authors will work on the 
> revised text to incorporate those points.
> 
> Anton
> 
> On Sunday 16 October 2016 22:43, Dino Farinacci wrote:
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> .
>>> 
>>> Document: draft-ietf-lisp-ddt-08
>>> Reviewer: Dale R. Worley
>>> Review Date: 2016-10-09
>>> IETF LC End Date: 2016-10-17
>>> IESG Telechat date: 2016-10-27
>>> 
>>> Summary: This draft is on the right track but has open issues,
>>> described in the review.
>> Thanks for the review Dale. Your comments are outstanding! And your 
>> suggestions even better.  ;-)
>> 
>> I am not an author but was involved in the LISP-DDT design early on so I 
>> would like to respond to some of your comments. Where I think text should 
>> change, I will suggest that to help the authors. To clarify understanding, I 
>> will comment inline.
>> 
>> One of the authors will make the changes.
>> 
>>> * In regard to XEIDs:  The concept of XEID unifies the treatment of
>>> DBID, IID, AFI, and EID.  Essentially all of the processing in the
>>> draft is simplified by expressing processing in terms of XEIDs.  For
>>> instance, delegation based on DBID, IID, or AF becomes just a special
>>> case of delegation based on XEID-prefix.  However, it's not clear to
>>> me whether this concept is followed in the text.  For example:
>> Yes, you interpreted the defintion of an extended-EID correctly. It is a 
>> multi-tuple entity that has hierarchy so we can delegate any tuple, as well 
>> as the tuple itself, downward on the tree.
>> 
>>> In section 3, definition "XEID-prefix" seems to assume that an
>>> XEID-prefix will always contain a complete DBID, IID, and AFI.
>> For a lookup yes. For a delegation, it can be any part of it as I explained 
>> above.
>> 
>>> In section 4.2.1:
>>> 
>>>   The root DDT node is the logical "top" of the database hierarchy:
>>>   DBID=0, IID=0, AFI=0, EID-prefix=0/0.
>>> 
>>> But really, the condition of a root node is that it's authoritative
>>> for the *empty* XEID-prefix.
>> Well it is authoriative for everything, by default, but a Map-Referral 
>> return code will tell you exactly what it is authoritative for if configured 
>> for specficy XEIDs.
>> 
>>> There is also the suggestion here that an AFI of 0 is somehow a
>>> wildcard match for any AFI value.  That is a special case that can be
>>> eliminated by considering the entire XEID to be prefixable.
>> Right, if a delegation is configured with solely the 2-tuple (DBID=0, 
>> IID=0), it would be the delegation represents all prefixes in all address 
>> families.
>> 
>> We should clarify that in the text.
>> 
>>> On the other hand, this text in 7.3.1 suggests that there is a "null
>>> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:
>>> 
>>>   the "referral XEID-prefix" is also initialized to the null value
>>>   since no referral has yet been received.
>> I think we don’t need to say how its initialized IMO. We should change text 
>> here.
>> 
>>> * In regard to the special fields in XEID, viz., DBID, IID, and AFI,
>>> those need to be described in a way that doesn't leave loose ends, by
>>> either describing how they are expected to be used or referring to a
>>> document that does so.  In this document, a lot of that information is
>>> bundled into the definitions of "Extended EID (XEID)" and
>>> "XEID-prefix" in section 3.  It would be best if this information
>>> appeared in its own paragraphs.
>> Agree. We should make this change.
>> 
>>> It appears to me that it is expected that DBID will always be zero
>>> (see definition "XEID-prefix"), but the machinery is defined so that
>>> other values can be used.
>> Experience has showed us that running parallel mapping databases will be 
>> useful. They really don’t need to be numbered or identified because there 
>> will be distinct roots and xTRs can connect to one or multiple of them.
>> 
>> And right now, we do not have an encoding for a DBID that can be sent in a 
>> Map-Register or Map-Request. So I am agreeing with you.
>> 
>>> IID is presumably expected to be zero except when VPNs are used.  (see
>>> definition "Extended EID (XEID)")
>>> 
>>> Note that definition "Extended EID (XEID)" says "optionally extended
>>> with a non-zero Instance ID".  Read literally, that means that zero
>>> IIDs aren't included in the XEID, which would be insanity.  The text
>>> needs to clarify that IID is always present in the XEID, but is
>>> normally zero.
>> Well no, not insane, if we requi

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Anton Smirnov]

   Hello Dino,

   thanks for taking time to answer these concerns. Authors will work 
on the revised text to incorporate those points.


Anton

On Sunday 16 October 2016 22:43, Dino Farinacci wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-lisp-ddt-08
Reviewer: Dale R. Worley
Review Date: 2016-10-09
IETF LC End Date: 2016-10-17
IESG Telechat date: 2016-10-27

Summary: This draft is on the right track but has open issues,
described in the review.

Thanks for the review Dale. Your comments are outstanding! And your suggestions 
even better.  ;-)

I am not an author but was involved in the LISP-DDT design early on so I would 
like to respond to some of your comments. Where I think text should change, I 
will suggest that to help the authors. To clarify understanding, I will comment 
inline.

One of the authors will make the changes.


* In regard to XEIDs:  The concept of XEID unifies the treatment of
DBID, IID, AFI, and EID.  Essentially all of the processing in the
draft is simplified by expressing processing in terms of XEIDs.  For
instance, delegation based on DBID, IID, or AF becomes just a special
case of delegation based on XEID-prefix.  However, it's not clear to
me whether this concept is followed in the text.  For example:

Yes, you interpreted the defintion of an extended-EID correctly. It is a 
multi-tuple entity that has hierarchy so we can delegate any tuple, as well as 
the tuple itself, downward on the tree.


In section 3, definition "XEID-prefix" seems to assume that an
XEID-prefix will always contain a complete DBID, IID, and AFI.

For a lookup yes. For a delegation, it can be any part of it as I explained 
above.


In section 4.2.1:

   The root DDT node is the logical "top" of the database hierarchy:
   DBID=0, IID=0, AFI=0, EID-prefix=0/0.

But really, the condition of a root node is that it's authoritative
for the *empty* XEID-prefix.

Well it is authoriative for everything, by default, but a Map-Referral return 
code will tell you exactly what it is authoritative for if configured for 
specficy XEIDs.


There is also the suggestion here that an AFI of 0 is somehow a
wildcard match for any AFI value.  That is a special case that can be
eliminated by considering the entire XEID to be prefixable.

Right, if a delegation is configured with solely the 2-tuple (DBID=0, IID=0), 
it would be the delegation represents all prefixes in all address families.

We should clarify that in the text.


On the other hand, this text in 7.3.1 suggests that there is a "null
prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:

   the "referral XEID-prefix" is also initialized to the null value
   since no referral has yet been received.

I think we don’t need to say how its initialized IMO. We should change text 
here.


* In regard to the special fields in XEID, viz., DBID, IID, and AFI,
those need to be described in a way that doesn't leave loose ends, by
either describing how they are expected to be used or referring to a
document that does so.  In this document, a lot of that information is
bundled into the definitions of "Extended EID (XEID)" and
"XEID-prefix" in section 3.  It would be best if this information
appeared in its own paragraphs.

Agree. We should make this change.


It appears to me that it is expected that DBID will always be zero
(see definition "XEID-prefix"), but the machinery is defined so that
other values can be used.

Experience has showed us that running parallel mapping databases will be 
useful. They really don’t need to be numbered or identified because there will 
be distinct roots and xTRs can connect to one or multiple of them.

And right now, we do not have an encoding for a DBID that can be sent in a 
Map-Register or Map-Request. So I am agreeing with you.


IID is presumably expected to be zero except when VPNs are used.  (see
definition "Extended EID (XEID)")

Note that definition "Extended EID (XEID)" says "optionally extended
with a non-zero Instance ID".  Read literally, that means that zero
IIDs aren't included in the XEID, which would be insanity.  The text
needs to clarify that IID is always present in the XEID, but is
normally zero.

Well no, not insane, if we required IID for every register and request, then 
the XEID would have the same set of tuples for all lookups. Supplying an IID=0 
is not wrong or bad semantically and just cost 32-bits in message space.


AFI is taken from http://www.iana.org/numbers.html, but you have to go
through the link to draft-ietf-lisp-lcaf to discover that; it should
be stated in this draft.

True. Authors use the reference I put in the latest LCAF draft. That was an 
IESG comment. So we should get it 

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Anton Smirnov]

   Hello Dale,

   thanks for your very detailed and extensive comments. Dino has 
already provided inline answers for your comments and authors [mostly] 
agree with them. So we are planning to update the draft to address 
points raised in your review - either by taking in proposed changes or 
by clarifying the text to better express author's intentions.


   Given extent of your comments it will take us some time to edit the 
document. Next revision will hopefully reduce number of places which 
needs further discussion, so it will be easier to have email discussion 
of remaining issues.


Anton

On Saturday 15 October 2016 03:29, Dale R. Worley wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-lisp-ddt-08
Reviewer: Dale R. Worley
Review Date: 2016-10-09
IETF LC End Date: 2016-10-17
IESG Telechat date: 2016-10-27

Summary: This draft is on the right track but has open issues,
described in the review.

I believe that the technical specifics in this draft have been
settled, but in many places the wording is unclear and contradictory
in minor ways to the point that I was uncertain whether I understood
what is intended.  The result is that this review is excessively long,
as I can only point to the items that appear problematic, rather than
pointing out the adjustments that would cure the problems.

I suspect that as the design has evolved, the text has been revised
many times, leading to incompletenesses and inconsistencies.  The
danger, in my opinion, is that no part of the document can be reliably
understood without correlating it with many other parts of the
document, that many implementers will make mistakes of interpretation,
and that there may be points on which people believe consensus was
reached, but that their understandings of the point were contradictory.

I think that the document needs a careful final editing to bring the
terminology and all parts of the document into sync.  That will also
reveal whether there are points on which people mistakenly believed
there was consensus.

I begin with a list of more global issues, then continue with comments
on specific parts.

* In regard to XEIDs:  The concept of XEID unifies the treatment of
DBID, IID, AFI, and EID.  Essentially all of the processing in the
draft is simplified by expressing processing in terms of XEIDs.  For
instance, delegation based on DBID, IID, or AF becomes just a special
case of delegation based on XEID-prefix.  However, it's not clear to
me whether this concept is followed in the text.  For example:

In section 3, definition "XEID-prefix" seems to assume that an
XEID-prefix will always contain a complete DBID, IID, and AFI.

In section 4.2.1:

The root DDT node is the logical "top" of the database hierarchy:
DBID=0, IID=0, AFI=0, EID-prefix=0/0.

But really, the condition of a root node is that it's authoritative
for the *empty* XEID-prefix.

There is also the suggestion here that an AFI of 0 is somehow a
wildcard match for any AFI value.  That is a special case that can be
eliminated by considering the entire XEID to be prefixable.

On the other hand, this text in 7.3.1 suggests that there is a "null
prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:

the "referral XEID-prefix" is also initialized to the null value
since no referral has yet been received.

* In regard to the special fields in XEID, viz., DBID, IID, and AFI,
those need to be described in a way that doesn't leave loose ends, by
either describing how they are expected to be used or referring to a
document that does so.  In this document, a lot of that information is
bundled into the definitions of "Extended EID (XEID)" and
"XEID-prefix" in section 3.  It would be best if this information
appeared in its own paragraphs.

It appears to me that it is expected that DBID will always be zero
(see definition "XEID-prefix"), but the machinery is defined so that
other values can be used.

IID is presumably expected to be zero except when VPNs are used.  (see
definition "Extended EID (XEID)")

Note that definition "Extended EID (XEID)" says "optionally extended
with a non-zero Instance ID".  Read literally, that means that zero
IIDs aren't included in the XEID, which would be insanity.  The text
needs to clarify that IID is always present in the XEID, but is
normally zero.

AFI is taken from http://www.iana.org/numbers.html, but you have to go
through the link to draft-ietf-lisp-lcaf to discover that; it should
be stated in this draft.

* For any given delegated prefix, there can be more than one "peer"
DDT nodes that contain duplicated information about the prefix.  But
the term "peer" isn't defined in the lexicon, and there is no

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Jari Arkko]

Many thanks Dale for this extensive and high quality review. Much appreciated.

And thank you Dino and others for working on answers and edits.

Jari



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08

[Dino Farinacci]

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-lisp-ddt-08
> Reviewer: Dale R. Worley
> Review Date: 2016-10-09
> IETF LC End Date: 2016-10-17
> IESG Telechat date: 2016-10-27
> 
> Summary: This draft is on the right track but has open issues,
> described in the review.

Thanks for the review Dale. Your comments are outstanding! And your suggestions 
even better.  ;-)

I am not an author but was involved in the LISP-DDT design early on so I would 
like to respond to some of your comments. Where I think text should change, I 
will suggest that to help the authors. To clarify understanding, I will comment 
inline.

One of the authors will make the changes.

> * In regard to XEIDs:  The concept of XEID unifies the treatment of
> DBID, IID, AFI, and EID.  Essentially all of the processing in the
> draft is simplified by expressing processing in terms of XEIDs.  For
> instance, delegation based on DBID, IID, or AF becomes just a special
> case of delegation based on XEID-prefix.  However, it's not clear to
> me whether this concept is followed in the text.  For example:

Yes, you interpreted the defintion of an extended-EID correctly. It is a 
multi-tuple entity that has hierarchy so we can delegate any tuple, as well as 
the tuple itself, downward on the tree.

> In section 3, definition "XEID-prefix" seems to assume that an
> XEID-prefix will always contain a complete DBID, IID, and AFI.

For a lookup yes. For a delegation, it can be any part of it as I explained 
above.

> In section 4.2.1:
> 
>   The root DDT node is the logical "top" of the database hierarchy:
>   DBID=0, IID=0, AFI=0, EID-prefix=0/0.
> 
> But really, the condition of a root node is that it's authoritative
> for the *empty* XEID-prefix.

Well it is authoriative for everything, by default, but a Map-Referral return 
code will tell you exactly what it is authoritative for if configured for 
specficy XEIDs.

> There is also the suggestion here that an AFI of 0 is somehow a
> wildcard match for any AFI value.  That is a special case that can be
> eliminated by considering the entire XEID to be prefixable.

Right, if a delegation is configured with solely the 2-tuple (DBID=0, IID=0), 
it would be the delegation represents all prefixes in all address families.

We should clarify that in the text.

> On the other hand, this text in 7.3.1 suggests that there is a "null
> prefix" which is (or is equivalent) to the XEID-prefix of 0 bits:
> 
>   the "referral XEID-prefix" is also initialized to the null value
>   since no referral has yet been received.

I think we don’t need to say how its initialized IMO. We should change text 
here.

> * In regard to the special fields in XEID, viz., DBID, IID, and AFI,
> those need to be described in a way that doesn't leave loose ends, by
> either describing how they are expected to be used or referring to a
> document that does so.  In this document, a lot of that information is
> bundled into the definitions of "Extended EID (XEID)" and
> "XEID-prefix" in section 3.  It would be best if this information
> appeared in its own paragraphs.

Agree. We should make this change.

> It appears to me that it is expected that DBID will always be zero
> (see definition "XEID-prefix"), but the machinery is defined so that
> other values can be used.

Experience has showed us that running parallel mapping databases will be 
useful. They really don’t need to be numbered or identified because there will 
be distinct roots and xTRs can connect to one or multiple of them.

And right now, we do not have an encoding for a DBID that can be sent in a 
Map-Register or Map-Request. So I am agreeing with you.

> IID is presumably expected to be zero except when VPNs are used.  (see
> definition "Extended EID (XEID)")  
> 
> Note that definition "Extended EID (XEID)" says "optionally extended
> with a non-zero Instance ID".  Read literally, that means that zero
> IIDs aren't included in the XEID, which would be insanity.  The text
> needs to clarify that IID is always present in the XEID, but is
> normally zero.

Well no, not insane, if we required IID for every register and request, then 
the XEID would have the same set of tuples for all lookups. Supplying an IID=0 
is not wrong or bad semantically and just cost 32-bits in message space.

> AFI is taken from http://www.iana.org/numbers.html, but you have to go
> through the link to draft-ietf-lisp-lcaf to discover that; it should
> be stated in this draft.

True. Authors use the reference I put in the latest LCAF draft. That was an 
IESG comment. So we should get it right.

> * For any given delegated prefix, there can be more than one "peer"
> DDT nodes tha