[lisp] Fwd: WebEx meeting invitation: IDEAS

[Padma Pillay-Esnault]

Hello


Many Thanks to our PALS!

We have a webex session set up for the side meeting tomorrow.

Please tune in!
Padma

Hello,
PALS Working Group invites you to join this WebEx meeting.

*IDEAS*
Tuesday, March 28, 2017
11:30 am  |  Central Daylight Time (Chicago, GMT-05:00)  |  2 hrs
Meeting number (access code): 645 023 501
Meeting password: ideaspw


Add to Calendar

When it's time, join the meeting
.

*Join by phone*
*1-877-668-4493 <(877)%20668-4493>* Call-in toll free number (US/Canada)
*1-650-479-3208 <(650)%20479-3208>* Call-in toll number (US/Canada)
Toll-free calling restrictions


Can't join the meeting? 

IMPORTANT NOTICE: Please note that this WebEx service allows audio and
other information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you automatically
consent to such recordings. If you do not consent to being recorded,
discuss your concerns with the host or do not join the session.


WebEx_Meeting.ics
Description: Binary data
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Request for private LCAF allocation

[Joel M. Halpern]

That does not sound quite right.
If the problem is experimentation, then what you describe (reserving one 
code point, if you need several structure your use in such a way to give 
you the spac eyou need) makes good sense.


If the problem is private use LCAF types being deployed in production, 
then we need some way to avoid collisions from competing private uses. 
There are several ways to address this, but ignoring it is not a good idea.


Yours,
Joel

On 3/27/17 2:53 PM, Alberto Rodriguez-Natal wrote:

Hi all,

Based in deployment experience we have seen a need for private ad-hoc
and use-case-specific LCAF types. However, current LCAF space does not
account for a private use similar to the private IP space defined in [1].

Due to the limited LCAF space, rather than reserving a subset of types
for private use as in [1] we propose to reserve only one number (e.g.
LCAF type 254). If needed, private deployments can define private
subtypes encoded within that private LCAF type. The encoding of the
private LCAF (besides the common LCAF header) is not specified and would
be deployment-specific.

The purpose of requesting a LCAF type to be allocated as private,
instead of just using one of the currently unallocated types, is to
avoid collisions with future LCAF types that may appear. We would like
to ask the WG for feedback on this and to trigger the process to request
a new LCAF type to be allocated by IANA.

Thanks,
Alberto

[1] https://tools.ietf.org/html/rfc1918


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



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

Re: [lisp] Request for private LCAF allocation

[Alberto Rodriguez-Natal]

On Mon, Mar 27, 2017 at 1:59 PM, Dino Farinacci  wrote:

> > Hi all,
> >
> > Based in deployment experience we have seen a need for private ad-hoc
> and use-case-specific LCAF types. However, current LCAF space does not
> account for a private use similar to the private IP space defined in [1].
>
> I have seen the need to use private space as well and by using the JSON
> LCAF Type as an RLOC-record, I find it very convienent and flexible to
> define my own parameters and extend to add more easily.
>

Certainly, that's the reason that motivated the JSON LCAF back in the day.
The motivation for a private LCAF type is to avoid to be constrained to
JSON and to give vendors/operators full freedom on how they use a private
LCAF.

>
> > Due to the limited LCAF space, rather than reserving a subset of types
> for private use as in [1] we propose to reserve only one number (e.g. LCAF
> type 254). If needed, private deployments can define private subtypes
> encoded within that private LCAF type. The encoding of the private LCAF
> (besides the common LCAF header) is not specified and would be
> deployment-specific.
>
> Could you be more specific if you would use this LCAF type for EID-records
> as well as RLOC-records? If the latter, it is easier to deploy since what
> is returned to a caller assumes the caller knows what it wants to lookup.
> But for EID-records, any new format that is not standard will be hard for
> the mapping system to support (right now LISP-ALT and LISP-DDT). So we
> would need some discussion about this.
>

The point is that the usage of the private LCAF should be undefined.
Different deployments may use it in different ways. Is up to the
vendors/operators to implement a mapping system that works properly with
private LCAFs on the role they use it.

>
> > The purpose of requesting a LCAF type to be allocated as private,
> instead of just using one of the currently unallocated types, is to avoid
> collisions with future LCAF types that may appear. We would like to ask the
> WG for feedback on this and to trigger the process to request a new LCAF
> type to be allocated by IANA.
>
> Sure, this makes sense to have a reserved one. But having a reserved LCAF
> is only the first step. How about interoperability?
>

That's the point, that by default should be no interoperabilty between
domains. Let's say that both Pepsi and Coke have deployments that use
private LCAFs, each for its own purposes. They should not be capable of
understanding each other LCAFs unless they explicitly coordinate offline to
do so. Similarly to RFC 1918, private LCAFs should only be used within a
domain and not cross domains unless those domains explicitly coordinate on
that. If interoperability is needed across domains, probably a private LCAF
is not the way to go.

If your question is regarding interoperability across different devices
within a single domain, then is up to that domain to make sure that the
devices are able to interoperate if needed.

>
> That is, can a general mapping system have both public LCAFs and private
> LCAFs and interoperate when an xTR that doesn’t support the private space
> can talk to an xTR that does as well as two old xTRs that use the same
> mapping system which supports both?
>

Not sure if I follow. It is up for the implementation/deployment to decide
if it allows to do so and how that would work.

>
> Would a private LCAF space be limited to an instance-ID and only run
> within a VPN?
>

Again, that is deployment-specific and should not be specified by the IETF.

Alberto

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

Re: [lisp] Request for private LCAF allocation

[Dino Farinacci]

> Hi all,
> 
> Based in deployment experience we have seen a need for private ad-hoc and 
> use-case-specific LCAF types. However, current LCAF space does not account 
> for a private use similar to the private IP space defined in [1]. 

I have seen the need to use private space as well and by using the JSON LCAF 
Type as an RLOC-record, I find it very convienent and flexible to define my own 
parameters and extend to add more easily.

> Due to the limited LCAF space, rather than reserving a subset of types for 
> private use as in [1] we propose to reserve only one number (e.g. LCAF type 
> 254). If needed, private deployments can define private subtypes encoded 
> within that private LCAF type. The encoding of the private LCAF (besides the 
> common LCAF header) is not specified and would be deployment-specific. 

Could you be more specific if you would use this LCAF type for EID-records as 
well as RLOC-records? If the latter, it is easier to deploy since what is 
returned to a caller assumes the caller knows what it wants to lookup. But for 
EID-records, any new format that is not standard will be hard for the mapping 
system to support (right now LISP-ALT and LISP-DDT). So we would need some 
discussion about this.

> The purpose of requesting a LCAF type to be allocated as private, instead of 
> just using one of the currently unallocated types, is to avoid collisions 
> with future LCAF types that may appear. We would like to ask the WG for 
> feedback on this and to trigger the process to request a new LCAF type to be 
> allocated by IANA.

Sure, this makes sense to have a reserved one. But having a reserved LCAF is 
only the first step. How about interoperability? 

That is, can a general mapping system have both public LCAFs and private LCAFs 
and interoperate when an xTR that doesn’t support the private space can talk to 
an xTR that does as well as two old xTRs that use the same mapping system which 
supports both?

Would a private LCAF space be limited to an instance-ID and only run within a 
VPN?

Dino

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

[lisp] Request for private LCAF allocation

[Alberto Rodriguez-Natal]

Hi all,

Based in deployment experience we have seen a need for private ad-hoc and
use-case-specific LCAF types. However, current LCAF space does not account
for a private use similar to the private IP space defined in [1].

Due to the limited LCAF space, rather than reserving a subset of types for
private use as in [1] we propose to reserve only one number (e.g. LCAF type
254). If needed, private deployments can define private subtypes encoded
within that private LCAF type. The encoding of the private LCAF (besides
the common LCAF header) is not specified and would be deployment-specific.

The purpose of requesting a LCAF type to be allocated as private, instead
of just using one of the currently unallocated types, is to avoid
collisions with future LCAF types that may appear. We would like to ask the
WG for feedback on this and to trigger the process to request a new LCAF
type to be allocated by IANA.

Thanks,
Alberto

[1] https://tools.ietf.org/html/rfc1918
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG Last Call fo document draft-ietf-lisp-signal-free-multicast-02.txt

[Victor Moreno (vimoreno)]

This is my formal/obvious vote to move the document forward.

-v

> On Mar 27, 2017, at 9:34 AM, Dino Farinacci  wrote:
> 
> Victor and I (co-authors) believe this should be moved to IESG review. That 
> might be obvious, but if the authors don’t vote . . .  ;-)
> 
> Dino
> 
>> On Mar 27, 2017, at 9:06 AM, Luigi Iannone  wrote:
>> 
>> Folks,
>> 
>> the chairs did not receive any feedback concerning this call.
>> 
>> Remember that silence is not consensus.
>> 
>> We extend the WG Last Call until next Monday April 3rd, 2017.
>> 
>> Please speak up.
>> 
>> Luigi & Joel
>> 
>>> On 11 Mar 2017, at 10:22, Luigi Iannone  wrote:
>>> 
>>> Hi All,
>>> 
>>> The authors of the LISP-Signal-Free-Multicast document 
>>> [https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-02] 
>>> asked for WG Last Call. 
>>> 
>>> This email starts the usual two weeks WG Last Call, to end March  27th, 
>>> 2017.
>>> 
>>> Please review this WG document and let the WG know if you agree that it is 
>>> ready for handing to the AD.
>>> If you have objections, please state your reasons why, and explain what it 
>>> would take to address your concerns.
>>> 
>>> Thanks
>>> 
>>> Luigi & Joel
>> 
>> ___
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

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

Re: [lisp] WG Last Call fo document draft-ietf-lisp-signal-free-multicast-02.txt

[Dino Farinacci]

Victor and I (co-authors) believe this should be moved to IESG review. That 
might be obvious, but if the authors don’t vote . . .  ;-)

Dino

> On Mar 27, 2017, at 9:06 AM, Luigi Iannone  wrote:
> 
> Folks,
> 
> the chairs did not receive any feedback concerning this call.
> 
> Remember that silence is not consensus.
> 
> We extend the WG Last Call until next Monday April 3rd, 2017.
> 
> Please speak up.
> 
> Luigi & Joel
> 
>> On 11 Mar 2017, at 10:22, Luigi Iannone  wrote:
>> 
>> Hi All,
>> 
>> The authors of the LISP-Signal-Free-Multicast document 
>> [https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-02] asked 
>> for WG Last Call. 
>> 
>> This email starts the usual two weeks WG Last Call, to end March  27th, 2017.
>> 
>> Please review this WG document and let the WG know if you agree that it is 
>> ready for handing to the AD.
>> If you have objections, please state your reasons why, and explain what it 
>> would take to address your concerns.
>> 
>> Thanks
>> 
>> Luigi & Joel
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

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

Re: [lisp] WG Last Call fo document draft-ietf-lisp-signal-free-multicast-02.txt

[Luigi Iannone]

Folks,

the chairs did not receive any feedback concerning this call.

Remember that silence is not consensus.

We extend the WG Last Call until next Monday April 3rd, 2017.

Please speak up.

Luigi & Joel

> On 11 Mar 2017, at 10:22, Luigi Iannone  wrote:
> 
> Hi All,
> 
> The authors of the LISP-Signal-Free-Multicast document 
> [https://tools.ietf.org/html/draft-ietf-lisp-signal-free-multicast-02 
> ] asked 
> for WG Last Call. 
> 
> This email starts the usual two weeks WG Last Call, to end March  27th, 2017.
> 
> Please review this WG document and let the WG know if you agree that it is 
> ready for handing to the AD.
> If you have objections, please state your reasons why, and explain what it 
> would take to address your concerns.
> 
> Thanks
> 
> Luigi & Joel

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

[lisp] Slides for Thursday's meeting

[Luigi Iannone]

To all presenters of the meeting,

Please send your slides to the chairs mailto:lisp-cha...@ietf.org>> by Wednesday evening at latest.
So that we have time to upload everything on the material page. 

Thanks

ciao

L.

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