Subject: [lisp] xTR-ID for Map-Request in RFC6833bis

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 19 Sep 2017 19:34:08 -0700

Hi all,

We would like to suggest updating rfc6833bis [1] to include the xTR-ID in
the Map-Request, in the same way that is already defined for the
Map-Register.

In particular, we propose to update the Map-Request message format in page
10 to include an I-bit right next to the m-bit (i.e. the I-bit would be in
position 11). We suggest the following text to be included in page 11,
after the explanation of the m-bit:

“I: This is the xTR-ID bit. When this bit is set, a 128-bit xTR-ID field
followed by a 64-bit Site-ID field are appended to the end of the
Map-Request, immediately following the last EID-Record (or the Map-Reply
Record, if present).”

Let us know what you think.

Thanks,
Alberto

[1] https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-05

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 19 Sep 2017 23:43:52 -0400

I can well believe that is useful.
It would help you you provided use case?

Yours,
Joel

On 9/19/17 10:34 PM, Alberto Rodriguez-Natal wrote:
> Hi all,
> 
> We would like to suggest updating rfc6833bis [1] to include the xTR-ID 
> in the Map-Request, in the same way that is already defined for the 
> Map-Register.
> 
> In particular, we propose to update the Map-Request message format in 
> page 10 to include an I-bit right next to the m-bit (i.e. the I-bit 
> would be in position 11). We suggest the following text to be included 
> in page 11, after the explanation of the m-bit:
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 19 Sep 2017 21:05:09 -0700

Sure Joel.

The xTR-ID in the Map-Request was originally defined for the PubSub draft
[1]. In that document, it is used as a way to unequivocally identify
subscribers to a mapping.

However, we believe that it may have value besides that specific use-case
and that RFC6833bis would be a better place to define it.

Thanks,
Alberto

[1] https://tools.ietf.org/html/draft-rodrigueznatal-lisp-pubsub-00

On Tue, Sep 19, 2017 at 8:43 PM, Joel M. Halpern <[email-masked]>
wrote:

>> page 10 to include an I-bit right next to the m-bit (i.e. the I-bit would
>> be in position 11). We suggest the following text to be included in page
>> 11, after the explanation of the m-bit:
>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 20 Sep 2017 00:12:52 -0400

Comparing what we have in 6833bis and NAT Traversal for the xTR-ID in 
the map register, and the proposed text plus the text in the pubsub 
draft for this usage of xTR-ID, it looks to me like we would benefit 
from a better description of this value is to be generated and used. 
Particularly if we want to put it in the base spec.

That said, with a reasonable explanation, it seems reasonable to do 
that, just as we did on the register side.

Yours,
joel

On 9/20/17 12:05 AM, Alberto Rodriguez-Natal wrote:
> Sure Joel.
> 
> The xTR-ID in the Map-Request was originally defined for the PubSub 
> draft [1]. In that document, it is used as a way to unequivocally 
> identify subscribers to a mapping.
> 
> However, we believe that it may have value besides that specific 
> use-case and that RFC6833bis would be a better place to define it.
> 
> Thanks,
> Alberto
> 
> On Tue, Sep 19, 2017 at 8:43 PM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>         We would like to suggest updating rfc6833bis [1] to include the
>         xTR-ID in the Map-Request, in the same way that is already
>         defined for the Map-Register.
> 
>         In particular, we propose to update the Map-Request message
>         format in page 10 to include an I-bit right next to the m-bit
>         (i.e. the I-bit would be in position 11). We suggest the
>         following text to be included in page 11, after the explanation
>         of the m-bit:
> 
>         “I: This is the xTR-ID bit. When this bit is set, a 128-bit
>         xTR-ID field followed by a 64-bit Site-ID field are appended to
>         the end of the Map-Request, immediately following the last
>         EID-Record (or the Map-Reply Record, if present).”
> 
>         <https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-05>
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/lisp>
> 
>

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 19 Sep 2017 21:19:28 -0700

That sounds reasonable Joel. We will work on an extended description and
get back to the list.

Thanks,
Alberto

On Tue, Sep 19, 2017 at 9:12 PM, Joel Halpern Direct <
[email-masked]> wrote:

> Comparing what we have in 6833bis and NAT Traversal for the xTR-ID in the
> map register, and the proposed text plus the text in the pubsub draft for
> this usage of xTR-ID, it looks to me like we would benefit from a better
> description of this value is to be generated and used. Particularly if we
> want to put it in the base spec.
>
> That said, with a reasonable explanation, it seems reasonable to do that,
> just as we did on the register side.
>
> Yours,
> joel
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Sep 2017 10:36:18 -0700

> On Sep 19, 2017, at 9:19 PM, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 
> That sounds reasonable Joel. We will work on an extended description and get back to the list.

The big question is if the pubsub draft should be referenced from 6833bis?

Has the same issues as referencing the NAT-traversal draft. 

Dino