Re: [Gen-art] Genart telechat review of draft-ietf-lisp-rfc6833bis-24

[Dino Farinacci]

Okay. I will keep the last paragraph only. Thanks. 

Dino

> On Feb 5, 2019, at 7:59 PM, Benjamin Kaduk  wrote:
> 
> On Tue, Feb 05, 2019 at 07:56:39PM -0800, Dino Farinacci wrote:
>>> Nits/editorial comments: Section 2: Get rid of everything except the last 
>>> paragraph.
>> 
>> Are you sure? I just followed what RFC 8174 suggested. Give me reason to not 
>> follow it?
> 
> Yes, he's sure.
> 
> You pasted the text that 8174 inserted into 2119, when all you need is the
> bit after "Authors who follow these guidelines should incorporate this
> phrase near the beginning of their document:"
> 
> -Benjamin

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-lisp-rfc6833bis-24

[Dino Farinacci]

> Nits/editorial comments: Section 2: Get rid of everything except the last 
> paragraph.

Are you sure? I just followed what RFC 8174 suggested. Give me reason to not 
follow it?

Dino
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Diff looks good to me. Thanks Med!

Dino

> On Jan 9, 2019, at 11:42 PM,  
>  wrote:
> 
> Hi Brian, all,
> 
> The changes are now available online: 
> https://tools.ietf.org/html/draft-ietf-lisp-rfc8113bis-02 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc8113bis-02
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
>> Envoyé : vendredi 21 décembre 2018 07:57
>> À : Dino Farinacci; Brian E Carpenter
>> Cc : Joel M. Halpern; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
>> rfc8113bis@ietf.org
>> Objet : RE: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> Re-,
>> 
>> Seems we are all in agreement.
>> 
>> I implemented the changes to 8113bis in my local copy.
>> 
>> Thank you, Brian.
>> 
>> Cheers,
>> Med
>> 
>>> -Message d'origine-
>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>> Envoyé : vendredi 21 décembre 2018 00:29
>>> À : Brian E Carpenter
>>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-art@ietf.org;
>>> l...@ietf.org; draft-ietf-lisp-rfc8113bis@ietf.org
>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>> 
>>>> On 2018-12-21 09:18, Dino Farinacci wrote:
>>>>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine
>> with
>>> that. That reference being at the top of the draft saying “Updates
>> 6833bis”.
>>> If we remove that, he may concur. Please confirm Brian (again).
>>>> 
>>>> Yes, that would resolve my concern.
>>> 
>>> Thanks.
>>> 
>>>>> Like I have mentioned to you before, the IETF “Updates” lingo is
>> confusing
>>> and really not useful unless a draft replaces a previous draft. And this is
>>> not the case here.
>>>> 
>>>> That's a debate for the RFC-interest list perhaps. IMHO the issue is that
>>> "Updates" sometimes means "Extends" and sometimes means "Modifies".
>>> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to
>>> create confusion.
>>> 
>>> Then maybe those words should be used.
>>> 
>>> Dino
>>> 
>>>> 
>>>> Thanks
>>>>  Brian
>>>> 
>>>>> 
>>>>> Dino
>>>>> 
>>>>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern 
>>> wrote:
>>>>>> 
>>>>>> Dino, Med, please confirm if I am reading the thread properly:
>>>>>> 
>>>>>> I believe that the proposal is to make the small change below to
>> 6833bis
>>> and to drop the "updates" reference from 8113bis to 6833bis.
>>>>>> 
>>>>>> I believe Dino's question was whether Brian agreed that the combination
>>> suggested would address his concern.
>>>>>> 
>>>>>> Yours,
>>>>>> Joel
>>>>>> 
>>>>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>>>>> I may be missing something but I don't see how 8113bis can
>>>>>>> logically cite 8113, which it replaces.
>>>>>>> Frankly I think you've collectively created a plate of citation
>>>>>>> spaghetti by not moving the IANA considerations for the type field
>>>>>>> registry into 6830bis, which is where they naturally belong. If you
>>>>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>>>>> I can see.
>>>>>>> Regards
>>>>>>>  Brian
>>>>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>>>>> 
>>>>>>>> Dino
>>>>>>>> ngo
>>>>>>>>> On Dec 19, 2018, at 11:35 PM, 
>>>  wrote:
>>>>>>>>> 
>>>>>>>>> Hi Dino,
>>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>> 
>>>>>>>>> Values in the "Not Assigned" range can be a

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Thanks all.

Dino

> On Dec 20, 2018, at 10:57 PM,  
>  wrote:
> 
> Re-,
> 
> Seems we are all in agreement. 
> 
> I implemented the changes to 8113bis in my local copy. 
> 
> Thank you, Brian. 
> 
> Cheers,
> Med 
> 
>> -----Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : vendredi 21 décembre 2018 00:29
>> À : Brian E Carpenter
>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-art@ietf.org;
>> l...@ietf.org; draft-ietf-lisp-rfc8113bis@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>>> On 2018-12-21 09:18, Dino Farinacci wrote:
>>>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine with
>> that. That reference being at the top of the draft saying “Updates 6833bis”.
>> If we remove that, he may concur. Please confirm Brian (again).
>>> 
>>> Yes, that would resolve my concern.
>> 
>> Thanks.
>> 
>>>> Like I have mentioned to you before, the IETF “Updates” lingo is confusing
>> and really not useful unless a draft replaces a previous draft. And this is
>> not the case here.
>>> 
>>> That's a debate for the RFC-interest list perhaps. IMHO the issue is that
>> "Updates" sometimes means "Extends" and sometimes means "Modifies".
>> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to
>> create confusion.
>> 
>> Then maybe those words should be used.
>> 
>> Dino
>> 
>>> 
>>> Thanks
>>>  Brian
>>> 
>>>> 
>>>> Dino
>>>> 
>>>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern 
>> wrote:
>>>>> 
>>>>> Dino, Med, please confirm if I am reading the thread properly:
>>>>> 
>>>>> I believe that the proposal is to make the small change below to 6833bis
>> and to drop the "updates" reference from 8113bis to 6833bis.
>>>>> 
>>>>> I believe Dino's question was whether Brian agreed that the combination
>> suggested would address his concern.
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>>>> I may be missing something but I don't see how 8113bis can
>>>>>> logically cite 8113, which it replaces.
>>>>>> Frankly I think you've collectively created a plate of citation
>>>>>> spaghetti by not moving the IANA considerations for the type field
>>>>>> registry into 6830bis, which is where they naturally belong. If you
>>>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>>>> I can see.
>>>>>> Regards
>>>>>>  Brian
>>>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>>>> 
>>>>>>> Dino
>>>>>>> ngo
>>>>>>>> On Dec 19, 2018, at 11:35 PM, 
>>  wrote:
>>>>>>>> 
>>>>>>>> Hi Dino,
>>>>>>>> 
>>>>>>>> OLD:
>>>>>>>> 
>>>>>>>> Values in the "Not Assigned" range can be assigned according to
>>>>>>>> procedures in [RFC8126].
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>> Values in the "Not Assigned" range can be assigned via Standards
>>>>>>>> Action [RFC8113].
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Med
>>>>>>>> 
>>>>>>>>> -Message d'origine-
>>>>>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org;
>> l...@ietf.org;
>>>>>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-
>> rfc8113bis-01
>>>>>&g

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

> On 2018-12-21 09:18, Dino Farinacci wrote:
>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine with 
>> that. That reference being at the top of the draft saying “Updates 6833bis”. 
>> If we remove that, he may concur. Please confirm Brian (again).
> 
> Yes, that would resolve my concern.

Thanks.

>> Like I have mentioned to you before, the IETF “Updates” lingo is confusing 
>> and really not useful unless a draft replaces a previous draft. And this is 
>> not the case here.
> 
> That's a debate for the RFC-interest list perhaps. IMHO the issue is that 
> "Updates" sometimes means "Extends" and sometimes means "Modifies". 
> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to 
> create confusion.

Then maybe those words should be used.

Dino

> 
> Thanks
>   Brian
> 
>> 
>> Dino
>> 
>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern  wrote:
>>> 
>>> Dino, Med, please confirm if I am reading the thread properly:
>>> 
>>> I believe that the proposal is to make the small change below to 6833bis 
>>> and to drop the "updates" reference from 8113bis to 6833bis.
>>> 
>>> I believe Dino's question was whether Brian agreed that the combination 
>>> suggested would address his concern.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>> I may be missing something but I don't see how 8113bis can
>>>> logically cite 8113, which it replaces.
>>>> Frankly I think you've collectively created a plate of citation
>>>> spaghetti by not moving the IANA considerations for the type field
>>>> registry into 6830bis, which is where they naturally belong. If you
>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>> I can see.
>>>> Regards
>>>>   Brian
>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>> 
>>>>> Dino
>>>>> ngo 
>>>>>> On Dec 19, 2018, at 11:35 PM,  
>>>>>>  wrote:
>>>>>> 
>>>>>> Hi Dino,
>>>>>> 
>>>>>> OLD:
>>>>>> 
>>>>>>  Values in the "Not Assigned" range can be assigned according to
>>>>>>  procedures in [RFC8126].
>>>>>> 
>>>>>> NEW:
>>>>>> 
>>>>>>  Values in the "Not Assigned" range can be assigned via Standards
>>>>>>  Action [RFC8113].
>>>>>> 
>>>>>> Cheers,
>>>>>> Med
>>>>>> 
>>>>>>> -Message d'origine-
>>>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; 
>>>>>>> l...@ietf.org;
>>>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>>>> Objet : Re: [lisp] Genart last call review of 
>>>>>>> draft-ietf-lisp-rfc8113bis-01
>>>>>>> 
>>>>>>> What does fixing in (1) mean?
>>>>>>> 
>>>>>>> Dino
>>>>>>> 
>>>>>>>> On Dec 19, 2018, at 3:51 AM, 
>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> Brian, whether to maintain the document standalone was discussed by 
>>>>>>>> the WG.
>>>>>>> You may refer, for example, to the message from Deborah which clarifies 
>>>>>>> this
>>>>>>> point: 
>>>>>>> https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
>>>>>>> of the outcomes of that discussion is to add an "updates" header to 
>>>>>>> 8113bis.
>>>>>>>> 
>>>>>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>>>>>> rfc8113bis as normative in 6833bis (the approach I initially supported) 
>>>>>>&g

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Brian wants to drop the reference to 6833bis from 8113bis. I am fine with that. 
That reference being at the top of the draft saying “Updates 6833bis”. If we 
remove that, he may concur. Please confirm Brian (again).

Like I have mentioned to you before, the IETF “Updates” lingo is confusing and 
really not useful unless a draft replaces a previous draft. And this is not the 
case here.

Dino

> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern  wrote:
> 
> Dino, Med, please confirm if I am reading the thread properly:
> 
> I believe that the proposal is to make the small change below to 6833bis and 
> to drop the "updates" reference from 8113bis to 6833bis.
> 
> I believe Dino's question was whether Brian agreed that the combination 
> suggested would address his concern.
> 
> Yours,
> Joel
> 
> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>> I may be missing something but I don't see how 8113bis can
>> logically cite 8113, which it replaces.
>> Frankly I think you've collectively created a plate of citation
>> spaghetti by not moving the IANA considerations for the type field
>> registry into 6830bis, which is where they naturally belong. If you
>> don't want to do that, I think you have to leave them in 8113bis and
>> simply lose the citation of 6833bis, which serves no purpose that
>> I can see.
>> Regards
>>Brian
>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>> 
>>> Dino
>>> ngo 
>>>> On Dec 19, 2018, at 11:35 PM,  
>>>>  wrote:
>>>> 
>>>> Hi Dino,
>>>> 
>>>> OLD:
>>>> 
>>>>   Values in the "Not Assigned" range can be assigned according to
>>>>   procedures in [RFC8126].
>>>> 
>>>> NEW:
>>>> 
>>>>   Values in the "Not Assigned" range can be assigned via Standards
>>>>   Action [RFC8113].
>>>> 
>>>> Cheers,
>>>> Med
>>>> 
>>>>> -Message d'origine-
>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; l...@ietf.org;
>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>> Objet : Re: [lisp] Genart last call review of 
>>>>> draft-ietf-lisp-rfc8113bis-01
>>>>> 
>>>>> What does fixing in (1) mean?
>>>>> 
>>>>> Dino
>>>>> 
>>>>>> On Dec 19, 2018, at 3:51 AM, 
>>>>>  wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> Brian, whether to maintain the document standalone was discussed by the 
>>>>>> WG.
>>>>> You may refer, for example, to the message from Deborah which clarifies 
>>>>> this
>>>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. 
>>>>> One
>>>>> of the outcomes of that discussion is to add an "updates" header to 
>>>>> 8113bis.
>>>>>> 
>>>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>>>> rfc8113bis as normative in 6833bis (the approach I initially supported) 
>>>>> and
>>>>> agreed by Dino (https://www.ietf.org/mail-
>>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>>>>> 8113bis will lead to circular dependency. Which is a fair argument.
>>>>>> 
>>>>>> The "updates" tag was justified as follows:
>>>>>> 
>>>>>> (1)
>>>>>> 
>>>>>> RFC6833bis includes the following:
>>>>>> 
>>>>>>  Values in the "Not Assigned" range can be assigned according to
>>>>>>  procedures in [RFC8126].
>>>>>> 
>>>>>> That text is updated by RFC8113bis to be aligned with 8113:
>>>>>> 
>>>>>>  Values can be assigned via Standards Action
>>>>>> 
>>>>>> (2)
>>>>>> 
>>>>>> RFC8113bis extends the type field to grab more bits/values when the
>>>>> available types are exhausted. This is captured in 8113bis:
>>>>>> 
>>>>>>  The values in the range 0-1

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

I’ll make that change if Brian thinks it fixes the issues he raised.

Dino

> On Dec 19, 2018, at 11:35 PM,  
>  wrote:
> 
> Hi Dino, 
> 
> OLD: 
> 
>   Values in the "Not Assigned" range can be assigned according to
>   procedures in [RFC8126].
> 
> NEW:
> 
>   Values in the "Not Assigned" range can be assigned via Standards
>   Action [RFC8113].
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : mercredi 19 décembre 2018 19:00
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Joel M. Halpern; Brian E Carpenter; gen-art@ietf.org; l...@ietf.org;
>> draft-ietf-lisp-rfc8113bis@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> What does fixing in (1) mean?
>> 
>> Dino
>> 
>>> On Dec 19, 2018, at 3:51 AM, 
>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Brian, whether to maintain the document standalone was discussed by the WG.
>> You may refer, for example, to the message from Deborah which clarifies this
>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
>> of the outcomes of that discussion is to add an "updates" header to 8113bis.
>>> 
>>> FWIW, one of the issues that led to that conclusion was whether to cite
>> rfc8113bis as normative in 6833bis (the approach I initially supported) and
>> agreed by Dino (https://www.ietf.org/mail-
>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>> 8113bis will lead to circular dependency. Which is a fair argument.
>>> 
>>> The "updates" tag was justified as follows:
>>> 
>>> (1)
>>> 
>>> RFC6833bis includes the following:
>>> 
>>>  Values in the "Not Assigned" range can be assigned according to
>>>  procedures in [RFC8126].
>>> 
>>> That text is updated by RFC8113bis to be aligned with 8113:
>>> 
>>>  Values can be assigned via Standards Action
>>> 
>>> (2)
>>> 
>>> RFC8113bis extends the type field to grab more bits/values when the
>> available types are exhausted. This is captured in 8113bis:
>>> 
>>>  The values in the range 0-1023 are assigned via Standards Action.
>>>  This range is provisioned to anticipate, in particular, the
>>>  exhaustion of the LISP Packet types.
>>> 
>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
>> "updates" header because (2) can be also seen as an extension.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -Message d'origine-
>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>> Envoyé : mercredi 19 décembre 2018 06:37
>>>> À : Joel M. Halpern
>>>> Cc : Brian E Carpenter; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
>>>> rfc8113bis@ietf.org
>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
>> 01
>>>> 
>>>> Mohmad to comment.
>>>> 
>>>> Dino
>>>> 
>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
>>>>> 
>>>>> That is the other fix he offered.  Just remove the updates tag.
>>>>> I will leav eit to you and the the authors to determine which is correct.
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>>>>>> 8113bis should say that is it *extending* the type field so we can have
>>>> more types. The word “update” I always had a problem with because it can
>> be
>>>> interpreted as “replacing". Replacing something to fix a problem.
>>>>>> 8113 is simply asking for one of the type value codepoint, so there can
>> be
>>>> another format to have more types.
>>>>>> Dino
>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern 
>> wrote:
>>>>>>> 
>>>>>>> Authors: that sounds like a reasonable addition to me?
>>>>>>> 
>>>>>>> Yours,
>>>>>>> Joel
>>>>>>> 
>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>>>>>>>> This is part of the package to move the coherent set of base LISP
>>

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

What does fixing in (1) mean?

Dino

> On Dec 19, 2018, at 3:51 AM,  
>  wrote:
> 
> Hi all, 
> 
> Brian, whether to maintain the document standalone was discussed by the WG. 
> You may refer, for example, to the message from Deborah which clarifies this 
> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One 
> of the outcomes of that discussion is to add an "updates" header to 8113bis.
> 
> FWIW, one of the issues that led to that conclusion was whether to cite 
> rfc8113bis as normative in 6833bis (the approach I initially supported) and 
> agreed by Dino 
> (https://www.ietf.org/mail-archive/web/lisp/current/msg07882.html). Deborah 
> convinced me that citing 8113bis will lead to circular dependency. Which is a 
> fair argument. 
> 
> The "updates" tag was justified as follows:
> 
> (1)
> 
> RFC6833bis includes the following:
> 
>   Values in the "Not Assigned" range can be assigned according to
>   procedures in [RFC8126].
> 
> That text is updated by RFC8113bis to be aligned with 8113: 
> 
>   Values can be assigned via Standards Action
> 
> (2) 
> 
> RFC8113bis extends the type field to grab more bits/values when the available 
> types are exhausted. This is captured in 8113bis:
> 
>   The values in the range 0-1023 are assigned via Standards Action.
>   This range is provisioned to anticipate, in particular, the
>   exhaustion of the LISP Packet types.
> 
> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the 
> "updates" header because (2) can be also seen as an extension. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : mercredi 19 décembre 2018 06:37
>> À : Joel M. Halpern
>> Cc : Brian E Carpenter; gen-art@ietf.org; l...@ietf.org; draft-ietf-lisp-
>> rfc8113bis@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> Mohmad to comment.
>> 
>> Dino
>> 
>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
>>> 
>>> That is the other fix he offered.  Just remove the updates tag.
>>> I will leav eit to you and the the authors to determine which is correct.
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>>>> 8113bis should say that is it *extending* the type field so we can have
>> more types. The word “update” I always had a problem with because it can be
>> interpreted as “replacing". Replacing something to fix a problem.
>>>> 8113 is simply asking for one of the type value codepoint, so there can be
>> another format to have more types.
>>>> Dino
>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
>>>>> 
>>>>> Authors: that sounds like a reasonable addition to me?
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>>>>>> This is part of the package to move the coherent set of base LISP specs
>>>>>>> to PS.
>>>>>>> 
>>>>>>> The reason we did this rather than folding it into 6830bis / 6833bis is
>>>>>>> that we had originally simply cited 8113, and then realized that needed
>>>>>>> to move to PS along with everything else.  It seemed (and is) simpler
>> to
>>>>>>> do it separately rather than to further modify 6830bis / 6933bis.
>>>>>>> 
>>>>>>> As for why it updates 6833bis, that is because one of the cahnges in
>>>>>>> moving the set to PS was to improve the split as to which information
>>>>>>> belonged in which document.
>>>>>> OK, but I still don't find it logical The text doesn't explain which
>> part of
>>>>>> 6833bis is impacted, and normally these days we require such an
>> explanation.
>>>>>> And if there is an impact, you're missing the opportunity of fixing the
>> error
>>>>>> or gap in 6833bis, so the reader of 6833bis will be none the wiser
>> unless
>>>>>> you insert a reference to 8113bis.
>>>>>> On the other hand, if there is no error or gap, you don't need
>> "Updates:"
>>>>>> at all. (Unfortunately, we don't have an "Extends:" header.)
>>>>>>   Brian
>&

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

> IMHO we just drop the “update 6833bis” and we are fine.

I agree.

Dino

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Mohmad to comment.

Dino

> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
> 
> That is the other fix he offered.  Just remove the updates tag.
> I will leav eit to you and the the authors to determine which is correct.
> Yours,
> Joel
> 
> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>> 8113bis should say that is it *extending* the type field so we can have more 
>> types. The word “update” I always had a problem with because it can be 
>> interpreted as “replacing". Replacing something to fix a problem.
>> 8113 is simply asking for one of the type value codepoint, so there can be 
>> another format to have more types.
>> Dino
>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
>>> 
>>> Authors: that sounds like a reasonable addition to me?
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>>>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>>>> This is part of the package to move the coherent set of base LISP specs
>>>>> to PS.
>>>>> 
>>>>> The reason we did this rather than folding it into 6830bis / 6833bis is
>>>>> that we had originally simply cited 8113, and then realized that needed
>>>>> to move to PS along with everything else.  It seemed (and is) simpler to
>>>>> do it separately rather than to further modify 6830bis / 6933bis.
>>>>> 
>>>>> As for why it updates 6833bis, that is because one of the cahnges in
>>>>> moving the set to PS was to improve the split as to which information
>>>>> belonged in which document.
>>>> OK, but I still don't find it logical The text doesn't explain which part 
>>>> of
>>>> 6833bis is impacted, and normally these days we require such an 
>>>> explanation.
>>>> And if there is an impact, you're missing the opportunity of fixing the 
>>>> error
>>>> or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
>>>> you insert a reference to 8113bis.
>>>> On the other hand, if there is no error or gap, you don't need "Updates:"
>>>> at all. (Unfortunately, we don't have an "Extends:" header.)
>>>>Brian
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>>>>>> Reviewer: Brian Carpenter
>>>>>> Review result: Ready with Issues
>>>>>> 
>>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>>>>>> 
>>>>>> 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
>>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>>> 
>>>>>> Document: draft-ietf-lisp-rfc8113bis-01.txt
>>>>>> Reviewer: Brian Carpenter
>>>>>> Review Date: 2018-12-19
>>>>>> IETF LC End Date: 2018-12-27
>>>>>> IESG Telechat date:
>>>>>> 
>>>>>> Summary: Ready with issues
>>>>>> 
>>>>>> 
>>>>>> Comments:
>>>>>> -
>>>>>> 
>>>>>> I note that this is being raised from Experimental to the standards 
>>>>>> track.
>>>>>> Presumably that depends on the base LISP spec becoming PS.
>>>>>> 
>>>>>> Minor issues:
>>>>>> -
>>>>>> 
>>>>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>>>>>> explain which text is updated. This is in contrast to RFC8113, which
>>>>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>>>>>> this draft claim to update rfc6830bis? I'm going to assume that
>>>>>> is an error.
>>>>>> 
>>>>>> In fact, why wasn't the definition of the LISP Packet Types registry
>>>>>> moved into the base spec (rfc6830bis)? That is where it belongs.
>>>>>> 
>>>>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>>>>>> in them that needs updating should be updated! The fact is that 
>>>>>> rfc8113bis
>>>>>> extends rfc6830bis, which is not the same thing as "updates".
>>>>>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>>>>>> there should be a normative reference in 6830bis to 8113bis.
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> ___
>>> lisp mailing list
>>> l...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

8113bis should say that is it *extending* the type field so we can have more 
types. The word “update” I always had a problem with because it can be 
interpreted as “replacing". Replacing something to fix a problem. 

8113 is simply asking for one of the type value codepoint, so there can be 
another format to have more types.

Dino

> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
> 
> Authors: that sounds like a reasonable addition to me?
> 
> Yours,
> Joel
> 
> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>> This is part of the package to move the coherent set of base LISP specs
>>> to PS.
>>> 
>>> The reason we did this rather than folding it into 6830bis / 6833bis is
>>> that we had originally simply cited 8113, and then realized that needed
>>> to move to PS along with everything else.  It seemed (and is) simpler to
>>> do it separately rather than to further modify 6830bis / 6933bis.
>>> 
>>> As for why it updates 6833bis, that is because one of the cahnges in
>>> moving the set to PS was to improve the split as to which information
>>> belonged in which document.
>> OK, but I still don't find it logical The text doesn't explain which part of
>> 6833bis is impacted, and normally these days we require such an explanation.
>> And if there is an impact, you're missing the opportunity of fixing the error
>> or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
>> you insert a reference to 8113bis.
>> On the other hand, if there is no error or gap, you don't need "Updates:"
>> at all. (Unfortunately, we don't have an "Extends:" header.)
>>Brian
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
 Reviewer: Brian Carpenter
 Review result: Ready with Issues
 
 Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
 
 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-rfc8113bis-01.txt
 Reviewer: Brian Carpenter
 Review Date: 2018-12-19
 IETF LC End Date: 2018-12-27
 IESG Telechat date:
 
 Summary: Ready with issues
 
 
 Comments:
 -
 
 I note that this is being raised from Experimental to the standards track.
 Presumably that depends on the base LISP spec becoming PS.
 
 Minor issues:
 -
 
 "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
 explain which text is updated. This is in contrast to RFC8113, which
 explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
 this draft claim to update rfc6830bis? I'm going to assume that
 is an error.
 
 In fact, why wasn't the definition of the LISP Packet Types registry
 moved into the base spec (rfc6830bis)? That is where it belongs.
 
 Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
 in them that needs updating should be updated! The fact is that rfc8113bis
 extends rfc6830bis, which is not the same thing as "updates".
 If the WG thinks that implementers of 6830bis need to read 8113bis,
 there should be a normative reference in 6830bis to 8113bis.
 
 
>>> 
> 
> ___
> lisp mailing list
> l...@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-lisp-rfc6833bis-15

[Dino Farinacci]

Thanks again Pete for all your effort. 

Dino

> On Sep 19, 2018, at 2:07 PM, Pete Resnick  wrote:
> 
> Reviewer: Pete Resnick
> Review result: Ready
> 
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-lisp-rfc6833bis-15
> Reviewer: Pete Resnick
> Review Date: 2018-09-19
> IETF LC End Date: 2018-08-31
> IESG Telechat date: 2018-09-27
> 
> Summary: Ready
> 
> Major issues: None.
> 
> Minor issues: None.
> 
> Nits/editorial comments: None. Thanks for all of the cleanup based on my 
> previous review.
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Dino Farinacci]

There is no other text in the email. So can’t be sure what you are saying. I’m 
guessing you are fine with the proposed text?

My co-authors have to agree though.  ;-)

Dino

> On Dec 1, 2016, at 11:55 AM, Jari Arkko  wrote:
> 
> That would work for me.
> 
> Jari
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Dino Farinacci]

> OK, forget my suggestion. I have a difficulty to parse this sentence (second 
> part)
> 
>  It determines the downstream destination for unicast head-end replication 
> and identifies the
>  receiver ETR that needs to be notified should the root of the
>  distribution tree move to another site.
> 
> Lucy

First off, let’s include the entire paragraph:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  It determines the downstream
   destination for unicast head-end replication and identifies the
   receiver ETR that needs to be notified should the root of the
   distribution tree move to another site.

How about we change to this:

   Knowledge of the receiver ETR's RLOC address is also essential to the
   control plane of the root ITR.  The RLOC address determines the downstream
   destination for unicast head-end replication and identifies the
   receiver ETR that needs to be notified should the root ITR of the
   distribution tree move to another site. The root ITR can change when the
   source EID is roaming to another LISP site.

Dino

> 
> -----Original Message-
> From: Dino Farinacci [mailto:farina...@gmail.com] 
> Sent: Thursday, December 01, 2016 1:45 PM
> To: Lucy yong
> Cc: Jari Arkko; draft-ietf-pim-join-attributes-for-l...@tools.ietf.org; 
> General Area Review Team; Stig Venaas
> Subject: Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05
> 
> 
>> Could you make this sentence more readable?
>> 
>>  It determines the downstream destination for unicast head-end replication 
>> and identifies the
>>  receiver ETR that needs to be notified should the root of the
>>  distribution tree move to another site.
>> 
>> "should be", "moving”?
> 
> I do not understand what you are suggesting. Write more words please.
> 
> Dino
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Dino Farinacci]

> Could you make this sentence more readable?
> 
>   It determines the downstream destination for unicast head-end replication 
> and identifies the
>   receiver ETR that needs to be notified should the root of the
>   distribution tree move to another site.
> 
> "should be", "moving”?

I do not understand what you are suggesting. Write more words please.

Dino


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Dino Farinacci]

> Lucy,
> 
> Many thanks for your review.
> 
> Dino, Stig, does this discussion lead you to consider adding some 
> clarifications to the document? I am not going to require those (just posted 
> a no-obj for the document on today’s telechat), but wanted to give you an 
> opportunity to consider that.
> 
> Jari

The base LISP multicast architecture is all explained in RFC6831. From the type 
of commentary from Lucy’s email, it led me to believe she (1) had not read 
RFC6831 or (2) did not understand the content of RFC6831.

Discussing how LISP multicast works in a PIM document is a misplacement of 
information and risks contradicting what is in the LISP published RFCs.

Dino

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Dino Farinacci]

> Two. One at all LISP sites (not one per LISP site) and part of the overlay 
> and possibly one in the underlay.
> [Lucy] Thank, Dino. This is helpful. So the attributes proposed in this draft 
> is used in the first PIM instance, right? These attributes are only used by 
> ETRs to send join/prune msg to ITR (root).

Right.

> site, one is for LISP underlay network, and one among LISP xTRs, is 
>> this right? PIM protocol instance running for LISP xTRs is a special 
>> version with additional LISP related attributes? When configuring
> 
> I don’t know what you mean by “additional LISP related attributes”. The LISP 
> xTR runs PIM and sends unicast PIM Join/Prune messages to other xTRs.
> [Lucy] I mean the attribute is per LISP specific implementation.

Well, you could use VXLAN encapsulation as the data-plane (arguably, with 14 
bytes of unnecessary overhead).

> PIM protocol on a device, do we need to differ them in configuration? Sorry 
> to ask these, I have not yet read RFC6831 but understand what you want to 
> achieve here.
> 
> That is implementation specific.
> [Lucy] PIM is a protocol running on top of IGP. Now we have PIM LISP 
> implementation specific. Within a 

You are conflating the relationship between PIM and LISP. PIM runs side-by-side 
with BGP, OSPF, IS-IS, and LISP. That is the way to look at it. Do they depend 
on each other? The answer is no. PIM uses the RIB that is populated by BGP, 
OSPF, IS-IS. And LISP uses the mapping database to find RLOCs where then it 
uses the RIB/FIB to forward to RLOCs.

There is no case where PIM messages are encapsulated by LISP. I mean it can be 
but it is not spec’ed anywhere and is not needed unless some new design feature 
is desired by it (like PIM Join/Prune messages need confidentiality so they are 
encapsulated in lisp-crypto).

> But the best test to know if a multicast RLOC should be used is to RLOC-probe 
> it and see all the ETRs that reply. Then you know which ETRs can received the 
> encapsulated multicast packet via a multicast underlay. And the ones that 
> don’t, you unicast replicate. This is the case where multicast partially 
> deployed in the underlay.
> [Lucy] You are the expert on this subject. From the draft text, I am not able 
> to picture these. 

Just taking a holistic view.

Dino


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Dino Farinacci]

>> the draft assumes that PIM works within individual LISP sites but PIM 
>> mcast transport may not be supported among LISP sites. However the 
>> mechanism itself does not enforce a unique (unicast or mcast) underlay 
>> transport among LISP sites. Could some ETRs request unicast transport, 
>> other request multicast transport? The mechanism requires all LISP 
>> xTRs to run PIM protocol, right?
> 
> We are sending a PIM join and we assume that the upstream LIS xTR is 
> supporting PIM. This is similar to RFC 6831. If PIM is not supported, the 
> join message would be ignored. As we mention in section 4 we want to allow a 
> mixture of multicast and unicast forwarding.
> [Lucy] I am thinking that how many PIM protocol instance may run in this 
> case, one is within a LISP 

Two. One at all LISP sites (not one per LISP site) and part of the overlay and 
possibly one in the underlay.

> site, one is for LISP underlay network, and one among LISP xTRs, is this 
> right? PIM protocol instance running for LISP xTRs is a special version with 
> additional LISP related attributes? When configuring 

I don’t know what you mean by “additional LISP related attributes”. The LISP 
xTR runs PIM and sends unicast PIM Join/Prune messages to other xTRs.

> PIM protocol on a device, do we need to differ them in configuration? Sorry 
> to ask these, I have not yet read RFC6831 but understand what you want to 
> achieve here.

That is implementation specific. And the details are in RFC6831. And if you are 
going to do a quality review of this document, you should read RFC 6831.

>> PIM join/prune msg are designed for PIM protocol. These two attributes 
>> are specifically designed for LISP purpose. Any concern here? From PIM 
>> perspective, they are optional attributes; are they "MUST" attributes 
>> for LISP (mcast)?
> 
> It is possible to do multicast according to 6831 without these attributes. As 
> we mention in this 

Yes, if multicast is in the underlay and reaches every LISP site. But the point 
is, it may not. Plus this draft can be used when RFC 6831 is NOT used but when 
draft-ietf-lisp-signal-free-multicast is used so the ITR can know if multicast 
RLOCs can be used. 

But the best test to know if a multicast RLOC should be used is to RLOC-probe 
it and see all the ETRs that reply. Then you know which ETRs can received the 
encapsulated multicast packet via a multicast underlay. And the ones that 
don’t, you unicast replicate. This is the case where multicast partially 
deployed in the underlay.

Dino

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pim-join-attributes-for-lisp-05

[Dino Farinacci]

> the draft assumes that PIM works within individual LISP sites but PIM mcast 
> transport may not be supported among LISP sites. However the mechanism itself 
> does not enforce a unique (unicast or mcast) underlay transport among LISP 
> sites. Could some ETRs request unicast transport, other request multicast 
> transport? The mechanism requires all LISP xTRs to run PIM protocol, right?

The draft is explaining how PIM messages are sent across the underlay between 
xTRs. Not how PIM operates within a LISP site. The way PIM operates within a 
LISP site is based on the PIM RFC unchanged.

The draft it solving the hard problem where the underlay neither supports 
multicast, partially supports multicast, or fully supports multicast. All these 
combinations create the complexity, so it is conveyed from ETRs that unicast 
PIM messages to ITRs according to RFC6831 (LISP-Multicast).

> PIM join/prune msg are designed for PIM protocol. These two attributes are 
> specifically designed for LISP purpose. Any concern here? From PIM 
> perspective, they are optional attributes; are they “MUST” attributes for 
> LISP (mcast)?

And the PIM protocol is run (over-the-top) between LISP xTRs.

Dino
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-lisp-lcaf-16

[Dino Farinacci]

>   On the basis that each RTR RLOC can be from a different address family, 
> than I would say that the number of RTRs cannot be determined from the LCAF 
> Length field.  The length alone would not tell you the breakdown of RTR RLOCs 
> between the address families, so the only way to tell how many RTR RLOCs are 
> present is to parse through them until the length of the AFI/address 
> combinations seen equals the Length value.  For example, 3 IPv4 RTR RLOCs 
> will have the same length (3 x (2 + 4)) as one IPv6 RTR RLOC (2 + 16).  I'd 
> simply strike the relevant sentence in the RTR RLOC definition (2nd to last 
> sentence).

I added text based on your suggestion. Thanks.

Dino


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review for draft-ietf-lisp-crypto-09

[Dino Farinacci]

> Summary: This draft is ready for publication as an Experimental RFC

Thanks for your review Pete. Brian and I appreciate it.

> Though this is not an area of expertise for me, the document is clearly 
> written, I reviewed the data structures and they appear correct, and the 
> document seems ready to go forward. (I do find it dicey that this is an 
> Experimental document. I understand there is history here, but this is

The reason the document is Experimental is to be consistent with the rest of 
the LISP RFC set. We do have in the LISP WG charter to standards track the 
RFC-set and anticipate that this RFC will follow the same path. But of course, 
it is for the working group to decide.

> a full-fledged protocol document and the fact that it is only required to be 
> subjected to a cursory review for Experimental status and can pass IESG 
> review with one "YES" and everyone else "ABSTAIN"ing seems kinda ridiculous. 
> But that's not a reason to stop this document.)

I’ll yield to others to comment on this.

> Nits/editorial comments:
> 
> Section 9, second to last paragraph: "Otherwise, the packet has been tampered 
> with and is discarded." The "tampered with" is probably overstating the case. 
> I would simply say "invalid”.

Fixed.

Thanks again,
Dino



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [lisp] Gen-ART Review for draft-ietf-lisp-crypto-09

[Dino Farinacci]

Manish, we wanted a more integrated solution. Many products can’t do 
encapsulation and encryption at one time in one router. There are 2-box 
solutions are there. Plus, there are more RTT packet exchanges for IPsec which 
would cause more packet loss when the ITR would have to resolve an EID to an 
RLOC and do key exchange. We did this all together in one RTT so we have 
efficiency and integration.

Plus, we can do rekeying more efficiently and quicker. And we don’t have to 
store keys and have a PKI.

Dino

> On Oct 13, 2016, at 12:21 PM, Roger Jørgensen  wrote:
> 
> On Thu, Oct 13, 2016 at 3:30 PM, Manish Kumar  
> wrote:
>> I guess I did mention this before but just in case that was missed - the
>> idea of a separate confidentiality mechanism for each encapsulation/overlay
>> protocol when these are all IP based does seem a bit inapposite to me. At a
>> minimum, it opens up scope for additional security holes to prey upon (as
>> against using a standard mechanism like IPsec).
> 
> 
> I was going to respond to the original question but somehow it got lost...
> 
> The idea went through alot of discussion with different security guys to make
> sure it would be as good as it could be, if I remember correctly we did all 
> that
> before it was requested to be a LISP-wg document..
> 
> 
> I would suggest you read the introduction part again, are a few things
> there that
> made IPSec or any form of outer encryption out of scope. Not to forget that if
> using IPSec we would have to encapsulate an already encapsulated packet...
> 
> Some other background on the document - I had two ideas, one was that we
> should encrypt the xTR - xTR traffic to make it a bit more secure over 
> whatever
> medium it was crossing - and an idea that as a LISP site I should somehow be
> able to signal alongside my EID that i only wanted encrypted traffic
> to arrive at
> my xTR's, or that I only supported a few given encryption scheme.
> This and some ideas Dino already combined with other input morphed into
> the document we are discussing now.
> 
> 
> 
> -- 
> 
> Roger Jorgensen   | ROJO9-RIPE
> rog...@gmail.com  | - IPv6 is The Key!
> http://www.jorgensen.no   | ro...@jorgensen.no

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-lisp-lcaf-17

[Dino Farinacci]

Thanks for your second round of comments Peter. See comments inline.

> Page 6, Rsvd2 definition: the definition both says "reserved for future use"
> and then says some types actually use it.  That sounds like present use.
> And to generically say that it should be sent as zero and ignored, but then
> to give uses (such as Type 2)  for it  is confusing.  I suggest rethinking
> the wording here.

I have fixed this and received multiple comemnts on this from various people.

> Page 6, Length definition: there's mention of a "Reserved" field that's
> included in the minimum length of 8 bytes that are not part of the length
> value.  Since there are actually Rsvd1 and Rsvd2 fields in the generic
> version of the LCAF and sometimes even Rsvd3 and Rsvd4 fields when using
> specific Types, it might be better to spell out which reserved fields (Rsvd1
> and Rsvd2) are meant here rather than giving the field a summary name that
> doesn't actually appear in the format.  This is also important because any
> Rsvd3 and Rsvd4 fields are included in the Length field, so using a generic
> "Reserved" description is ambiguous at best.

Should be fixed now.

> Page 13, RTR RLOC Address definition, 4th sentence: The ability to determine
> the number of RTRs encoded by looking at the value of the LCAF length
> doesn't seem feasible.  3 IPv4 RTR RLOCs will produce the same LCAF Length
> as 1 IPv6 RTR RLOC.

Fixed now.

> Page 13, RTR RLOC Address definition, 5th sentence: this sentence gives two
> means to indicate that there RTR field values.  What's the point of having
> two different means of doing so?  This just seems to introduce complexity
> and increase the chance for implementations that may not handle both schemes
> correctly.  One scheme ought to suffice.  I prefer the Length field method
> since it requires fewer bytes transmitted, but either works.

An implementation must be prepared to find the RTR RLOC address entry with an 
AFI=0. So either the length includes all bytes up to and including the “Private 
ETR RLOC Address” field which basically encodes no “RTR RLOC Address” more 
efficiently or it does include an AFI=0 for the “RTR RLOC Address” entry. Since 
an AFI can be a value of 0 in any LISP message, we have to document the two 
ways to encode “no RLOC addresses”.

> Nits:
> 
> Page 5, Type definition: change the comma to a semicolon.
> 
> Page 8, Usage, 1st sentence: change the second "a" to "an".
> 
> Page 9, AS Number definition: insert "to" before "either".
> 
> Page 13, RTR RLOC Address definition, 3rd sentence: change "these" to
> "this".
> 
> Page 14, section 4.5, 2nd paragraph: change "it's" to "its".
> 
> Page 15, Source/Subnet Address and Group Address definitions: delete an
> extra space before "is" in each definition.
> 
> Page 16, Strict bit (S) definition, 1st sentence: change "Rencap" to
> "Reencap".
> 
> Page 18, Key Count definition, 2nd sentence: change "the" to "of".
> 
> Page 18, AFI = x definition: insert two spaces before the second sentence.
> 
> Page 24, section 4.10.3, 1st paragraph: delete "where it is delimited by
> length 'n' of the LCAF Length encoding"
> 
> Page 26, 1st paragraph after Length2 definition: change "AFI-encoded" to
> "AFI encoded".  My apologies for suggesting a blind find-and-replace in the
> previous review.  Obviously that was wrong here.

Made changes for above.

> Page 27, section 5.1, Length value n definition: I'm not sure what qualifies
> as "8-byte Application Data fields", but there appear to be 12 bytes before
> the AFI and that's reflected in the Length field in the figure.  So the
> local and remote port ranges are the 8-byte Application Data fields?  This
> comes back to my minor issue with how Length values are described in the
> text and in the figures.  Please clarify what's meant here.

I don’t find any reference in document -17 to "8-byte Application Data fields”.

> Page 29, Key Field Num definition: change "the the" to "the".
> 
> Page 32, section 5.5, 1st paragraph, 2nd sentence: insert "the" before
> "key”.

Made these changes too. Thanks.

Dino


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-lisp-multicast-08

[Dino Farinacci]

Kathleen, thanks for the comments. I have made changes to reflect all your 
editorial comments. I will be posting a draft-ietf-lisp-multicast-09.txt with 
yours and Ralph's comments.

Dino

On Oct 3, 2011, at 8:23 PM, kathleen.moria...@emc.com 
kathleen.moria...@emc.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-lisp-multicast-08
 Reviewer: Kathleen Moriarty
 Review Date: 3 October 2011
 IETF LC End Date: 28 September 2011
 IESG Telechat date: (if known)
 
 Summary:  The document is ready with nits.  I am sorry about the late review!
 
 Major issues:
 
 Minor issues:
 
 Nits/editorial comments:
 The last paragraph of section 3 introduces the use of the term 'oif-list' 
 within a definition for 'Unicast Encapsulated PIM Join/Prune Message'.  I 
 think it would be helpful to define this term.
 
 Section 4, consider breaking the first sentence of #6 into two sentences:
 When a packet is originated by the multicast host in the source
 site, it will flow to one or more ITRs which will prepend a LISP
 header by copying the group address to the outer destination
 address field and insert its own locator address in the outer
 source address field.
 
 Section 5, 2nd paragraph: Recommend changing from:
 In a LISP site, packets
 are originated from hosts using their allocated EIDs, those addresses
 are used to identify the host as well as where in the site's topology
 the host resides but not how and where it is attached to the
 Internet.
 To: In a LISP site, packets originate from hosts using their allocated EIDs. 
  EID addresses
 are used to identify the host as well as where in the site's topology
 the host resides, but not how and where it is attached to the
 Internet.
 
 Section 7, IGMP section, second sentence, add a comma:
 To: One being that they are link-
local and not used over site boundaries and second, they advertise
group addresses that don't need translation.
 
 Section 7: PIM-SSN - consider breaking this into a couple of sentences to 
 make it easier to read.
 In this case, there is a small
modification to the operation of the PIM protocol (but not to any
message format) to support taking a Join/Prune message originated
inside of a LISP site with embedded addresses from the EID
namespace and converting them to addresses from the RLOC namespace
when the Join/Prune message crosses a site boundary.
 
 Section 7: PIM-Bidir Section - consider breaking the following into a couple 
 of sentences:
 When using
Bidir-PIM for inter-domain multicast routing, it is recommended to
use staticly configured RPs so core routers think the Bidir group
is associated with an ITR's RLOC as the RP address and site
routers think the Bidir group is associated with the site resident
RP with an EID address.
 
 Section 9.2: This section is the first place where 'you' is used.  The 
 writing style changes, you may want to rewrite and make it consistent with 
 the rest of the document.  There is a 'you' in 9.3 as well and 'we' is used 
 in section 11.
 
 Section 12: Should the 'must' in the first paragraph be in caps?
 Mtrace functionality must be consistent with unicast traceroute
 functionality where all hops from multicast receiver to multicast
 source are visible.
 
 
 
 
 
 
 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art