[lisp] Re: Review draft-ietf-lisp-te

[Padma Pillay-Esnault]

Thank you 
Padma 

> On Jun 22, 2024, at 14:33, Dino Farinacci  wrote:
> 
> I will captialize.
> 
> Dino
> 
>> On Jun 22, 2024, at 9:24 AM, Padma Pillay-Esnault  
>> wrote:
>> 
>> HI Dino
>> 
>> Thanks for the updates. From draft-ietf-lisp-te
>> 
>> Otherwise, when the S-bit is set and an
>> xTR determines the RLOC is not reachable, it must not use any of
>> the remaining entries in the ELP list and drop the packet.
>> 
>> 
>> 
>> 
>> 
>> Shouldn't this be a "MUST not"?
>> Otherwise all my comments have been addressed.
>> 
>> Padma
>> 
>> 
>>> On Thu, Jun 13, 2024 at 3:16 PM Dino Farinacci  wrote:
>>> Here is where i wonder whether strict would have been best to drop the 
>>> packet and not go to n+1 per the example for SFC where there are mandatory 
>>> services.
>>> 
>>> I think it might be worthwhile to document this behavior so as there are no 
>>> surprises.
>>> Thoughts?
>> 
>> Will add. Thanks.
>> 
>> Dino
>> 
>> 
> 

___
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org

[lisp] Re: Review draft-ietf-lisp-te

[Padma Pillay-Esnault]

HI Dino

Thanks for the updates. From draft-ietf-lisp-te

 Otherwise, when the S-bit is set and an
   xTR determines the RLOC is not reachable, it must not use any of
   the remaining entries in the ELP list and drop the packet.




Shouldn't this be a "MUST not"?
Otherwise all my comments have been addressed.

Padma


On Thu, Jun 13, 2024 at 3:16 PM Dino Farinacci  wrote:

> > Here is where i wonder whether strict would have been best to drop the
> packet and not go to n+1 per the example for SFC where there are mandatory
> services.
> >
> > I think it might be worthwhile to document this behavior so as there are
> no surprises.
> > Thoughts?
>
> Will add. Thanks.
>
> Dino
>
>
>
___
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org

[lisp] Re: Review draft-ietf-lisp-te

[Padma Pillay-Esnault]

Thanks for your responses - see below

> On Jun 13, 2024, at 2:34 PM, Dino Farinacci  wrote:
> 
> 
> 
> What is the precedence between the L bit and the S bit? Must they both be 
> set to 1? What is the procedure of L
 
 There isn't one, they are treated independently.
>>> 
>>> PPE
>>> How is the decision to skip a node taken?
>>> Let’s take this example  ( n (L=1, S=0, P=0), n+1 (L=1,S=1),…., etr)
>>> 
>>> If we check S=0 first then the decision is just to Skip that hop “n” then 
>>> will not do a look up and go to next
> 
> Right, if the encapsulator thinks the RLOC for n is down, it could go to n+1.

Here is where i wonder whether strict would have been best to drop the packet 
and not go to n+1 per the example for SFC where there are mandatory services.

I think it might be worthwhile to document this behavior so as there are no 
surprises.
Thoughts?

Padma
> 
>>> reencap hop n+1 . Get a valid RLOC by performing look up for next hops in 
>>> the list. (Result “n”is skipped).
> 
> Then it looks up EID n+1 to get the RLOC for it.
> 
>>> If we check first L = 1 and then there is a valid RLOC we use the reencap 
>>> hop n regardless of whether it was skippable
>>> (Result here “n” is not skipped)
> 
> Right.
> 
>>> If S =1 then we may do a look up (Result “n” not skipped)
>>> See more below on S=1 and unreachability.
>>> 
>>> I was wondering which is the actual behavior. As the text on S=0 is a “can 
>>> skip” it seems implementation specific and still be ok.  Should some 
>>> guidance on use of L and S bit be included for clarity?  FWIW I have no 
>>> strong opinion on this.
> 
> You have to lookup the EID when L=1, you can't tell the EID is up or not, you 
> have to probe its RLOC. When you do that, you can decide not to use it and 
> move to the second one. If the S=1 is set for this EID, then you must stop 
> using the ELP.
> 
> Dino
> 

___
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org

[lisp] Re: Review draft-ietf-lisp-te

[Padma Pillay-Esnault]

Fixing a few typos

> On Jun 12, 2024, at 2:37 PM, Padma Pillay-Esnault  
> wrote:
> 
> Hi Dino
> 
> Thanks for the updates.
> 
> For the draft 17
> -section 6
> That could be the final ETR, RLOC…where it must search for itself and use the 
> next RLOC in the ELP list to encapsulate to.
> 
> This sentence a bit hard to parse. Consider to rephrase.
> 
> 
> See below PPE for responses to these comments
> 
>> On Jun 11, 2024, at 2:32 PM, Dino Farinacci  wrote:
>> 
>> I have posted -17. Here are responses to some of your comments.
>> 
>>> Do we still need to do this if the S bit is set to 0 for that hop?
>> 
>> Yes, because the list of RLOCs in the ELP can change.
> 
> PPE - Ack, i was thinking along the lines of specific skippable Reencap Hop 
> “n”.
> 
>> 
>>> What is the precedence between the L bit and the S bit? Must they both be 
>>> set to 1? What is the procedure of L
>> 
>> There isn't one, they are treated independently.
> 
> PPE
> How is the decision to skip a node taken?
> Let’s take this example  ( n (L=1, S=0, P=0), n+1 (L=1,S=1),…., etr)
> 
> If we check S=0 first then the decision is just to Skip that hop “n” then 
> will not do a look up and go to next reencap hop n+1 . Get a valid RLOC by 
> performing look up for next hops in the list. (Result “n”is skipped).
> 
> If we check first L = 1 and then there is a valid RLOC we use the reencap hop 
> n regardless of whether it was skippable
> (Result here “n” is not skipped)
> 
> If S =1 then we may do a look up (Result “n” not skipped)
> See more below on S=1 and unreachability.
> 
> I was wondering which is the actual behavior. As the text on S=0 is a “can 
> skip” it seems implementation specific and still be ok.  Should some guidance 
> on use of L and S bit be included for clarity?  FWIW I have no strong opinion 
> on this.
> 
>> 
>>> bit =1 and S bit to 0? This handling should be defined in step 3 of the 
>>> procedure
>> 
>> When you decide to use the address in the ELP entry, which is the next one 
>> in the list from a give RTR's position in it, who is encapsulating, then you 
>> do a lookup to find the RLOC for what is an EID at that position.
>>> It is must if you have L bit set. Is it appliicable  when S is set to 0 and 
>>> can be skipped?
>>> See my comment earlier clarification on their behavior would be useful.
>> 
>> No not true, the L-bit is for each entry within the ELP list. What is being 
>> explained in this paragraph is if the mapping has changed. Which means a 
>> Map-Notify is sent by the mapping system if ANY RLOC-record changes.
> 
> Ack.
>> 
>>> MUST NOT be used -
>>> As this can happen at any RTR - shouldn't this be just part of the look up 
>>> each time as a sanity check?
>>> Step 1 and Step 3?
>> 
>> Yes, it should be part of the validity check when a mapping is returned.
> Thanks
>> 
>>> but this is only valid if the S-bit is 0ff right?
>>> What happens if there is S bit set to 1 and it is unreachable?
>> 
>> No, if the RLOC is in the list and is unreachable, the actions from the 
>> paragraph are performed. If an EID is in the list and the RLOC it maps to is 
>> unreachable, the actions from the paragraph are performed.
> So even if S=1  for a hop, packets are not dropped when unreachable ? I was 
> expecting packets to be dropped  if the strict hop is not reachable.
> Consider the following example - hop x is to for antivirus screening then 
> shouldn’t packets be dropped?
>> 
>>> This processing is based on the AFI -
>> 
>> I didn't want to add that in the early section. Because it really doesn't 
>> matter what the AFI is on the RLOC (or the EID when L=1).
>> 
> Ack no strong opinion on that
> 
>> Thanks for your comments,
>> Dino
>> 
>>>> On Jun 2, 2024, at 10:40 PM, Padma Pillay-Esnault  
>>>> wrote:
>>> 
>>> Hello Authors and all.
>>> 
>>> Thanks for your patience.
>>> 
>>> First of all - I think the document describes a useful feature in LISP. 
>>> Thank you for writing this doc.
>>> 
>>> I reviewed this document after reading the ELP definition in RFC8060 
>>> section 4.6.
>>> My overall comment is that I was expecting the detailed processing of the 
>>> ELP  as  RFC8060 references this document for "details".  Therefore, I find 
>>> that the document would be improved if section 5 had  detailed processing 
>>> for all cases. I ha

[lisp] Re: Review draft-ietf-lisp-te

[Padma Pillay-Esnault]

Hello Dino and al

I will review the doc, comments, exchanges and get back to the list.
Thanks for your patience

Padma

On Thu, May 30, 2024 at 12:31 PM Dino Farinacci  wrote:

> That is correct.
>
> Dino
>
> > On May 30, 2024, at 9:53 AM, Joel Halpern  wrote:
> >
> > The question, as I understand it, is not what you want Dino.  Nor is it
> what Luigi wants.  It is what the working group wants.  I gather that Padma
> has the task of figuring that out.   Good luck Padma.
> > Yours,
> > Joel
> > On 5/30/2024 12:17 PM, Dino Farinacci wrote:
> >>
> >>
> >>> On May 30, 2024, at 6:07 AM, Luigi Iannone  wrote:
> >>>
> >>> Dino,
> >>>
> >>> Private emails, with insulting content, will not help progress the
> document.
> >>
> >> I didn’t insult you. I made a conclusion you didn’t understand
> something since I repeated the explanation several times.
> >>
> >>>
> >>> Since apparently we are not able to converge, my co-chair Padma
> accepted to handle this document from now on.
> >>
> >> Just because commenters have comments doesn’t mean all of them need
> fixing. And we need to agree to disagree.
> >>
> >>>
> >>> Please wait her review of the draft.
> >>>
> >>>
> >>>
> >>> As a participant of the LISP WG, and with no hats on, my concerns
> remain unaddressed (despite proposing very detailed and easy fixes).
> >>>
> >>> Second example in  section 4 remains unclear and misleading. See:
> https://mailarchive.ietf.org/arch/msg/lisp/CzJjLCgCZquCPOkhv56-q3DZTRE/
> >>>
> >>> The general organisation of the document can be improved.
> >>> As of now it is a bunch of use cases where for each one we see the
> same structure:
> >>>
> >>> Here is a cool thing you can do using LISP ELPs….
> >>> In order to do it you MUST do this or SHOULD do that…..
> >>>
> >>> In other words the specifications that need to be implemented are
> scattered all over the document. The risk is that people interested in one
> single use case will implement only part of the specs.
> >>
> >> I implemented it and so did cisco with no problems.
> >>
> >>> My suggestion is to move a few paragraph in one single place so to
> have the document organized in two main parts: A section with all the
> specifications; A section with all the use cases.
> >>> My first review included detailed suggestions of the few simple cut &
> paste to be done:
> https://mailarchive.ietf.org/arch/msg/lisp/3zIUevHl8ZbqfKgwjXhJ8Z-FUlA/
> >>
> >> Yes I know what you commented on. I don’t want to make the changes. I
> want to focus on all the documents that I am responsible for and this
> document is just not as important as the other ones.
> >>
> >> We have a real deadline now. I won’t be doing IETF after 2025. So now
> we have to be laser focused and not take > 5 years to move documents
> forward.
> >>
> >> Dino
> >>
> >> ___
> >> lisp mailing list -- lisp@ietf.org
> >> To unsubscribe send an email to lisp-le...@ietf.org
> >>
>
>
___
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org

Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Padma Pillay-Esnault]

> On Apr 23, 2024, at 09:25, Dino Farinacci  wrote:
> 
> My preference is to update RFC 8060.
> 
How many implementations are using RFC 8060 and will be impacted?

Thanks
 Padma

> Dino
> 
>> On Apr 23, 2024, at 12:24 PM, Joel Halpern  wrote:
>> 
>> From where I sit, doing nothing should be a non-starter.  We have a 
>> published RFC.  We are allowed to change our mind.
>> 
>> But...
>> 
>> 1) We need to be explicit about making such a change.  Which involves 
>> updating the existing RFC.
>> 
>> 2) Any such change needs to explain why it is being changed. Just because a 
>> later implementation did it differently, without a standard, does not 
>> justify changing the standard.  If there is an actual benefit to the change 
>> we should step up, admit we are changing it, and explain why.
>> 
>> Yours,
>> 
>> Joel
>> 
>> On 4/23/2024 11:48 AM, Dino Farinacci wrote:
 As I said, the simplest solution is to use a different type value. This 
 allows to still use the old encoding and does not obsoletes 
 implementations that use it.
>>> You will obsolete implementations if we do that. Which really means you 
>>> make the spec irrelevant. So I say stay with the same code point.
>>> 
 Option B. This document officially updates 8060, but this means that 
 existing implementation of the 8060 encoding are not valid anymore.
>>> Right. But so much time has passed between from when the lisp-geo spec was 
>>> published I believe most implementations have done lisp-geo encoding vs RFC 
>>> 8060. My lispers.net implementation does the lisp-geo encoding with the 
>>> type defined in the draft which is the same as RFC 8060.
>>> 
 How many implementation of this draft are you aware of?
>>> I think cisco and lispers.net. But cisco has to confirm.
>>> 
>>> I think we should do Option C which is do nothing to RFC 8060 and put text 
>>> in the lisp-geo spec which indicates its encoding takes precedent over RFC 
>>> 8060 using the same code point and document all implementations have 
>>> evolved to the lisp-geo spec.
>>> 
>>> Dino
>>> 
>>> 
>>> ___
>>> 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

[lisp] Draft LISP Geo-Coordinate Use-Cases

[Padma Pillay-Esnault]

Hello Dino and Alberto

The  Yang Doctor review had comments on Yang -20 draft regarding the
geoloc.
For reference comment from Joe Clark

As to the two questions asked here, I can see some benefit of breaking
out the IANA parts of address-types into a module that they maintain.
But in its current form, I don't know that it makes sense to have them
maintain it.  As for geoloc, I do see some overlap, but I am not a
LISP expert at all, so I cannot comment as to whether bringing that
whole module in makes sense or would even work with LISP
implementations.  That is, it seems LISP lat and long are expressed in
degrees° minutes'seconds" whereas geoloc does this as a decimal64 from
a reference frame.  I do feel that whatever direction is taken, text
explaining why geoloc is not used is useful.


Per Med's comment on groupings -
https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/

Consolidating these comments in a single thread here for resolution and
discussion on the list before the refresh,

Thanks
Padma and Luigi
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] I-D Action: draft-ietf-lisp-yang-21.txt

[Padma Pillay-Esnault]

Hi Alberto and authors

Thank you for refreshing this draft.

Will you be addressing the comments by Joe Clarke on -20 ( Yang doctors)
 in a subsequent version?
For your reference, his comments pasted below.

I am the latest member of YANG Doctors to review this document and the modules
therein.  I looked over chopps' previous review, and it appears most of his
comments have been addressed.  In my own reading, I found inconsistent use of
capitalization and punctuation in descriptions (e.g., some ended in periods,
some did not; most started with a capital letter, some did not); as well as
inconsistent quoting.  All modules would benefit from a `pyang -f yang`
normalization and an editorial pass.

In the ietf-lisp module itself, there are a couple of patterns in there where I
wonder if the regex is what you want exactly.  For example, is it okay if an
eid-id starts with a ':' or a '-'?  For the locator-id, this is a string of
1-64 characters, but the regex hints it could be zero or more of the character
class (a similar example exists with hop-id in address-types).

All modules' initial revisions reference the original LISP RFC but do so with a
URL only vs. a more correct, RFC 6830
: ... syntax.  And speaking
of revision,
most of the modules have a revision of 2021-02-22 with the exception of itr and
mapresolver.  This isn't a big deal now, as I assume you'll set all of these
when the draft is finalized.  You should also update all of the copyright years
and copyright text.

As to the two questions asked here, I can see some benefit of breaking out the
IANA parts of address-types into a module that they maintain.  But in its
current form, I don't know that it makes sense to have them maintain it.  As
for geoloc, I do see some overlap, but I am not a LISP expert at all, so I
cannot comment as to whether bringing that whole module in makes sense or would
even work with LISP implementations.  That is, it seems LISP lat and long are
expressed in degrees° minutes'seconds" whereas geoloc does this as a decimal64
from a reference frame.  I do feel that whatever direction is taken, text
explaining why geoloc is not used is useful.


Thanks
Padma and Luigi

On Mon, Apr 15, 2024 at 1:16 PM  wrote:

> Internet-Draft draft-ietf-lisp-yang-21.txt is now available. It is a work
> item
> of the Locator/ID Separation Protocol (LISP) WG of the IETF.
>
>Title:   LISP YANG Model
>Authors: Vina Ermagan
> Alberto Rodriguez-Natal
> Florin Coras
> Carl Moberg
> Reshad Rahman
> Albert Cabellos-Aparicio
> Fabio Maino
>Name:draft-ietf-lisp-yang-21.txt
>Pages:   82
>Dates:   2024-04-15
>
> Abstract:
>
>This document describes a YANG data model to use with the Locator/ID
>Separation Protocol (LISP).
>
>The YANG modules in this document conform to the Network Management
>Datastore Architecture (NMDA).
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-yang-21
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-yang-21
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> 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] John Scudder's No Objection on charter-ietf-lisp-04-06: (with COMMENT)

[Padma Pillay-Esnault]

Hi John

Please see  PPE for my comments inline.

On Wed, Jan 3, 2024 at 4:47 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:

> John Scudder has entered the following ballot position for
> charter-ietf-lisp-04-06: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>
>
>
> --
> COMMENT:
> --
>
> “LISP deployments could benefit from more advanced internet-working”
>
> Should this be “interworking”? If not, why not?
>
> PPE - Thanks for catching this.

Original:
“LISP deployments could benefit from more advanced internet-working”

Proposed:
“LISP deployments could benefit from more advanced interworking”


Editorial:
>
> s/identified by the working as main LISP applications/identified by the
> working
> group as main LISP applications/ (add “group”)


> s/The management of LISP protocol and deployments include data models,
> OAM/The
> management of LISP protocol and deployments including data models, OAM/
> (“include” should be “including”)



> s/leveraging on/leveraging/ (remove “on”)
>


PPE - Agree with all changes proposed above


s/LISP tunnel endpoints are separated from by a NAT/LISP tunnel endpoints
> are
> separated from one another by a NAT/ (add “one another”)
>
> PPE -
The original was modified into Proposed. The New Proposed includes your
editorial comment and Martin's comments

Original:
NAT-Traversal: Support for a NAT-traversal solution in deployments where
LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).

Proposed:
NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
solution in deployments where LISP tunnel endpoints are separated from by a
NAT (e.g., LISP mobile node). The LISP WG will collaborate with the TSVWG
working on NAT-Transversal.

New Proposed:
NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
solution in deployments where LISP tunnel endpoints are separated from one
another by a NAT (e.g., LISP mobile node). The LISP WG will collaborate
with the TSVWG working on NAT-Transversal.

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

Re: [lisp] Martin Duke's Block on charter-ietf-lisp-04-06: (with BLOCK and COMMENT)

[Padma Pillay-Esnault]

Sure. New proposed changes.

Original:
NAT-Traversal: Support for a NAT-traversal solution in deployments where
LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).

Proposed:
NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
solution in deployments where LISP tunnel endpoints are separated from by a
NAT (e.g., LISP mobile node). The LISP WG will collaborate with the TSVWG
working on NAT-Transversal.

On Thu, Jan 4, 2024 at 11:12 AM Martin Duke  wrote:

> Sure, but please add the TSVWG reference for NAT.
>
>
>
> On Thu, Jan 4, 2024 at 11:10 AM Padma Pillay-Esnault 
> wrote:
>
>> Would these changes address your feedback?
>>
>> Clarified the text as we are not building a new NAT solution but rather
>> adding LISP extensions needed to make it work.
>>
>> Original:
>> NAT-Traversal: Support for a NAT-traversal solution in deployments where
>> LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).
>>
>> Proposed:
>> NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
>> solution in deployments where LISP tunnel endpoints are separated from by a
>> NAT (e.g., LISP mobile node)
>>
>> and
>>
>> Original:
>> Map Server Reliable Transport: LISP control plane messages are
>> transported over UDP, however, in some cases, the use of a reliable
>> transport protocol is a better fit, since it actually helps reduce periodic
>> signaling.
>>
>> Proposed:
>> Map Server Reliable Transport: LISP control plane messages are
>> transported over UDP, however, in some cases, the use of a reliable
>> transport protocol *(such as TCP)*  is a better fit, since it actually
>> helps reduce periodic signaling.
>> Thanks
>> Padma
>>
>> On Thu, Jan 4, 2024 at 9:00 AM Martin Duke 
>> wrote:
>>
>>> SG, please mention these points in the text.
>>>
>>> On Thu, Jan 4, 2024 at 8:38 AM Padma Pillay-Esnault <
>>> padma.i...@gmail.com> wrote:
>>>
>>>> Hi Martin
>>>>
>>>> Please see PPE for my comments inline
>>>>
>>>> On Tue, Jan 2, 2024 at 11:50 AM Martin Duke via Datatracker <
>>>> nore...@ietf.org> wrote:
>>>>
>>>>> Martin Duke has entered the following ballot position for
>>>>> charter-ietf-lisp-04-06: Block
>>>>>
>>>>> When responding, please keep the subject line intact and reply to all
>>>>> email addresses included in the To and CC lines. (Feel free to cut this
>>>>> introductory paragraph, however.)
>>>>>
>>>>>
>>>>>
>>>>> The document, along with other ballot positions, can be found here:
>>>>> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> BLOCK:
>>>>> --
>>>>>
>>>>> Is the NAT traversal work going to prioritize existing solutions (e.g.
>>>>> STUN,
>>>>> TURN, ICE), or have all those already been determined to be
>>>>> inadequate? If the
>>>>> latter, LISP should coordinate with TSVWG on its NAT traversal
>>>>> solution.
>>>>>
>>>>> PPE - The symmetric or endpoint-address-and-port-dependent mapping
>>>>> NATs (ICE, TURN..) have been  have been determined to be inadequate
>>>>> due to the nature of LISP that is typically unidirectional traffic and its
>>>>> usage of UDP port 4341 without specification of source port.
>>>>>
>>>> Yes - on coordination with TSVWG.
>>>>>
>>>>
>>>>
>>>>> --
>>>>> COMMENT:
>>>>> --
>>>>>
>>>>> Is the reliable transport protocol required to be secure? (e.g., are
>>>>> you
>>>>> looking at TCP/TLS, QUIC, and SCTP/DTLS, or just bare TCP/SCTP)
>>>>>
>>>>> PPE - The current reliable transport draft has a proposal for the use
>>>>> of bare TCP and fallback to UDP using the existing mechanisms for security
>>>>> in LISP. The document is being evaluated and reviewed.
>>>>>
>>>>>
>>>> Thanks
>>>> Padma
>>>>
>>>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Martin Duke's Block on charter-ietf-lisp-04-06: (with BLOCK and COMMENT)

[Padma Pillay-Esnault]

Would these changes address your feedback?

Clarified the text as we are not building a new NAT solution but rather
adding LISP extensions needed to make it work.

Original:
NAT-Traversal: Support for a NAT-traversal solution in deployments where
LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node).

Proposed:
NAT-Traversal: *LISP protocol extensions to* support a NAT-traversal
solution in deployments where LISP tunnel endpoints are separated from by a
NAT (e.g., LISP mobile node)

and

Original:
Map Server Reliable Transport: LISP control plane messages are transported
over UDP, however, in some cases, the use of a reliable transport protocol
is a better fit, since it actually helps reduce periodic signaling.

Proposed:
Map Server Reliable Transport: LISP control plane messages are transported
over UDP, however, in some cases, the use of a reliable transport
protocol *(such
as TCP)*  is a better fit, since it actually helps reduce periodic
signaling.
Thanks
Padma

On Thu, Jan 4, 2024 at 9:00 AM Martin Duke  wrote:

> SG, please mention these points in the text.
>
> On Thu, Jan 4, 2024 at 8:38 AM Padma Pillay-Esnault 
> wrote:
>
>> Hi Martin
>>
>> Please see PPE for my comments inline
>>
>> On Tue, Jan 2, 2024 at 11:50 AM Martin Duke via Datatracker <
>> nore...@ietf.org> wrote:
>>
>>> Martin Duke has entered the following ballot position for
>>> charter-ietf-lisp-04-06: Block
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>>>
>>>
>>>
>>> --
>>> BLOCK:
>>> --
>>>
>>> Is the NAT traversal work going to prioritize existing solutions (e.g.
>>> STUN,
>>> TURN, ICE), or have all those already been determined to be inadequate?
>>> If the
>>> latter, LISP should coordinate with TSVWG on its NAT traversal solution.
>>>
>>> PPE - The symmetric or endpoint-address-and-port-dependent mapping NATs
>>> (ICE, TURN..) have been  have been determined to be inadequate due to
>>> the nature of LISP that is typically unidirectional traffic and its usage
>>> of UDP port 4341 without specification of source port.
>>>
>> Yes - on coordination with TSVWG.
>>>
>>
>>
>>> --
>>> COMMENT:
>>> --
>>>
>>> Is the reliable transport protocol required to be secure? (e.g., are you
>>> looking at TCP/TLS, QUIC, and SCTP/DTLS, or just bare TCP/SCTP)
>>>
>>> PPE - The current reliable transport draft has a proposal for the use of
>>> bare TCP and fallback to UDP using the existing mechanisms for security in
>>> LISP. The document is being evaluated and reviewed.
>>>
>>>
>> Thanks
>> Padma
>>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Roman Danyliw's Block on charter-ietf-lisp-04-06: (with BLOCK and COMMENT)

[Padma Pillay-Esnault]

Hi Roman

Please see PPE for my comments inline

On Wed, Jan 3, 2024 at 1:14 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> charter-ietf-lisp-04-06: Block
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>
>
>
> --
> BLOCK:
> --
>
> Per the following set of work "Privacy and Security: The WG will work on
> EID
> anonymity, VPN segmentation leveraging on the Instance ID, and traffic
> anonymization. The reuse of existing mechanisms will be prioritized.":
>
> -- What is the threat model assumed for "traffic anonymization" and "EID
> anonymity"?  Could the desired security properties be clarified?
>
> PPE - LISP has an (EID, Routing Location) pair, it is possible to learn of
> a specific long lived EID and then poll the mapping system to know its new
> bindings over time. It would be therefore possible to record and track long
> lived EIDs and identify the traffic specifically for that endpoint. Some
> desired security properties would be to have short lived EIDs as well as
> secured and restricted access to binding of an EID and locator for privacy.
>


> --
> COMMENT:
> --
>
> Per the following set of work "Privacy and Security: The WG will work on
> EID
> anonymity, VPN segmentation leveraging on the Instance ID, and traffic
> anonymization. The reuse of existing mechanisms will be prioritized.":
>
> -- What will the output of this work look like?  Which milestone is it
> associated with?
>
> PPE - There are currently 2 WG drafts and the milestone is
> March 2025 Submit LISP Privacy and Security document(s) to the IESG for
> consideration (Privacy and Security) [EXPERIMENTAL]
>
> Thanks
Padma
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Martin Duke's Block on charter-ietf-lisp-04-06: (with BLOCK and COMMENT)

[Padma Pillay-Esnault]

Hi Martin

Please see PPE for my comments inline

On Tue, Jan 2, 2024 at 11:50 AM Martin Duke via Datatracker <
nore...@ietf.org> wrote:

> Martin Duke has entered the following ballot position for
> charter-ietf-lisp-04-06: Block
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-lisp/
>
>
>
> --
> BLOCK:
> --
>
> Is the NAT traversal work going to prioritize existing solutions (e.g.
> STUN,
> TURN, ICE), or have all those already been determined to be inadequate? If
> the
> latter, LISP should coordinate with TSVWG on its NAT traversal solution.
>
> PPE - The symmetric or endpoint-address-and-port-dependent mapping NATs
> (ICE, TURN..) have been  have been determined to be inadequate due to the
> nature of LISP that is typically unidirectional traffic and its usage of
> UDP port 4341 without specification of source port.
>
Yes - on coordination with TSVWG.
>


> --
> COMMENT:
> --
>
> Is the reliable transport protocol required to be secure? (e.g., are you
> looking at TCP/TLS, QUIC, and SCTP/DTLS, or just bare TCP/SCTP)
>
> PPE - The current reliable transport draft has a proposal for the use of
> bare TCP and fallback to UDP using the existing mechanisms for security in
> LISP. The document is being evaluated and reviewed.
>
>
Thanks
Padma
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

Hi All

I have made another pass to integrate Alvaro's editorial changes.
Please review and approve.

https://github.com/lisp-wg/wg-charter/pull/12/files

Thanks
Padma

On Sat, Oct 21, 2023 at 1:06 AM Padma Pillay-Esnault 
wrote:

> Approved and Merged.
>
> Padma
>
> On Fri, Oct 20, 2023 at 8:15 AM Alberto Rodriguez-Natal (natal) <
> na...@cisco.com> wrote:
>
>> Sounds good, updated.
>>
>>
>>
>> Alberto
>>
>>
>>
>> *From: *Dino Farinacci 
>> *Date: *Friday, October 20, 2023 at 4:02 PM
>> *To: *Alberto Rodriguez-Natal (natal) 
>> *Cc: *Padma Pillay-Esnault , Luigi Iannone <
>> g...@gigix.net>, LISP mailing list list ,
>> lisp-cha...@ietf.org 
>> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter
>> on GitHub]
>>
>> I would phrase it “LISP xTRs” rather than “tunnel routers”.
>>
>>
>>
>> Dino
>>
>>
>>
>> On Oct 20, 2023, at 2:26 AM, Alberto Rodriguez-Natal (natal) <
>> na...@cisco.com> wrote:
>>
>> 
>>
>> Hi Padma,
>>
>>
>>
>> Fixes seem fine to me, thanks!
>>
>>
>>
>> Maybe another suggestion, how about this text for mobility?
>>
>> “Mobility: Some LISP deployment scenarios include endpoints that move
>> across different tunnel routers and/or tunnel routers that are themselves
>> mobile, hence, support needs to be provided in order to achieve seamless
>> connectivity.”
>>
>>
>>
>> https://github.com/lisp-wg/wg-charter/pull/11/
>>
>>
>>
>> Thanks!
>>
>> Alberto
>>
>> *From: *Padma Pillay-Esnault 
>> *Date: *Friday, October 20, 2023 at 7:53 AM
>> *To: *Alberto Rodriguez-Natal (natal) 
>> *Cc: *Luigi Iannone , Dino Farinacci ,
>> LISP mailing list list , lisp-cha...@ietf.org <
>> lisp-cha...@ietf.org>
>> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter
>> on GitHub]
>>
>> Hi everyone,
>>
>>
>>
>> I fixed some nits and addressed my previous editorial comments on "Moving
>> to Standards Track:" and "Yang Model:".
>>
>> It can be found here https://github.com/lisp-wg/wg-charter/pull/10/files.
>>
>>
>>
>> Let me know if you have any further comments.
>>
>>
>>
>> Thanks
>>
>> Padma
>>
>>
>>
>> On Wed, Oct 18, 2023 at 11:38 PM Padma Pillay-Esnault <
>> padma.i...@gmail.com> wrote:
>>
>> Approved and merged.
>>
>>
>>
>>
>>
>> On Wed, Oct 18, 2023 at 10:05 AM Alberto Rodriguez-Natal (natal) <
>> na...@cisco.com> wrote:
>>
>> Hi all,
>>
>>
>>
>> I just sent a PullRequest in GitHub with some edits. You can find it
>> here: https://github.com/lisp-wg/wg-charter/pull/9
>>
>>
>>
>> To keep the discussion on the list, here are the main points:
>>
>> - I switched the Name Encoding and Yang deliverable dates. I have action
>> items on both (shepherd for the first and author for the second), and I
>> feel Yang might require some time to get it done, while Name Encoding is
>> almost there. I don’t think flipping these two dates has major implications.
>>
>>
>>
>> - I removed this sentence from the Yang item: “These management methods
>> should be considered for both the data-plane, control plane, and mapping
>> system components.” I think it is probably redundant and it might
>> confuse more than clarify (isn’t mapping system a subset of control plane?)
>>
>>
>>
>> - I polished the language on the milestones to be consistent across the
>> different items (using the same sentence structure, etc). I also use
>> “document(s)” for the document bundles and those items further in the
>> future, so we are flexible in how to address them.
>>
>>
>>
>> Other than that, it’s just minor edits. Let me know if you have any
>> comment.
>>
>>
>>
>> Thanks!
>>
>> Alberto
>>
>>
>>
>>
>>
>> *From: *Luigi Iannone 
>> *Date: *Tuesday, October 17, 2023 at 2:01 PM
>> *To: *Padma Pillay-Esnault 
>> *Cc: *Dino Farinacci , LISP mailing list list <
>> lisp@ietf.org>, lisp-cha...@ietf.org 
>> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter
>> on GitHub]
>>
>> Hi Dino, Padma,
>>
>>
>>
>> The list of milestones I proposed does not have more than 2 item per
>> deadline, which is reaso

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

Approved and Merged.

Padma

On Fri, Oct 20, 2023 at 8:15 AM Alberto Rodriguez-Natal (natal) <
na...@cisco.com> wrote:

> Sounds good, updated.
>
>
>
> Alberto
>
>
>
> *From: *Dino Farinacci 
> *Date: *Friday, October 20, 2023 at 4:02 PM
> *To: *Alberto Rodriguez-Natal (natal) 
> *Cc: *Padma Pillay-Esnault , Luigi Iannone <
> g...@gigix.net>, LISP mailing list list ,
> lisp-cha...@ietf.org 
> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on
> GitHub]
>
> I would phrase it “LISP xTRs” rather than “tunnel routers”.
>
>
>
> Dino
>
>
>
> On Oct 20, 2023, at 2:26 AM, Alberto Rodriguez-Natal (natal) <
> na...@cisco.com> wrote:
>
> 
>
> Hi Padma,
>
>
>
> Fixes seem fine to me, thanks!
>
>
>
> Maybe another suggestion, how about this text for mobility?
>
> “Mobility: Some LISP deployment scenarios include endpoints that move
> across different tunnel routers and/or tunnel routers that are themselves
> mobile, hence, support needs to be provided in order to achieve seamless
> connectivity.”
>
>
>
> https://github.com/lisp-wg/wg-charter/pull/11/
>
>
>
> Thanks!
>
> Alberto
>
> *From: *Padma Pillay-Esnault 
> *Date: *Friday, October 20, 2023 at 7:53 AM
> *To: *Alberto Rodriguez-Natal (natal) 
> *Cc: *Luigi Iannone , Dino Farinacci ,
> LISP mailing list list , lisp-cha...@ietf.org <
> lisp-cha...@ietf.org>
> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on
> GitHub]
>
> Hi everyone,
>
>
>
> I fixed some nits and addressed my previous editorial comments on "Moving
> to Standards Track:" and "Yang Model:".
>
> It can be found here https://github.com/lisp-wg/wg-charter/pull/10/files.
>
>
>
> Let me know if you have any further comments.
>
>
>
> Thanks
>
> Padma
>
>
>
> On Wed, Oct 18, 2023 at 11:38 PM Padma Pillay-Esnault <
> padma.i...@gmail.com> wrote:
>
> Approved and merged.
>
>
>
>
>
> On Wed, Oct 18, 2023 at 10:05 AM Alberto Rodriguez-Natal (natal) <
> na...@cisco.com> wrote:
>
> Hi all,
>
>
>
> I just sent a PullRequest in GitHub with some edits. You can find it here:
> https://github.com/lisp-wg/wg-charter/pull/9
>
>
>
> To keep the discussion on the list, here are the main points:
>
> - I switched the Name Encoding and Yang deliverable dates. I have action
> items on both (shepherd for the first and author for the second), and I
> feel Yang might require some time to get it done, while Name Encoding is
> almost there. I don’t think flipping these two dates has major implications.
>
>
>
> - I removed this sentence from the Yang item: “These management methods
> should be considered for both the data-plane, control plane, and mapping
> system components.” I think it is probably redundant and it might confuse
> more than clarify (isn’t mapping system a subset of control plane?)
>
>
>
> - I polished the language on the milestones to be consistent across the
> different items (using the same sentence structure, etc). I also use
> “document(s)” for the document bundles and those items further in the
> future, so we are flexible in how to address them.
>
>
>
> Other than that, it’s just minor edits. Let me know if you have any
> comment.
>
>
>
> Thanks!
>
> Alberto
>
>
>
>
>
> *From: *Luigi Iannone 
> *Date: *Tuesday, October 17, 2023 at 2:01 PM
> *To: *Padma Pillay-Esnault 
> *Cc: *Dino Farinacci , LISP mailing list list <
> lisp@ietf.org>, lisp-cha...@ietf.org 
> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on
> GitHub]
>
> Hi Dino, Padma,
>
>
>
> The list of milestones I proposed does not have more than 2 item per
> deadline, which is reasonable to me.
>
> However, some milestones do indeed refer to several documents like Privacy
> and Security, Multicast, and mobility.
>
> IMO there is no need to list the detailed documents and if we finish
> before the schedule this is a plus not a problem.
>
>
>
> Since Nov 2023 is in 2 weeks I agree with Padma that there is no need to
> rush.
>
>
>
> The name encoding document was indeed missing, since it is a simple
> document we can publish it by March 2024.
>
>
>
> The update list looks like:
>
>
>
> 1. November 2023: Submit a LISP Yang model document to the IESG for
> consideration
>
> 2. March 2024: Submit LISP Traffic Engineering document to the IESG for
> consideration
>
> 3. March 2024: Submit LISP Reliable Transport document to the IESG for
> consideration
>
> 4. March 2024

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

Hi everyone,

I fixed some nits and addressed my previous editorial comments on "Moving
to Standards Track:" and "Yang Model:".
It can be found here https://github.com/lisp-wg/wg-charter/pull/10/files.

Let me know if you have any further comments.

Thanks
Padma

On Wed, Oct 18, 2023 at 11:38 PM Padma Pillay-Esnault 
wrote:

> Approved and merged.
>
>
> On Wed, Oct 18, 2023 at 10:05 AM Alberto Rodriguez-Natal (natal) <
> na...@cisco.com> wrote:
>
>> Hi all,
>>
>>
>>
>> I just sent a PullRequest in GitHub with some edits. You can find it
>> here: https://github.com/lisp-wg/wg-charter/pull/9
>>
>>
>>
>> To keep the discussion on the list, here are the main points:
>>
>> - I switched the Name Encoding and Yang deliverable dates. I have action
>> items on both (shepherd for the first and author for the second), and I
>> feel Yang might require some time to get it done, while Name Encoding is
>> almost there. I don’t think flipping these two dates has major implications.
>>
>>
>>
>> - I removed this sentence from the Yang item: “These management methods
>> should be considered for both the data-plane, control plane, and mapping
>> system components.” I think it is probably redundant and it might
>> confuse more than clarify (isn’t mapping system a subset of control plane?)
>>
>>
>>
>> - I polished the language on the milestones to be consistent across the
>> different items (using the same sentence structure, etc). I also use
>> “document(s)” for the document bundles and those items further in the
>> future, so we are flexible in how to address them.
>>
>>
>>
>> Other than that, it’s just minor edits. Let me know if you have any
>> comment.
>>
>>
>>
>> Thanks!
>>
>> Alberto
>>
>>
>>
>>
>>
>> *From: *Luigi Iannone 
>> *Date: *Tuesday, October 17, 2023 at 2:01 PM
>> *To: *Padma Pillay-Esnault 
>> *Cc: *Dino Farinacci , LISP mailing list list <
>> lisp@ietf.org>, lisp-cha...@ietf.org 
>> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter
>> on GitHub]
>>
>> Hi Dino, Padma,
>>
>>
>>
>> The list of milestones I proposed does not have more than 2 item per
>> deadline, which is reasonable to me.
>>
>> However, some milestones do indeed refer to several documents like
>> Privacy and Security, Multicast, and mobility.
>>
>> IMO there is no need to list the detailed documents and if we finish
>> before the schedule this is a plus not a problem.
>>
>>
>>
>> Since Nov 2023 is in 2 weeks I agree with Padma that there is no need to
>> rush.
>>
>>
>>
>> The name encoding document was indeed missing, since it is a simple
>> document we can publish it by March 2024.
>>
>>
>>
>> The update list looks like:
>>
>>
>>
>> 1. November 2023: Submit a LISP Yang model document to the IESG for
>> consideration
>>
>> 2. March 2024: Submit LISP Traffic Engineering document to the IESG for
>> consideration
>>
>> 3. March 2024: Submit LISP Reliable Transport document to the IESG for
>> consideration
>>
>> 4. March 2024: Submit LISP Name Encoding document to the IESG for
>> consideration
>>
>> 5. June 2024 : Submit LISP geo-coordinates to the IESG for consideration
>>
>> 6. June 2024: Submit a LISP NAT Traversal document to the IESG for
>> consideration
>>
>> 7. November 2024: Submit 8111bis to the IESG for consideration
>>
>> 8. November 2024: Submit merged LCAFbis document to the IESG for
>> consideration
>>
>> 9. March 2025: Submit LISP Privacy and Security documents to the IESG for
>> consideration
>>
>> 10. March 2025: Submit 6832bis Proxy XTRs document to the IESG for
>> consideration
>>
>> 11. June 2025: Submit LISP Mobile documents to the IESG for consideration
>>
>> 12. November 2025: Submit Multicast documents to the IESG for
>> consideration
>>
>> 13. March 2026: Submit LISP Applicability document to the IESG for
>> consideration
>>
>> 14. November 2026: Wrap-Up or recharter
>>
>>
>>
>>
>>
>> Better?
>>
>>
>>
>> L.
>>
>>
>>
>>
>>
>> On Oct 17, 2023, at 01:46, Padma Pillay-Esnault 
>> wrote:
>>
>>
>>
>> Hi Dino
>>
>>
>>
>> The groupings look good!
>>
>>
>>
>> Some dates look too aggress

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

Approved and merged.


On Wed, Oct 18, 2023 at 10:05 AM Alberto Rodriguez-Natal (natal) <
na...@cisco.com> wrote:

> Hi all,
>
>
>
> I just sent a PullRequest in GitHub with some edits. You can find it here:
> https://github.com/lisp-wg/wg-charter/pull/9
>
>
>
> To keep the discussion on the list, here are the main points:
>
> - I switched the Name Encoding and Yang deliverable dates. I have action
> items on both (shepherd for the first and author for the second), and I
> feel Yang might require some time to get it done, while Name Encoding is
> almost there. I don’t think flipping these two dates has major implications.
>
>
>
> - I removed this sentence from the Yang item: “These management methods
> should be considered for both the data-plane, control plane, and mapping
> system components.” I think it is probably redundant and it might confuse
> more than clarify (isn’t mapping system a subset of control plane?)
>
>
>
> - I polished the language on the milestones to be consistent across the
> different items (using the same sentence structure, etc). I also use
> “document(s)” for the document bundles and those items further in the
> future, so we are flexible in how to address them.
>
>
>
> Other than that, it’s just minor edits. Let me know if you have any
> comment.
>
>
>
> Thanks!
>
> Alberto
>
>
>
>
>
> *From: *Luigi Iannone 
> *Date: *Tuesday, October 17, 2023 at 2:01 PM
> *To: *Padma Pillay-Esnault 
> *Cc: *Dino Farinacci , LISP mailing list list <
> lisp@ietf.org>, lisp-cha...@ietf.org 
> *Subject: *Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on
> GitHub]
>
> Hi Dino, Padma,
>
>
>
> The list of milestones I proposed does not have more than 2 item per
> deadline, which is reasonable to me.
>
> However, some milestones do indeed refer to several documents like Privacy
> and Security, Multicast, and mobility.
>
> IMO there is no need to list the detailed documents and if we finish
> before the schedule this is a plus not a problem.
>
>
>
> Since Nov 2023 is in 2 weeks I agree with Padma that there is no need to
> rush.
>
>
>
> The name encoding document was indeed missing, since it is a simple
> document we can publish it by March 2024.
>
>
>
> The update list looks like:
>
>
>
> 1. November 2023: Submit a LISP Yang model document to the IESG for
> consideration
>
> 2. March 2024: Submit LISP Traffic Engineering document to the IESG for
> consideration
>
> 3. March 2024: Submit LISP Reliable Transport document to the IESG for
> consideration
>
> 4. March 2024: Submit LISP Name Encoding document to the IESG for
> consideration
>
> 5. June 2024 : Submit LISP geo-coordinates to the IESG for consideration
>
> 6. June 2024: Submit a LISP NAT Traversal document to the IESG for
> consideration
>
> 7. November 2024: Submit 8111bis to the IESG for consideration
>
> 8. November 2024: Submit merged LCAFbis document to the IESG for
> consideration
>
> 9. March 2025: Submit LISP Privacy and Security documents to the IESG for
> consideration
>
> 10. March 2025: Submit 6832bis Proxy XTRs document to the IESG for
> consideration
>
> 11. June 2025: Submit LISP Mobile documents to the IESG for consideration
>
> 12. November 2025: Submit Multicast documents to the IESG for consideration
>
> 13. March 2026: Submit LISP Applicability document to the IESG for
> consideration
>
> 14. November 2026: Wrap-Up or recharter
>
>
>
>
>
> Better?
>
>
>
> L.
>
>
>
>
>
> On Oct 17, 2023, at 01:46, Padma Pillay-Esnault 
> wrote:
>
>
>
> Hi Dino
>
>
>
> The groupings look good!
>
>
>
> Some dates look too aggressive Nov 2023:  draft-ietf-lisp-geo,
> draft-ietf-lisp-name-encoding, RFC 8060 and 9306 (Standards Track). We are
> already there ...
>
> As the dates proposed are target dates, i suggest we keep the date of June
> 2024 but if we can go faster it is all good. thoughts?
>
>
>
> Similar comment for mobility.
>
>
>
> Thanks
>
> Padma
>
>
>
> On Mon, Oct 16, 2023 at 4:35 PM Dino Farinacci 
> wrote:
>
> > What do you think of putting some major milestones for mobility and
> security sections rather than per document?
>
> I think security is further out compared to mobility. Just because other
> groups will have to peer-review the security documents. But good suggestion
> and will incldue below the set that go together (IMO).
>
> So here is what I suggest:
>
> For June 2024: Mobility documents as a set to IESG, which incl

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

Hi Dino

The groupings look good!

Some dates look too aggressive Nov 2023:  draft-ietf-lisp-geo,
draft-ietf-lisp-name-encoding, RFC 8060 and 9306 (Standards Track). We are
already there ...
As the dates proposed are target dates, i suggest we keep the date of June
2024 but if we can go faster it is all good. thoughts?

Similar comment for mobility.

Thanks
Padma

On Mon, Oct 16, 2023 at 4:35 PM Dino Farinacci  wrote:

> > What do you think of putting some major milestones for mobility and
> security sections rather than per document?
>
> I think security is further out compared to mobility. Just because other
> groups will have to peer-review the security documents. But good suggestion
> and will incldue below the set that go together (IMO).
>
> So here is what I suggest:
>
> For June 2024: Mobility documents as a set to IESG, which include:
>
>   draft-ietf-lisp-eid-mobility, draft-ietf-lisp-mn,
> draft-ietf-lisp-predictive-rlocs, draft-ietf-lisp-vpn
>
> And for June 2025: Security documents as a set to IESG, which include:
>
>   draft-ietf-lisp-crypto (RFC8061 to Standards Track),
> draft-ietf-lisp-ecdsa-auth, draft-ietf-lisp-eid-anonymity
>
> And then, not related to what you asked for, to put all LCAF related stuff
> in one set:
>
> For Nov 2023:
>
>   draft-ietf-lisp-geo, draft-ietf-lisp-name-encoding, RFC 8060 and 9306
> (Standards Track)
>
> What do you think?
>
> Dino
>
>
>
>
>
>
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

Hi Dino

Thank you for the comments.

What do you think of putting some major milestones for mobility and
security sections rather than per document?

Padma



On Mon, Oct 16, 2023 at 12:31 PM Dino Farinacci  wrote:

> Looking at what you put earlier versus later is not based on the reality
> of the readiness of the documents. Here are some comments:
>
> (1) Nov 2023 should be Submit Name-Encoding to IESG.
> (2) Geo-Coordinates has been stable for a long time where NAT-traversal is
> so far from ready. The June date for NAT-traversal is too aggressive.
> Geo-Coordinates should be Nov 2023.
> (3) There is no mention of the VPN document. That too has been running for
> a decade and stable. That should be submitted Nov 2023 or at least Mar 2024.
> (4) What about the other mobility drafts that go along with LISP Mobile
> Node?
> (5) What about the security drafts?

Seems the list below is not complete to me.
>
> Dino
>
> > On Oct 16, 2023, at 6:52 AM, Luigi Iannone  wrote:
> >
> > Good points Padma,
> >
> >
> > What about the following ordering?
> >
> > 1. November 2023: Submit a LISP Yang model document to the IESG for
> consideration
> > 2. March 2024: Submit LISP Traffic Engineering document to the IESG for
> consideration
> > 3. March 2024: Submit LISP Reliable Transport document to the IESG for
> consideration
> > 4. June 2024 : Submit LISP geo-coordinates for consideration
> > 5. June 2024: Submit a LISP NAT Traversal document to the IESG for
> consideration
> > 6. November 2024: Submit 8111bis to the IESG for consideration
> > 7. November 2024: Submit merged LCAFbis document to the IESG for
> consideration
> > 8. March 2025: Submit LISP Privacy and Security documents to the IESG
> for consideration
> > 9. March 2025: Submit 6832bis Proxy XTRs document to the IESG for
> consideration
> > 10. June 2025: Submit LISP Mobile Node to the IESG for consideration
> > 11. November 2025: Submit Multicast documents to the IESG for
> consideration
> > 12. March 2026: Submit LISP Applicability document to the IESG for
> consideration
> > 13. November 2026: Wrap-Up or recharter
> >
> > L.
> >
> >> On Oct 13, 2023, at 19:49, Padma Pillay-Esnault 
> wrote:
> >>
> >> Additional comments/suggestions
> >>
> >> Milestones
> >> To be consistent, we should have at least a milestone for each of the
> larger sections. There is a couple missing:
> >> - TE section - suggest March 2025
> >> - Privacy and Security section - suggest Nov 2025 or March 2026
> >>
> >> Format
> >> To be consistent with other sections, we should have "Yang Model:"
> format.
> >>
> >> Ordering
> >> I would not propose to order as sections matching the milestones as
> sections may have different documents at different maturity levels.
> However this one caught my attention: should we move up "NAT transversal"
> section  to after "Yang Model:" as it is in March 2024.
> >>
> >> Thanks
> >> Padma
> >>
> >>
> >> On Fri, Oct 13, 2023 at 10:21 AM Padma Pillay-Esnault <
> padma.i...@gmail.com> wrote:
> >> Hi Luigi
> >>
> >> Looks good to me
> >> nit/suggestion below see PPE
> >>
> >> Padma
> >>
> >> On Fri, Oct 13, 2023 at 2:05 AM Luigi Iannone  wrote:
> >> Hi,
> >>
> >> I’ve tried to merge the list of work items in the charter in a single
> list and created a PR.
> >>
> >> Items have been merged and re-ordered in the following way:
> >> First the general standard track work item (multicast work merged here)
> >> Then other work with drafts more advanced appearing earlier.
> >> Milestone list will be updated once WG converged on this part.
> >>
> >> The list looks like:
> >>
> >> Main work items are identified as follows:
> >> • Standard Track Documents: The core specifications of LISP have
> been published as “Standard Track” ([RFC9300], [RFC9301]). The WG will
> continue the work of moving select specifications to “Standard Track”
> (e.g., [RFC8060], [RFC8111] and the set of multicast documents like
> [RFC6831] and [RFC8378]).
> >>
> >> PPE - Reading this the "standard track document" bullet kinda implies
> that the docs below are not standard track.
> >> Suggestion - "Moving to Standard tracks:"
> >>
> >>
> >> • YANG models for managing the LISP protocol and deployments that
> include data models, OAM, as well as allowing for pr

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

Additional comments/suggestions

Milestones
To be consistent, we should have at least a milestone for each of the
larger sections. There is a couple missing:
- TE section - suggest March 2025
- Privacy and Security section - suggest Nov 2025 or March 2026

Format
To be consistent with other sections, we should have "Yang Model:" format.

Ordering
I would not propose to order as sections matching the milestones as
sections may have different documents at different maturity levels.
However this one caught my attention: should we move up "NAT transversal"
section  to after "Yang Model:" as it is in March 2024.

Thanks
Padma


On Fri, Oct 13, 2023 at 10:21 AM Padma Pillay-Esnault 
wrote:

> Hi Luigi
>
> Looks good to me
> nit/suggestion below see PPE
>
> Padma
>
> On Fri, Oct 13, 2023 at 2:05 AM Luigi Iannone  wrote:
>
>> Hi,
>>
>> I’ve tried to merge the list of work items in the charter in a single
>> list and created a PR.
>>
>>
>> Items have been merged and re-ordered in the following way:
>>
>> First the general standard track work item (multicast work merged here)
>>
>> Then other work with drafts more advanced appearing earlier.
>>
>> Milestone list will be updated once WG converged on this part.
>>
>> The list looks like:
>>
>> Main work items are identified as follows:
>>
>>-
>>
>>Standard Track Documents: The core specifications of LISP have been
>>published as “Standard Track” ([RFC9300], [RFC9301]). The WG will continue
>>the work of moving select specifications to “Standard Track” (e.g.,
>>[RFC8060], [RFC8111] and the set of multicast documents like [RFC6831] and
>>[RFC8378]).
>>
>> PPE - Reading this the "standard track document" bullet kinda implies
> that the docs below are not standard track.
> Suggestion - "Moving to Standard tracks:"
>
>
>
>>
>>-
>>
>>YANG models for managing the LISP protocol and deployments that
>>include data models, OAM, as well as allowing for programmable management
>>interfaces. These management methods should be considered for both the
>>data-plane, control plane, and mapping system components.
>>
>>
>>-
>>
>>Map Server Reliable Transport: LISP control plane messages are
>>transported over UDP, however, in some cases, the use of a reliable
>>transport protocol is a better fit, since it actually helps reduce 
>> periodic
>>signaling.
>>-
>>
>>LISP for traffic engineering: Specifics on how to do traffic
>>engineering on LISP deployments could be useful. For instance, encode in a
>>mapping not only the routing locators associated to EIDs, but also an
>>ordered set of re-encapsulating tunnel routers used to specify a path.
>>-
>>
>>LISP external connectivity: [RFC6832] defines the Proxy ETR element,
>>to be used to connect LISP sites with non-LISP sites. However, LISP
>>deployments could benefit from more advanced internetworking, for instance
>>by defining mechanism to discover such external connectivity.
>>-
>>
>>NAT-Traversal: Support for NAT-traversal solution in deployments
>>where LISP tunnel routers are separated from correspondent tunnel routers
>>by a NAT (e.g., LISP mobile node).
>>-
>>
>>Mobility: Some LISP deployment scenarios include mobile nodes (in
>>mobile environments) or Virtual Machines (VMs in data centers), hence,
>>support needs to be provided in order to achieve seamless connectivity.
>>-
>>
>>Privacy and Security: The WG will work on topics of EID anonymity,
>>VPN segmentation leveraging on the Instance ID, and traffic anonymization.
>>The reuse of existing mechanisms will be prioritized.
>>-
>>
>>LISP Applicability: In time, LISP has proved to be a very flexible
>>protocol that can be used in various use-cases not even considered during
>>its design phase. [RFC7215], while remaining a good source of information,
>>covers one single use case, which is not anymore the main LISP application
>>scenario. The LISP WG will document LISP deployments for most recent and
>>relevant use-cases so as to update [RFC7215].
>>
>>
>>
>> Does it look as an acceptable trade-off among the various comments
>> received?
>>
>> Ciao
>>
>> L.
>>
>> On Oct 11, 2023, at 14:33, Alberto Rodriguez-Natal (natal) <
>> na...@cisco.com> wrote:
>>
>> Hi all,
>&

Re: [lisp] WG work items list [WAS: Re: Proposed WG Charter on GitHub]

[Padma Pillay-Esnault]

neering and LISP: Specifics on how to do traffic engineering
> on LISP deployments could be useful, for instance some use cases…”
>
> * On the milestones section, I think LCAFbis could be done much sooner.
> Also, I agree with Dino we should have name-encoding sooner as well (this
> is partly my fault, I’m halfway on my shepherds writeup, will try to close
> on that).
>
> * Based on the discussion on San Francisco, it is not entirely clear to me
> the consensus of the WG regarding “Submitting a LISP Applicability document
> to the IESG”. Would it be possible to leave this milestone somehow more
> open?
>
>
> I’m also planning to send a PR on GitHub with some editorial comments.
>
> Thanks,
> Alberto
>
>
> *From: *Padma Pillay-Esnault 
> *Date: *Sunday, October 1, 2023 at 7:46 PM
> *To: *LISP mailing list list 
> *Cc: *lisp-cha...@ietf.org 
> *Subject: *Proposed WG Charter on GitHub
> Hello all,
>
> We have created a repository to gather input for the proposed LISP WG
> charter presented in our last meeting.
>
> A pointer to the repo below
> https://github.com/lisp-wg/wg-charter
>
> We welcome your comments and contributions.
>
> Thanks
> Padma and Luigi
>
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

Hi Prasad

Thanks for your comments

See PPE below

On Wed, Oct 11, 2023 at 9:08 AM Vengada Prasad Govindan (venggovi) <
vengg...@cisco.com> wrote:

> Hello Luigi/ Dino,
> A couple of minor comments inline with GVP1>
> >>• Multicast Support: LISP support for multicast environments has a
> growing number of use cases. Support for multicast is needed in order to
> achieve scalability. The current documents [Ref to experimental multicast
> RFCs] should be merged and published as Standard Track.
> GVP1> Is it correct to understand that the scope of the above item
> includes RFC6831 and RFC8059 (and draft-ietf-pim-jp-extensions). Kindly
> clarify. We have many working implementations based on RFC6831 and hence it
> would be very useful to get them upgraded to Standards Track.
>
> PPE - Yes it does include RFC6831and RFC 8378. There was a discussion
about mechanisms needed and useful. See here
https://datatracker.ietf.org/doc/minutes-116-lisp/ .

>
> >>• November 2024: Submit merged Multicast document to the IESG for
> >> consideration
> >
> > Note, from the previous email you referred to
> "underlay-multicast-trees". That document has changed its name to reflect
> what it really is designing, its titled draft-vdas-lisp-group-mapping-00.
>
> As for previous comments we better avoid “merged”, may be just use
> “multicast documentS”.
> GVP1> Agreed, this is another important document that we could complete.
>

PPE - ack

Thanks
Padma


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

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

Yes Sent from my iPhoneOn Oct 11, 2023, at 04:26, Alberto Rodriguez-Natal (natal)  wrote:







Padma,
 
Just to confirm, is the end goal to have a single list of items then? (that is, not divided into two groups)
 
Thanks,
Alberto
 




From: Padma Pillay-Esnault 
Date: Friday, October 6, 2023 at 4:14 AM
To: Alvaro Retana 
Cc: LISP mailing list list , lisp-cha...@ietf.org 
Subject: Re: [lisp] Proposed WG Charter on GitHub




On Tue, Oct 3, 2023 at 5:14 PM Alvaro Retana <aretana.i...@gmail.com>
 wrote:





 


(1) What’s the difference between the work items in “Part 1” and the ones in “Part 2”?





 


PPE - originally we had in part 1 work that were promised and part 2 grouping work in progress. Will fix the document and remove the "part" for clarity.









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

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

On Mon, Oct 9, 2023 at 9:09 PM Padma Pillay-Esnault 
wrote:

>
> I propose that we change the wording of  "Standard Track Documents: The
> core specifications of LISP have been published as “Standard Track”
> [references]. The WG will continue moving select specifications to
> “Standard Track”."
>
> Propose we add some language to cover incremental features, behaviors and
> specifications in this section.
>

Rather I meant  propose to add some language to cover behaviors in a
different section.

>
> Thanks
> Padma
>
>
> On Mon, Oct 9, 2023 at 3:58 PM Prakash Jain (prakjain) 
> wrote:
>
>> Hi All,
>>
>> Should we include ‘External connectivity’ (
>> https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/)
>> work too in the charter as its close to the adoption or it needs to be
>> adopted first?
>>
>> Thanks,
>>
>> Prakash
>>
>>
>>
>>
>>
>> *From: *lisp  on behalf of Alberto
>> Rodriguez-Natal (natal) 
>> *Date: *Monday, October 9, 2023 at 3:25 PM
>> *To: *Padma Pillay-Esnault , LISP mailing list
>> list 
>> *Cc: *lisp-cha...@ietf.org 
>> *Subject: *Re: [lisp] Proposed WG Charter on GitHub
>>
>> Hi all,
>>
>>
>>
>> I need to catch up with the conversation on this thread (I’ll get to that
>> soon).
>>
>>
>>
>> I wanted to send a quick note that we missed Reliable Transport on the
>> new charter, but I see that Luigi has opened a PR on that today, thanks
>> Luigi!
>>
>>
>>
>> Alberto
>>
>>
>>
>> *From: *Padma Pillay-Esnault 
>> *Date: *Sunday, October 1, 2023 at 7:46 PM
>> *To: *LISP mailing list list 
>> *Cc: *lisp-cha...@ietf.org 
>> *Subject: *Proposed WG Charter on GitHub
>>
>> Hello all,
>>
>>
>>
>> We have created a repository to gather input for the proposed LISP WG
>> charter presented in our last meeting.
>>
>>
>>
>> A pointer to the repo below
>>
>> https://github.com/lisp-wg/wg-charter
>>
>>
>>
>> We welcome your comments and contributions.
>>
>>
>>
>> Thanks
>>
>> Padma and Luigi
>>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

I propose that we change the wording of  "Standard Track Documents: The
core specifications of LISP have been published as “Standard Track”
[references]. The WG will continue moving select specifications to
“Standard Track”."

Propose we add some language to cover incremental features, behaviors and
specifications in this section.

Thanks
Padma


On Mon, Oct 9, 2023 at 3:58 PM Prakash Jain (prakjain) 
wrote:

> Hi All,
>
> Should we include ‘External connectivity’ (
> https://datatracker.ietf.org/doc/draft-jain-lisp-site-external-connectivity/)
> work too in the charter as its close to the adoption or it needs to be
> adopted first?
>
> Thanks,
>
> Prakash
>
>
>
>
>
> *From: *lisp  on behalf of Alberto Rodriguez-Natal
> (natal) 
> *Date: *Monday, October 9, 2023 at 3:25 PM
> *To: *Padma Pillay-Esnault , LISP mailing list list
> 
> *Cc: *lisp-cha...@ietf.org 
> *Subject: *Re: [lisp] Proposed WG Charter on GitHub
>
> Hi all,
>
>
>
> I need to catch up with the conversation on this thread (I’ll get to that
> soon).
>
>
>
> I wanted to send a quick note that we missed Reliable Transport on the new
> charter, but I see that Luigi has opened a PR on that today, thanks Luigi!
>
>
>
> Alberto
>
>
>
> *From: *Padma Pillay-Esnault 
> *Date: *Sunday, October 1, 2023 at 7:46 PM
> *To: *LISP mailing list list 
> *Cc: *lisp-cha...@ietf.org 
> *Subject: *Proposed WG Charter on GitHub
>
> Hello all,
>
>
>
> We have created a repository to gather input for the proposed LISP WG
> charter presented in our last meeting.
>
>
>
> A pointer to the repo below
>
> https://github.com/lisp-wg/wg-charter
>
>
>
> We welcome your comments and contributions.
>
>
>
> Thanks
>
> Padma and Luigi
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

On Mon, Oct 9, 2023 at 3:25 PM Alberto Rodriguez-Natal (natal) <
na...@cisco.com> wrote:

> Hi all,
>
>
>
> I need to catch up with the conversation on this thread (I’ll get to that
> soon).
>
>
>
> I wanted to send a quick note that we missed Reliable Transport on the new
> charter, but I see that Luigi has opened a PR on that today, thanks Luigi!
>

Ack

Thanks
Padma

>
>
> Alberto
>
>
>
> *From: *Padma Pillay-Esnault 
> *Date: *Sunday, October 1, 2023 at 7:46 PM
> *To: *LISP mailing list list 
> *Cc: *lisp-cha...@ietf.org 
> *Subject: *Proposed WG Charter on GitHub
>
> Hello all,
>
>
>
> We have created a repository to gather input for the proposed LISP WG
> charter presented in our last meeting.
>
>
>
> A pointer to the repo below
>
> https://github.com/lisp-wg/wg-charter
>
>
>
> We welcome your comments and contributions.
>
>
>
> Thanks
>
> Padma and Luigi
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

Thanks for your comments

Agree with Luigi's comments earlier
See PPE for my comments

On Mon, Oct 9, 2023 at 1:41 PM Dino Farinacci  wrote:

> > Hi Dino,
> >
> > A few comments inline
> >
> >> On Oct 7, 2023, at 00:54, Dino Farinacci  wrote:
> >>
> >> Here are my comments. The charter text comes first and is indented and
> my comments follow:
> >>
> >>> LISP Working Group Charter ProposalProposed Charter: Introduction
> >>> LISP supports a routing architecture which decouples the routing
> locators and identifiers, thus allowing for efficient
> >>
> >> "... supports an overlay routing …"
> >
> > Is it really necessary?
>
> Well I think so since we changed the solution space of LISP from "saving
> the routing tables" to a more general overlay solution.
>
> >
> >>> aggregation of the routing locator space and providing persistent
> identifiers in the identifier space. LISP requires no changes to
> end-systems or to routers that do not directly participate in the LISP
> deployment. LISP aims for an incrementally deployable protocol, so new
> features and services can be added easily and quickly to the network using
> overlays. The scope of the LISP technology is potentially applicable to
> have a large span.The LISP WG is chartered to continue work on the LISP
> protocol and produce standard-track documents.
> >>
> >> I would add some of the more explicit features that overlay routing can
> do and how LISP actually has done so and specified at a very detailed
> level. Some examples are mobility, VPNs, multicast, mix protocol family,
> all with the latest in security mechanisms.
> >
> > We are not promoting LISP here, we are listing the work items. Let’s
> keep it simple and to the point.
>
> That is okay, but you did give some basic features as you describe "how it
> works".
>
> >
> >>
> >>> Proposed Charter: Work Items Part 1
> >>>   • NAT-Traversal: Support for NAT-traversal solution in deployments
> where LISP tunnel routers are separated from correspondent tunnel routers
> by a NAT (e.g., LISP mobile node).
> >>>   • YANG models for managing the LISP protocol and deployments that
> include data models, OAM, as well as allowing for programmable management
> interfaces. These management methods should be considered for both the
> data-plane, control plane, and mapping system components.
> >>>   • Multicast Support: LISP support for multicast environments has a
> growing number of use cases. Support for multicast is needed in order to
> achieve scalability. The current documents [Ref to experimental multicast
> RFCs] should be merged and published as Standard Track.
> >>
> >> I think the smaller work items that we can knock out should be in Part
> 1 like geo-coordinates and name-encoding.
> >
> > Geo coordinates is part of the mobility bullet point.
>
> Right, that is misplaced IMO. GPS can be used for mobility but none of the
> mobility drafts that state mechanisms refer to it. Like VPNs and TE, GPS is
> its own category.
>
> PPE - I do think future drafts in mobility will probably reference it
hence its grouping here.

>
> >> And there is no mention of VPN and TE support. It needs to go in
> somewhere.
> >
> > VPN is later on. TE is indeed missing, we need to include it somewhere.
>
> Ack.
>
> >
> >>
> >>> Proposed Charter: Work Items Part 2
> >>>   • Standard Track Documents: The core specifications of LISP have
> been published as “Standard Track” [references]. The WG will continue the
> work of moving select specifications to “Standard Track”.
> >>>   • Mobility: Some LISP deployment scenarios include mobile nodes (in
> mobile environments) or Virtual Machines (VMs in data centers), hence,
> support needs to be provided in order to achieve seamless connectivity.
> >>>   • Privacy and Security: The WG will work on topics of EID anonymity,
> VPN segmentation leveraging on the Instance ID, and traffic anonymization.
> The reuse of existing mechanisms will be prioritized.
> >>
> >> I would not call VPN segmentation as security. I view it more as
> topological member grouping.
> >
> > Which is also used for security purposes.
> >>
>
> Right but goes beyond it.
>

PPE - I see security as a use case but  grouping the draft here does not
imply any restriction on its uses beyond.

>
> >>>   • LISP Applicability: In time, LISP has proved to be a very flexible
> protocol that can be used in various use-cases not even considered during
> its design phase. RFC 7215, while remaining a good source of information,
> covers one single use case, which is not anymore the main LISP application
> scenario. The LISP WG will document LISP deployments for most recent and
> relevant use-cases so as to update RFC 7215.
> >>> Proposed Charter: Tentative Milestones
> >>>   • November 2023: Submit a LISP YANG document to the IESG for
> consideration
> >>>   • March 2024: Submit a LISP NAT Traversal document to the IESG for
> consideration
> >>>   • June 2024: Submit 8111bis to the IESG for consideration
> >>>   • June 2024 : Submi

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

Noted.

Thanks
Padma

On Fri, Oct 6, 2023 at 2:11 PM Dino Farinacci  wrote:

> > PPE: It was proposed to merge the experimental RFCs RFC6831 & RFC8378.
> However, how they are used in Replication List entries is in
> https://datatracker.ietf.org/doc/draft-vda-lisp-underlay-multicast-trees/.
> It is still open if all three docs should be merged in a big document or
> preferable to have several docs. It would be great to hear feedback from
> the WG.
>
> I propose (and prefer) seperate docs since RFC6831 is really large and
> details the interaction of LISP with PIM used in the underlay. And RFC8378
> focuses solely on an unicast underlay. And of course
> draft-vda-lisp-underlay-multicast-trees allows you to have a mix of unicast
> and multicast RLOC mappings which both RFC6831 and RFC8378 use.
>
> Dino
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

Hi Alvaro

Thank you for your review and comments.

See PPE below for my responses

On Tue, Oct 3, 2023 at 5:14 PM Alvaro Retana  wrote:

> Hi!
>
> In general, I like the charter.  However, I have some questions/comments:
>
> (1) What’s the difference between the work items in “Part 1” and the ones
> in “Part 2”?
>

PPE - originally we had in part 1 work that were promised and part 2
grouping work in progress. Will fix the document and remove the "part" for
clarity.


> (2) Related.  I’m assuming that the headers “Proposed Charter…” will be
> deleted.
>

PPE - Yes. It was left as "Proposed" in this version so it is clear it is
still under review.


> (3) Multicast support. It’s not clear from the description if the work is
> just to merge the experimental RFCs or if there’s something else. ?
>
>
PPE: It was proposed to merge the experimental RFCs RFC6831 & RFC8378.
However, how they are used in Replication List entries is in
https://datatracker.ietf.org/doc/draft-vda-lisp-underlay-multicast-trees/.  It
is still open if all three docs should be merged in a big document or
preferable to have several docs. It would be great to hear feedback from
the WG.

(4) LISP Applicability.  How will "the most recent and relevant use-cases”
> be determined?  I don’t think we need to answer, but the question may come
> up later in the process.
>
>
PPE- The spirit of this statement is to document only novel use cases that
are significantly different from the original LISP use case and avoid a
multitude of small incremental use cases.  "Novel" may also be vague, open
to suggestions.

(5) Maybe reorder the work items to coincide with the order of the
> milestones.
>

PPE - Good catch, will do.

>
> (6) "LISP geo-coordinates” doesn’t map to a work item.
>

PPE -  We were planning to have this under the mobility umbrella. We can
add some text to make it more explicit.

I don’t have write access to the repo, so I’m attaching diffs with some
> editorial points.
>

PPE   - ok will go over them and merge.

Thanks
Padma


>
> Thanks!
>
> Alvaro.
>
> On October 1, 2023 at 1:46:22 PM, Padma Pillay-Esnault (
> padma.i...@gmail.com) wrote:
>
> Hello all,
>
> We have created a repository to gather input for the proposed LISP WG
> charter presented in our last meeting.
>
> A pointer to the repo below
> https://github.com/lisp-wg/wg-charter
>
> We welcome your comments and contributions.
>
> Thanks
> Padma and Luigi
> ___
> 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] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

Thanks Joel


On Sun, Oct 1, 2023 at 2:00 PM Joel Halpern  wrote:

> My thanks to the chairs.  That looks like a reasonable, achievable, and
> useful set of goals for the working group.
>
> Yours,
>
> Joel
>
> On 10/1/2023 1:46 PM, Padma Pillay-Esnault wrote:
> > Hello all,
> >
> > We have created a repository to gather input for the proposed LISP WG
> > charter presented in our last meeting.
> >
> > A pointer to the repo below
> > https://github.com/lisp-wg/wg-charter
> >
> > We welcome your comments and contributions.
> >
> > Thanks
> > Padma and Luigi
> >
> > ___
> > 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

[lisp] Proposed WG Charter on GitHub

[Padma Pillay-Esnault]

Hello all,

We have created a repository to gather input for the proposed LISP WG
charter presented in our last meeting.

A pointer to the repo below
https://github.com/lisp-wg/wg-charter

We welcome your comments and contributions.

Thanks
Padma and Luigi
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Rechartering Thread 1: Promised work item: work items currently in the charter but not finished

[Padma Pillay-Esnault]

Hi Luigi, Dino

See below PPE

Thanks
Padma

> On Mar 15, 2023, at 02:03, Luigi Iannone  wrote:
> 
> Hi Dino,
> 
>>> On 14 Mar 2023, at 20:35, Dino Farinacci  wrote:
>>> 
>>> LISP Mobility: candidate document LISP-MN but does not solve everything 
>>> should we enlarge the scope?
>> 
>> draft-ietf-lisp-eid-mobility as well. 
> 
> Right. We can have a general discussion about mobility and what kind of 
> documents we need.
> Would lisp-mn and lisp-end-mobility be sufficient? Are there any other use 
> cases? 

PPE- should we consider predictive rlocs draft as well? It covers predictive 
mobility.

>> 
>>> LISP Yang Model: We are pretty close to finish this one
>>> LISP NAT Traversal: we have a candidate document
>> 
>> And VPNs are in charter and used quite a lot in LISP deployments, so 
>> draft-ietf-lisp-vpn.
> 
> Good point.
> 
>> 
>> Alternative Mapping System Design is part of the charter and the only draft 
>> that is pending is draft-farinacci-lisp-decent but not sure this needs to be 
>> standardized.
>> 
>> And we need to decide the outcome of draft-ietf-lisp-te and control-plane 
>> security such as draft-ietf-lisp-ecdsa-auth and draft-ietf-eid-anonymity. 
>> I'm not sure they need to be standards track. 
>> 
> 
> They can still be experimental if WG is willing to publishing them. The 
> charter may include a security/privacy work item and these documents would be 
> covered.
> 
> Ciao
> 
> L.
> 
> 
> 
>> Dino
>> 
> 

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

Re: [lisp] Padma's feedback on PubSub -09 [was: Re: LISP PubSub to Proposed Standard?]

[Padma Pillay-Esnault]

Hi Alberto

Thank you for addressing my comments. See below


On Wed, Jan 18, 2023 at 11:44 PM Alberto Rodriguez-Natal (natal) <
na...@cisco.com> wrote:

> Hi Padma,
>
>
>
> Thanks again for the feedback! You’re making some good points. Please see
> below for some comments inline with [AR].
>
>
>
> *From: *lisp  on behalf of Padma Pillay-Esnault <
> padma.i...@gmail.com>
> *Date: *Thursday, January 5, 2023 at 8:29 AM
> *To: *Alberto Rodriguez-Natal (natal) 
> *Cc: *lisp@ietf.org , Sharon Barkai  40getnexar@dmarc.ietf.org>, Jordi Paillissé 
> *Subject: *Re: [lisp] LISP PubSub to Proposed Standard?
>
> Dear Alberto and authors
>
>
>
> Thank you for the good work on this doc. I fully support moving this
> document as a proposed standard,  however I have a few comments on the
> document. See PPE below
>
> 1.  Introduction
>
> <...>
>
>In general, when an ITR/RTR/PITR wants to be notified for mapping
>
>changes for a given EID-prefix, the following steps occur:
>
>
>
>(1)  The ITR/RTR/PITR sends a Map-Request for that EID-prefix.
>
>
>
>(2)  The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on
>
> the Map-Request and includes its xTR-ID and Site-ID.
>
>
>
>(3)  The Map-Request is forwarded to one of the Map-Servers that the
>
> EID-prefix is registered to.
>
>
>
>(4)  The Map-Server creates subscription state for the ITR/RTR/PITR
>
> on the EID-prefix.
>
>
>
>(5)  The Map-Server sends a Map-Notify to the ITR/RTR/PITR to
>
> acknowledge the successful subscription.
>
>
>
>(6)  When there is a change in the mapping of the EID-Prefix, the
>
> Map-Server sends a Map-Notify message to each ITR/RTR/PITR in
>
> the subscription list.
>
>
>
>(7)  Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
>
> received Map-Notify.
>
>
>
>This operation is repeated for all EID-prefixes for which ITR/RTR/
>
>PITR want to be notified.  The ITR/RTR/PITR can set the N-bit for
>
>several EID-prefixes within a single Map-Request.
>
> <...>
>
> PPE -  This section relies on section 6.1 of rfc 9301 and gives as an
> example the simplest use case. The concluding paragraph also gives the
> impression that this is the only processing pub sub needs to do. Both the
> section 6.1 and here do not address all the use cases.
>
>
>
> [AR] Yes, this is just a simple case to illustrate the idea and general
> flow. The example certainly is not meant to be comprehensive. We can maybe
> add a note to mention that this the simplest example and that the details
> for this and other cases are found later in the document, what do you think?
>
>
>
> I suggest removing this from the introduction and instead clearly define
> the scope and then define all the use cases as in a real deployment
> scenario in section 3. See more about this below.
>
>
>
> [AR] I have no strong opinion about removing the simple example from the
> intro. I’m leaning towards keeping it, as there seemed to be some consensus
> around having an example (even if simple) in the intro. What others think?
>

PPE - no strong opinion about removing but we should add a note as you
suggest to clarify

>
>
> <...>
>
> 3.  Deployment Assumptions
>
>
>
>The specification described in this document makes the following
>
>deployment assumptions:
>
>
>
>(1)  A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
>
> assigned to each xTR.
>
>
>
>(2)  Map-Servers are configured in proxy-reply mode, i.e., they are
>
> solicited to generate and send Map-Reply messages for the
>
> mappings they are serving.
>
>
>
>The distribution of xTR-IDs (and Site-IDs) are out of the scope of
>
>this document.
>
> <...>
>
>
>
> PPE - The section 3 is sparse and could define use cases in this section.  In
> a real life deployment, there may be a variety of use cases such as
>
> 1. an ITR/PITR/RTR joins an existing LISP network and subscribes to
> specific existing EID prefixes updates (this is addressed in the intro)
>
> 2. an ITR/PITR/RTR  joins "early" a growing LISP network and subscribes
> to an EID prefix NOT YET present in the database ( covered by 8.4 in rfc
> 9301? - more below)
>
>
>
> [AR] In this case PubSub follows the same logic defined in 9301. As in
> 9301, “the least-specific prefix that both matches the original query and
> does not match any EID-Prefix known” is computed and a subscription created
> fo

Re: [lisp] Padma's feedback on PubSub -09 [was: Re: LISP PubSub to Proposed Standard?]

[Padma Pillay-Esnault]

see below

On Thu, Jan 5, 2023 at 4:18 AM Luigi Iannone  wrote:

>
>
> On 5 Jan 2023, at 12:16, Alberto Rodriguez-Natal (natal)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Hi Padma,
>
>
>
> Thanks a lot for your feedback! Let me spin out a new thread to better
> address your comments.
>
>
>
> We were about to submit version -10 of the document addressing (hopefully)
> all the feedback received so far (which has been significant). If it is
> fine with you, I’ll still proceed with submitting version -10 (today or
> tomorrow, likely) in its current form. Then we can discuss your latest
> feedback here and any potential changes coming from the discussion can go
> into -11, sounds good?
>
>
> Also, given that there seems to be support for moving the document to
> Standards Track, I’ll submit version -10 as Standards already, hoping this
> is fine.
>
>
> Hi Alberto,
>
> Yes, it is fine. Pad an and myself already discussed about it and we agree
> that the WG is OK to move this document to PS.
>
> Ciao
>
> L.
>
>
>
>
>
>
> Regarding your feedback below, I think you’re making some good questions.
> Let me put together some text to address your comments. I’ll get back to
> you shortly.
>
> PPE - looking forward and thanks!

Padma

>
>
> Thanks!
>
> Alberto
>
>
>
> *From: *lisp  on behalf of Padma Pillay-Esnault <
> padma.i...@gmail.com>
> *Date: *Thursday, January 5, 2023 at 8:29 AM
> *To: *Alberto Rodriguez-Natal (natal) 
> *Cc: *lisp@ietf.org , Sharon Barkai  40getnexar@dmarc.ietf.org>, Jordi Paillissé 
> *Subject: *Re: [lisp] LISP PubSub to Proposed Standard?
>
> Dear Alberto and authors
>
>
>
> Thank you for the good work on this doc. I fully support moving this
> document as a proposed standard,  however I have a few comments on the
> document. See PPE below
>
> 1.  Introduction
>
> <...>
>
>In general, when an ITR/RTR/PITR wants to be notified for mapping
>
>changes for a given EID-prefix, the following steps occur:
>
>
>
>(1)  The ITR/RTR/PITR sends a Map-Request for that EID-prefix.
>
>
>
>(2)  The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on
>
> the Map-Request and includes its xTR-ID and Site-ID.
>
>
>
>(3)  The Map-Request is forwarded to one of the Map-Servers that the
>
> EID-prefix is registered to.
>
>
>
>(4)  The Map-Server creates subscription state for the ITR/RTR/PITR
>
> on the EID-prefix.
>
>
>
>(5)  The Map-Server sends a Map-Notify to the ITR/RTR/PITR to
>
> acknowledge the successful subscription.
>
>
>
>(6)  When there is a change in the mapping of the EID-Prefix, the
>
> Map-Server sends a Map-Notify message to each ITR/RTR/PITR in
>
> the subscription list.
>
>
>
>(7)  Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
>
> received Map-Notify.
>
>
>
>This operation is repeated for all EID-prefixes for which ITR/RTR/
>
>PITR want to be notified.  The ITR/RTR/PITR can set the N-bit for
>
>several EID-prefixes within a single Map-Request.
>
> <...>
>
> PPE -  This section relies on section 6.1 of rfc 9301 and gives as an
> example the simplest use case. The concluding paragraph also gives the
> impression that this is the only processing pub sub needs to do. Both the
> section 6.1 and here do not address all the use cases.
>
>
>
> I suggest removing this from the introduction and instead clearly define
> the scope and then define all the use cases as in a real deployment
> scenario in section 3. See more about this below.
>
>
>
> <...>
>
> 3.  Deployment Assumptions
>
>
>
>The specification described in this document makes the following
>
>deployment assumptions:
>
>
>
>(1)  A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
>
> assigned to each xTR.
>
>
>
>(2)  Map-Servers are configured in proxy-reply mode, i.e., they are
>
> solicited to generate and send Map-Reply messages for the
>
> mappings they are serving.
>
>
>
>The distribution of xTR-IDs (and Site-IDs) are out of the scope of
>
>this document.
>
> <...>
>
>
>
> PPE - The section 3 is sparse and could define use cases in this section.  In
> a real life deployment, there may be a variety of use cases such as
>
> 1. an ITR/PITR/RTR joins an existing LISP network and subscribes to
> specific existing EID prefixes updates (this is addressed in the intro)
>
> 2. an ITR

Re: [lisp] LISP PubSub to Proposed Standard?

[Padma Pillay-Esnault]

Dear Alberto and authors

Thank you for the good work on this doc. I fully support moving this
document as a proposed standard,  however I have a few comments on the
document. See PPE below

1.  Introduction

<...>

   In general, when an ITR/RTR/PITR wants to be notified for mapping
   changes for a given EID-prefix, the following steps occur:

   (1)  The ITR/RTR/PITR sends a Map-Request for that EID-prefix.

   (2)  The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on
the Map-Request and includes its xTR-ID and Site-ID.

   (3)  The Map-Request is forwarded to one of the Map-Servers that the
EID-prefix is registered to.

   (4)  The Map-Server creates subscription state for the ITR/RTR/PITR
on the EID-prefix.

   (5)  The Map-Server sends a Map-Notify to the ITR/RTR/PITR to
acknowledge the successful subscription.

   (6)  When there is a change in the mapping of the EID-Prefix, the
Map-Server sends a Map-Notify message to each ITR/RTR/PITR in
the subscription list.

   (7)  Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
received Map-Notify.

   This operation is repeated for all EID-prefixes for which ITR/RTR/
   PITR want to be notified.  The ITR/RTR/PITR can set the N-bit for
   several EID-prefixes within a single Map-Request.

<...>

PPE -  This section relies on section 6.1 of rfc 9301 and gives as an
example the simplest use case. The concluding paragraph also gives the
impression that this is the only processing pub sub needs to do. Both the
section 6.1 and here do not address all the use cases.

I suggest removing this from the introduction and instead clearly define
the scope and then define all the use cases as in a real deployment
scenario in section 3. See more about this below.

<...>

3.  Deployment Assumptions

   The specification described in this document makes the following
   deployment assumptions:

   (1)  A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
assigned to each xTR.

   (2)  Map-Servers are configured in proxy-reply mode, i.e., they are
solicited to generate and send Map-Reply messages for the
mappings they are serving.

   The distribution of xTR-IDs (and Site-IDs) are out of the scope of
   this document.

<...>

PPE - The section 3 is sparse and could define use cases in this section.  In
a real life deployment, there may be a variety of use cases such as
1. an ITR/PITR/RTR joins an existing LISP network and subscribes to
specific existing EID prefixes updates (this is addressed in the intro)
2. an ITR/PITR/RTR  joins "early" a growing LISP network and subscribes to
an EID prefix NOT YET present in the database ( covered by 8.4 in rfc 9301?
- more below)
3. an ITR/PITR/RTR sends multiple requests where the range of prefix/len is
removed and readded are slightly different or overlapping, how do we
cover the use case of "holes"?
4. scale - what if we have a large number of subscriptions - do we intend
them to be aggregated or rely on 5.5 in rfc 9301?

The document would be much clearer if the processing expected for each of
these use cases were described explicitly.

Consider, the pub sub mechanism is used to minimize the number of messages
exchanged and timing issues by using a triggered event solution. However,
it is unclear how it works for use case 2  when there is no existing EID
entry yet.  Upon receiving a negative map reply should there be periodic
resend of SMR from the RTR/ITR/PITR? Or is the first SMR stored somewhere
on the Mapping System on a temporary entry and when the EID is added later
does it trigger the response? If the entry is temporary must the SMR
requestors renew their request- if so what periodicity? Can the two
behaviors coexist?

If there is periodic resend until the EID entry is present then the pub sub
is still polling for an event rather than being event driven for the first
part of the process then the MS and requestors should have a configuration
that accounts for the polling or timing out of an entry.

As different implementations may have specific behaviors (e.g retry when it
receives a negative map reply or assumption a subscription is
preprovisioned) there is an implicit assumption both endpoints are acting
in a cooperative manner.  Perhaps there is another deployment
assumption that the mapping system and the RTR/ITR/PITR have a
collaborative behavior (periodicity, polling mechanism, event trigger) by
config or default config.

Thanks
Padma




On Fri, Dec 9, 2022 at 3:48 AM Jordi Paillissé 
wrote:

> +1
>
> Jordi
>
> El 8/12/22 a les 22:18, Prakash Jain (prakjain) ha escrit:
> > +1
> > - Prakash
> >
> > On 12/8/22, 8:09 AM, "lisp on behalf of Sharon Barkai" <
> lisp-boun...@ietf.org on behalf of sharon.barkai=
> 40getnexar@dmarc.ietf.org> wrote:
> >
> >  ++
> >
> >  --szb
> >  Cell: +972.53.2470068
> >  WhatsApp: +1.650.492.0794
> >
> >  > On Dec 8, 2022, at 18:02, Dino Farinacci 
> wrote:
> >

Re: [lisp] LISP Specifications Published!! :-)

[Padma Pillay-Esnault]

Congratulations to Everyone!
It was indeed a long process and thanks to everyone involved.

Cheers
Padma

> On Oct 23, 2022, at 07:45, Dino Farinacci  wrote:
> 
> A special thanks to you Albert. You were the backbone of this long standing 
> publication process. 
> 
> Dino
> 
>> On Oct 23, 2022, at 2:49 AM, Albert Cabellos  
>> wrote:
>> 
>> Congrats to everyone involved! And also thanks for the final push that made 
>> this possible
>> 
>> Albert
>> 
 On 22 Oct 2022, at 10:56, Luigi Iannone  wrote:
>>> 
>>> A nice team work :-)
>>> 
>>> Congrats all.
>>> 
>>> L.
>>> 
> On 21 Oct 2022, at 06:59, Dino Farinacci  wrote:
 
 
> 
> Now it’s time to pull the Prosecco!
 
 Make it a DOC!
 
 Dino
 
 ___
 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

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

Re: [lisp] Call for Adoption: draft-farinacci-lisp-name-encoding-15.txt

[Padma Pillay-Esnault]

Support as a wg member

It is a useful specification for a number of use cases such as predictive
rlocs.

Padma

On Fri, Aug 5, 2022 at 8:23 AM Luigi Iannone  wrote:

> Hi All,
>
> The authors of the lisp-name-encoding draft (see below) have requested
> working group adoption for this document.
>
> This email starts a three weeks call for working group adoption of this
> document.
>
> Please respond, positively or negatively.  Silence does NOT mean consent.
> Please include explanation / motivation / reasoning for your view.
>
> Thank you,
>
> Luigi & Joel
>
> On 24 Jul 2022, at 17:17, Dino Farinacci  wrote:
>
> We have made changes to -15 to address Joel's comments. Thanks to Marc and
> Joel for their participation and cooperation.
>
> I would like to, at this time, request for this draft to be a working
> group document. I will present the status and changes to -15 at the LISP WG.
>
> Cheers,
> Dino
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **[lisp] I-D Action: draft-farinacci-lisp-name-encoding-15.txt*
> *Date: *July 24, 2022 at 8:15:25 AM PDT
> *To: *
> *Cc: *lisp@ietf.org
> *Reply-To: *lisp@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Locator/ID Separation Protocol WG of the
> IETF.
>
>Title   : LISP Distinguished Name Encoding
>Author  : Dino Farinacci
>  Filename: draft-farinacci-lisp-name-encoding-15.txt
>  Pages   : 9
>  Date: 2022-07-24
>
> Abstract:
>   This draft defines how to use the AFI=17 Distinguished Names in LISP.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-farinacci-lisp-name-encoding-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-farinacci-lisp-name-encoding-15
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> 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
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] New lisp WG Co-Chair

[Padma Pillay-Esnault]

Thanks Deborah and all who pinged me for your welcome and kind words.

Joel has been instrumental to this group and I will have very big shoes to
fill. I would like to thank Joel for his imparting some of his wisdom with
me. I am looking forward to working with Luigi and all of you.

-Padma

On Thu, Aug 18, 2022 at 6:52 AM BRUNGARD, DEBORAH A  wrote:

> +1 on Dino's sincere words - Joel and Luigi were instrumental in guiding
> LISP to where it is today as a standards track working group!
> All the best Joel!
> Welcome Padma!
>
> Deborah
>
>
> -Original Message-
> From: lisp  On Behalf Of Dino Farinacci
> Sent: Wednesday, August 17, 2022 5:57 PM
> To: Alvaro Retana 
> Cc: lisp@ietf.org list 
> Subject: Re: [lisp] New lisp WG Co-Chair
>
> I'd like to say a few words about Joel.
>
> Not only did he run this WG for quite a long time, he was also involved in
> the Routing Research Group (as was Luigi) and started a lot of the seed
> ideas for LISP. I have worked with Joel for many decades and his ability to
> spot architecture bugs and issues is unique and makes him one of a kind.
> His expertise will be missed but I gather he will still be involved
> technically.
>
> I want to say, on behalf of the original LISP authors, a huge thank you
> Joel for your huge contributions. I think the protocol and its deployments
> are better off because of your consultation and effort.
>
> Appreciative,
> Dino
>
> > On Aug 17, 2022, at 2:42 PM, Alvaro Retana 
> wrote:
> >
> > Dear lisp WG:
> >
> > Joel has decided to step down as lisp Co-Chair.   For the last 12+
> > years, he has been instrumental in the focus of the WG, including
> > bringing the updated Standards Track specifications to publication
> > (which we expect anytime!).  Joel: thank you for all the time and
> > effort you have put into the WG; we all look forward to your continued
> > contributions to the IETF!
> >
> > In consultation with Luigi and the other ADs, we have asked Padma
> > Pillay-Esnault to take on the role of lisp Co-Chair.  As you know,
> > Padma has served as the WG's Secretary since 2017.  In addition, she
> > has been an active IETF contributor for many years.  Welcome Padma!
> >
> > This change is effective immediately.
> >
> > Thanks!
> >
> > Alvaro.
> >
> > ___
> > lisp mailing list
> > lisp@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lisp__;!!BhdT!m6eMzIsJkPrQVPhjYY_YWdzYl48H-J5Wn5uKluz1b-_3oCSWw97UPuyDvES-5IHLRukeIwPCd6AyjNXT$
>
>
> ___
> lisp mailing list
> lisp@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lisp__;!!BhdT!m6eMzIsJkPrQVPhjYY_YWdzYl48H-J5Wn5uKluz1b-_3oCSWw97UPuyDvES-5IHLRukeIwPCd6AyjNXT$
>
>
> ___
> 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] IETF 106 LISP Working Group Minutes

[Padma Pillay-Esnault]

The IETF 106 LISP Working Group Minutes are available at
https://datatracker.ietf.org/meeting/106/materials/minutes-106-lisp-00

Please email me if you have any corrections, clarifications or comments.

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

Re: [lisp] The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state "Call For Adoption By WG Issued"

[Padma Pillay-Esnault]

Support the adoption

Thanks
Padma

On Wed, Apr 4, 2018 at 3:14 AM, IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> The LISP WG has placed draft-rodrigueznatal-lisp-pubsub in state
> Call For Adoption By WG Issued (entered by Joel Halpern)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-rodrigueznatal-lisp-pubsub/
>
> Comment:
> As requested by the authors, calling for WG adoption.
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Confirm/Deny changes on draft 6830bis

[Padma Pillay-Esnault]

Hi Albert

Please find below my comments PPE

On Fri, Jan 12, 2018 at 5:20 PM, Albert Cabellos 
wrote:

> Hi all
>
> As editor of 6830bis I´d like to confirm or deny the following changes
> which I believe have support.
>
> Please note that I have intentionally ignored minor/editorial changes to
> help sync all the participants. I hope that the list below captures the
> most relevant ones.
>
> Also note that I don´t necessarily agree with all the changes listed
> below, but that´s an opinion with a different hat.
>
> WG: Please CONFIRM or DENY:
>
> ---
>
> A.- Remove definitions of PA and PI
>

 Confirm

>
> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and
> ‘identifier of the underlay’ respectively.
>

 Deny - Agree with some others on the list that this does not add much
for clarification.


>
> C.- In section 5.3, change the description of the encap/decap operation
> concerning how to deal with ECN and DSCP bits to (new text needs to be
> validated by experts):
>
> When doing ITR/PITR encapsulation:
>
> o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the
> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
>
> o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or
> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
> inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
> considering the exception listed below.
>
> o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
> IPv6 'Traffic Class' field) requires special treatment in order to avoid
> discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy
> the 2-bit 'ECN' field from the inner header to the outer header.
> Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer
> header to the new outer header.
>
> When doing ETR/PETR decapsulation:
>
>  o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the
> case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field,
> when the Time to Live value of the outer header is less than the Time to
> Live value of the inner header.  Failing to perform this check can cause
> the Time to Live of the inner header to increment across
> encapsulation/decapsulation cycles.  This check is also performed when
> doing initial encapsulation, when a packet comes to an ITR or PITR destined
> for a LISP site.
>
> o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or
> the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
> outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
> considering the exception listed below.
>
> o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
> IPv6 'Traffic Class' field) requires special treatment in order to avoid
> discarding indications of congestion [RFC3168]. If the 'ECN' field contains
> a congestion indication codepoint (the value is '11', the Congestion
> Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit
> 'ECN' field from the stripped outer header to the surviving inner header
> that is used to forward the packet beyond the ETR.  These requirements
> preserve CE indications when a packet that uses ECN traverses a LISP tunnel
> and becomes marked with a CE indication due to congestion between the
> tunnel endpoints.
>
> Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate
> after decapsulating, the net effect of this is that the new outer header
> will carry the same Time to Live as the old outer header minus 1.
>
> Copying the Time to Live (TTL) serves two purposes: first, it preserves
> the distance the host intended the packet to travel; second, and more
> importantly, it provides for suppression of looping packets in the event
> there is a loop of concatenated tunnels due to misconfiguration.  See
> Section 18.3 for TTL exception handling for traceroute packets.
>
>
>   Abstain for now


> D.- Simplify section ‘Router Locator Selection’ stating that the
> data-plane MUST follow what´s stored in the map-cache (priorities and
> weights), the remaining text should go to an OAM document.
>
>  Confirm


> E.- Rewrite Section “Routing Locator Reachability” considering the
> following changes:
>
> *Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and
> Echo-Nonce
> *Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3
> (hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a
> response) and RLOC probing
>
>
>  Confirm see some of my comments on this on the thread.


> F.- Move Solicit-Map-Request to 6833bis
>
>  Confirm


> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
> Considerations), 18 (Traceroute Consideration) to a new OAM document
>
>
>
 Confirm


Thanks
Padma

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

Re: [lisp] Confirm/Deny changes on draft 6830bis

[Padma Pillay-Esnault]

Dear Dino and Albert

The doc reads well.
Please find thereafter some comments on the version- 09 you posted on the
list

Page 4
*"Client-side:  Client-side is a term used in this document to indicate a
connection initiation attempt by an EID."*

PPE 1: Strictly speaking the EID is just an identifier and does not
initiate anything. Suggest something like this.

*"Client-side:  Client-side is a term used in this document to indicate a
connection initiation attempt by the end system (represented by an EID)"*


Page 6
*The source EID is obtained via existing mechanisms used to set a host's
"local" IP address.  An EID used on the public Internet must have the same
properties as any other IP address used in that manner; this means, among
other things, that it must be globally unique.*

PPE 2: Shouldn't these two be MUST rather than must? Suggestion below
*The source EID is obtained via existing mechanisms used to set a host's
"local" IP address.  An EID used on the public Internet MUST have the same
properties as any other IP address used in that manner; this means, among
other things, that it MUST be globally unique.*

Page 8
*An EID maps to one or more RLOCs.*

PPE 3: Seems to contradict earlier explanation on negative mapping entry
where it is possible that an EID has NO RLOC.

*Page 8 *
*When using multiple mapping database systems, care must be taken to not
create re-encapsulation loops through misconfiguration.*

PPE 4: Suggest to add "re-encapsulation" in the list in Security
Considerations section as this is an exploit possibility.


Page 13
*"gleaned" mapping*

PPE 5: Suggest adding “glean mapping” in the definition section.

Page 17
*"The KK-bits are a 2-bit field used when encapsualted packets
are encrypted."*

PPE 6: Nit - Typo "*encapsualted" -> "**encapsulated"*

Page 20
*"When the lookup succeeds, the locator-set  retrieved from the map-cache
is used to send the packet to the EID's topological location."*

PPE 7: Nit - Suggest capitalize L and S of "locator-set" for consistency
with rest of document.

Page 23
"*The server-side sets a Weight of 0..."*

PPE 8: Nit - For consistency in text change to "Weight of zero".
Page 23
"*Control is shared by the server- side determining the list and the client
determining load  distribution." *

PPE 9: Suggest use of "Client-side"

*"Control is shared by the server- side determining the list and the
client-side determining load distribution."*

Page 24
*When a verified Map-Cache entry is stored, data gleaning no longer occurs
for subsequent packets that have a source EID that matches*
*the EID-Prefix of the verified entry.[PE1]   This "gleaning" mechanism is
OPTIONAL.*

PPE 10: In section 16.2 later gleaning is used as a solution.  Changes in
the gleaned info could be an interesting way to update the cache fast
…however this text make it sound that this is not an option after first
packet.

Page 25
"Note that trusting ICMP messages may  not be desirable, but neither is
ignoring them completely. Implementations are encouraged to follow current
best practices in treating these conditions."

PPE 11: A reference would be useful if possible.

Page 25

*"An ITR that participates in the global routing system can determine that
an RLOC is down if no BGP Routing Information Base (RIB) route exists that
matches the RLOC IP address."*

PPE 12: Isn't this true for any protocol entry not just a BGP entry? We are
really trying to determine if there is no route whatever the protocol.

Page 38
*"For a more detailed networkd design deployment recommendation, refer to
[RFC7215]."*

PPE 13: Nit typo "netword"-> "network"
Page 40
*"By having the PE be the first router on the path to encapsulate, it can
choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for
a new encapsuluation path to the destination end site."*

PPE 14: Nit Typo "*encapsuluation" -> "encapsulation"*

Page 43
"*If the attacker spoofs the source RLOC, it can mount a DoS attack by
redirecting traffic to the spoofed victim;s RLOC, potentially overloading
it."*

PPE 15: Nit  typo "*victim;s" -> "**victim's"*

Thanks
Padma

On Mon, Jan 15, 2018 at 6:57 PM, Dino Farinacci  wrote:

> > Should I review 09 or 08?
>
> It would be better to do -09. If I had known comments were coming from you
> I would have waited to put in Albert’s text. What I did in -09 is simply
> cut-and-paste his text.
>
> > But please once you reply to this mail than you stick to the decision
> until I review the document.
>
> I won’t make any other changes until I see your comments.
>
> Dino
>
> >
> > L.
> >
> >
> >> On 13 Jan 2018, at 19:30, Dino Farinacci  wrote:
> >>
> >> Here is a -09 proposal to add your requested change C below. All the
> other points are still open for discussion.
> >>
> >> Dino
> >>
> >> 
> >>
> >> 
> >>
> >>> On Jan 12, 2018, at 8:20 AM, Albert Cabellos <
> albert.cabel...@gmail.com> wrote:
> >>>
> >>> Hi all
> >>>
> >>> As editor of 6830bis I´d like to confirm or deny the following changes
> which I be

Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

[Padma Pillay-Esnault]

On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema 
wrote:

> On 10/11/2017 7:56 AM, Robert Moskowitz wrote:
>
> and 'identity' is a red flag.
>
>
> Whow there!  You were part of the Namespace Research Group?  I think?  I
> was and we we worked a lot on this and came to the conclusion that there
> could be no conclusion.  Not even a rough concensus, it seemed.
>
> I have been using 'identity' to apply to things for 20 years. Pretty much
> ever since I started working with things.  Anyone that holds the position
> that 'identity' means we are talking only about people are allowing their
> thinking to be clouded.
>
>
> I am concerned that the current proponents of the IDEAS work are mainly
> resisting the feedback, treating it as some roadblock put in the path of
> their work by misguided privacy purists, and attempting to remove the
> roadblocks by adding some weasel words to the charter. I would feel much
> more confident if these proponents acknowledged the tension between privacy
> and stable identifiers of any sort, if that tension was clearly noted in
> the charter, and if privacy goals were clearly stated.
>
>
As one of the proponents, I feel I need to speak up because blanket
statements are just not helping.

Speaking on behalf of my fellow proponents, we have always welcomed
constructive feedback from people who want/can contribute and make the
technology better. We have been willing to clarify the charter
(clarification does not mean weaseling).

If it is helpful to  move forward, I am willing to volunteer for this work
and discuss with anyone to ensure constructive feedback and comments are
addressed.


Specifically, I think there is a contradiction between some of documents.
> For example, draft-padma-ideas-problem-statement-01 states that:
>
>o  A single entity may have multiple IDs, and IDs of the same entity
>   may have different life spans that are different from the lifespan
>   of the entity.  Furthermore, it is understood that IDs may have
>   different lifecycles, which may be permanent or ephemeral by
>   choice or design.
>
>o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
>   for a permanent ID to protect the privacy of the related entity.
>
> But then, draft-ccm-ideas-identity-use-cases-01 states that:
>
>a.  Unique and Permanent Identity representing the entity enables
>authentication (AUTH) with the mapping and Identity services
>infrastructure.  While it is possible to do AUTH on Identifiers
>those are not permanently associated to the entity.  Moreover,
>AUTH operation is a relatively an expensive and inefficient
>procedure (compared to LOC resolution for example) and can cause
>excessive startup delays for lot of applications.
>
>
>
As said earlier this draft was not updated by the authors and a new version
was posted yesterday.

https://www.ietf.org/mail-archive/web/ideas/current/msg00520.html



> The tension is obvious. On one hand, the ephemeral identifiers envisaged
> in the problem statement would pretty much align the privacy properties of
> the ID to those of IPv6 privacy addresses, and that's good. On the other
> hand, the requirement to perform authentication on identities completely
> negates that property.
>
> I would be fine if the support for "Unique and Permanent Identity" was
> explicitly excluded from the charter.
>

AFAIK, none of the proponents resisted that.


> There is obviously a need to support some form of access control to a
> mapping database,
>

Agreed.


> but you do not need a reference to a permanent identity for that --
> systems similar to CGA would work just fine.
>


The identity of the device is just adding a lever of identifier which
effectively allows authentication to modify the identifiers used by that
device but also what the users of these identifiers can look up. If we had
used "user of identifier" it would have been misconstrued for humans. So
damn if you do and damn if you don't ...

We are open for discussions anytime.

Padma



>
> --
> Christian Huitema
>
>
> ___
> 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] [ERRATA] Call for WG Adoption of Vendor Specific LCAF [draft-rodrigueznatal-lisp-vendor-lcaf-00.txt]

[Padma Pillay-Esnault]

Support

On Wed, Jul 26, 2017 at 5:19 AM, Reshad Rahman (rrahman) 
wrote:

> I support WG adoption of draft-rodrigueznatal-lisp-vendor-lcaf.
>
> From: lisp mailto:lisp-boun...@ietf.org>> on
> behalf of Luigi Iannone mailto:g...@gigix.net>>
> Date: Wednesday, July 26, 2017 at 7:16 AM
> To: LISP mailing list list mailto:lisp@ietf.org>>
> Cc: "lisp-cha...@ietf.org" <
> lisp-cha...@ietf.org>
> Subject: [lisp] [ERRATA] Call for WG Adoption of Vendor Specific LCAF
> [draft-rodrigueznatal-lisp-vendor-lcaf-00.txt]
>
> The call ends August 10th 2017 !
>
> Luigi
>
> On 26 Jul 2017, at 11:41, Luigi Iannone mailto:ggx@
> gigix.net>> wrote:
>
> Hi All,
>
> During the 99th IETF authors of the document draft-rodrigueznatal-lisp-
> vendor-lcaf-00.txt
> [https://tools.ietf.org/html/draft-rodrigueznatal-lisp-vendor-lcaf-00]
> asked for WG adoption. Meeting participants expressed consensus on adoption
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of LISP Anonymity [draft-farinacci-lisp-eid-anonymity-02.txt]

[Padma Pillay-Esnault]

Support as co-author



On Wed, Jul 26, 2017 at 2:41 AM, Luigi Iannone  wrote:

> Hi All,
>
> During the 99th IETF authors of the document draft-farinacci-lisp-
> eid-anonymity-02.txt
> [https://tools.ietf.org/html/draft-farinacci-lisp-eid-anonymity-02]
> asked for WG adoption. Meeting participants expressed consensus on
> adoption.
>
> This message begins the two weeks call for WG adoption to confirm the
> meeting outcome.
> The call ends on  August 3rd 2017.
>
> Please respond to the LISP mailing list with any statements of approval or
> disapproval.
>
> Recall that:
>
> - This is not WG Last Call. The document is not final, and the WG is
> expected to
>   modify the document’s content until there is WG consensus that the
> content is solid.
>   Therefore, please don’t oppose adoption just because you want to see
> changes to its content.
>
> - If you have objections to adoption of the document, please state your
> reasons why,
>   and explain what it would take to address your concerns.
>
> - If you have issues with the content, by all means raise those issues and
> we can
>   begin a dialog about how best to address them.
>
>
>
> Luigi and Joel
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-farinacci-lisp-predictive-rlocs-02.txt

[Padma Pillay-Esnault]

Support

Padma

On Fri, May 19, 2017 at 2:06 AM, Luigi Iannone  wrote:

> Hi All,
>
> Authors of the document draft-farinacci-lisp-predictive-rlocs-02.txt
> [https://datatracker.ietf.org/doc/draft-farinacci-lisp-predictive-rlocs/]
> asked for WG adoption.
>
> This message begins the two weeks call for WG adoption.
> The call ends on  June 2nd 2017.
>
> Please respond to the LISP mailing list with any statements of approval or
> disapproval.
>
> Recall that:
>
> - This is not WG Last Call. The document is not final, and the WG is
> expected to
>   modify the document’s content until there is WG consensus that the
> content is solid.
>   Therefore, please don’t oppose adoption just because you want to see
> changes to its content.
>
> - If you have objections to adoption of the document, please state your
> reasons why,
>   and explain what it would take to address your concerns.
>
> - If you have issues with the content, by all means raise those issues and
> we can
>   begin a dialog about how best to address them.
>
>
>
> Luigi and Joel
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-farinacci-lisp-te-12.txt

[Padma Pillay-Esnault]

Support

Padma

On Wed, Apr 12, 2017 at 2:30 AM, Luigi Iannone  wrote:

> Hi All,
>
> During the 98th IETF authors of the document draft-farinacci-lisp-te-12.
> txt
> [https://tools.ietf.org/html/draft-farinacci-lisp-te-12]
> asked for WG adoption. Meeting participants expressed consensus on
> adoption.
>
> This message begins the two weeks call for WG adoption to confirm the
> meeting outcome.
> The call ends on  April 27th 2017.
>
> Please respond to the LISP mailing list with any statements of approval or
> disapproval.
>
> Recall that:
>
> - This is not WG Last Call. The document is not final, and the WG is
> expected to
>   modify the document’s content until there is WG consensus that the
> content is solid.
>   Therefore, please don’t oppose adoption just because you want to see
> changes to its content.
>
> - If you have objections to adoption of the document, please state your
> reasons why,
>   and explain what it would take to address your concerns.
>
> - If you have issues with the content, by all means raise those issues and
> we can
>   begin a dialog about how best to address them.
>
>
>
> Luigi and 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] Call for WG Adoption of document draft-portoles-lisp-eid-mobility-02.txt

[Padma Pillay-Esnault]

Support

Padma

On Wed, Apr 12, 2017 at 2:28 AM, Luigi Iannone  wrote:

> Hi All,
>
> During the 98th IETF authors of the document draft-portoles-lisp-
> eid-mobility-02.txt
> [https://tools.ietf.org/html/draft-portoles-lisp-eid-mobility-02]
> asked for WG adoption. Meeting participants expressed consensus on
> adoption.
>
> This message begins the two weeks call for WG adoption to confirm the
> meeting outcome.
> The call ends on  April 27th 2017.
>
> Please respond to the LISP mailing list with any statements of approval or
> disapproval.
>
> Recall that:
>
> - This is not WG Last Call. The document is not final, and the WG is
> expected to
>   modify the document’s content until there is WG consensus that the
> content is solid.
>   Therefore, please don’t oppose adoption just because you want to see
> changes to its content.
>
> - If you have objections to adoption of the document, please state your
> reasons why,
>   and explain what it would take to address your concerns.
>
> - If you have issues with the content, by all means raise those issues and
> we can
>   begin a dialog about how best to address them.
>
>
>
> Luigi and Joel
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-meyer-lisp-mn-16.txt

[Padma Pillay-Esnault]

Support

Padma

On Wed, Apr 12, 2017 at 2:30 AM, Luigi Iannone  wrote:

> Hi All,
>
> During the 98th IETF authors of the document draft-meter-lisp-mn-16.txt
> [https://tools.ietf.org/html/draft-meyer-lisp-mn-16]
> asked for WG adoption. Meeting participants expressed consensus on
> adoption.
>
> This message begins the two weeks call for WG adoption to confirm the
> meeting outcome.
> The call ends on  April 27th 2017.
>
> Please respond to the LISP mailing list with any statements of approval or
> disapproval.
>
> Recall that:
>
> - This is not WG Last Call. The document is not final, and the WG is
> expected to
>   modify the document’s content until there is WG consensus that the
> content is solid.
>   Therefore, please don’t oppose adoption just because you want to see
> changes to its content.
>
> - If you have objections to adoption of the document, please state your
> reasons why,
>   and explain what it would take to address your concerns.
>
> - If you have issues with the content, by all means raise those issues and
> we can
>   begin a dialog about how best to address them.
>
>
>
> Luigi and Joel
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Call for WG Adoption of document draft-moreno-lisp-vpn-00.txt

[Padma Pillay-Esnault]

Support

Padma

On Wed, Apr 12, 2017 at 2:29 AM, Luigi Iannone  wrote:

> Hi All,
>
> During the 98th IETF authors of the document draft-moreno-lisp-vpn-00.txt
> [https://tools.ietf.org/html/draft-moreno-lisp-vpn-00]
> asked for WG adoption. Meeting participants expressed consensus on
> adoption.
>
> This message begins the two weeks call for WG adoption to confirm the
> meeting outcome.
> The call ends on  April 27th 2017.
>
> Please respond to the LISP mailing list with any statements of approval or
> disapproval.
>
> Recall that:
>
> - This is not WG Last Call. The document is not final, and the WG is
> expected to
>   modify the document’s content until there is WG consensus that the
> content is solid.
>   Therefore, please don’t oppose adoption just because you want to see
> changes to its content.
>
> - If you have objections to adoption of the document, please state your
> reasons why,
>   and explain what it would take to address your concerns.
>
> - If you have issues with the content, by all means raise those issues and
> we can
>   begin a dialog about how best to address them.
>
>
>
> Luigi and Joel
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] IDEAS Meeting in IETF98

[Padma Pillay-Esnault]

Hello Everyone

Unfortunately, we will not be providing pizza or lunch for the meeting.
Please bring your own lunch.

See you there!
Padma

On Mon, Mar 20, 2017 at 2:22 PM, Padma Pillay-Esnault 
wrote:

> Hello Everyone,
>
> We are holding an IDEAS meeting for IETF98.
>
> Date: Tuesday, 28th March 2017
> Time : 11:40am - 12:50pm
> Venue: Vevey1/2
>
> Related Areas: RTG, INT, OPS
> Sponsoring AD: Alvaro Retana
>
> Agenda
> Introduction
> Problem Statement for IDEAS  - Padma Pillay-Esnault
> https://www.ietf.org/internet-drafts/draft-padma-ideas-probl
> em-statement-01.txt
>
> Use Cases for IDEAS - Tom Herbert
> https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt
>
> Requirements for Generic Resilient Identity Services in IDEAS -  -
> Alex Clemm
> https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt
>
> A Blockchain-based Mapping System - Jordi Paillisse
>
> Mobility First and Global Name Resolution Service - Parishad Karimi
> /Shreeyasee Mukherjee
> https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt
>
> Next Steps
>
> See you all there!
> Padma
>
>
> Mailing list: IDEAS
> List address: id...@ietf.org
> Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas
> To subscribe: https://www.ietf.org/mailman/listinfo/ideas
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[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

[lisp] IDEAS Meeting in IETF98

[Padma Pillay-Esnault]

Hello Everyone,

Resending with a few corrections

We are holding an IDEAS meeting for IETF98.
Unfortunately there is no Meetecho.

Date: Tuesday, 28th March 2017
Time : 11:40am - 12:45 pm
Venue: Vevey1/2

Agenda
Introduction
Problem Statement for IDEAS  - Padma Pillay-Esnault
https://www.ietf.org/internet-drafts/draft-padma-ideas-probl
em-statement-01.txt

Use Cases for IDEAS - Tom Herbert
https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt

Requirements for Generic Resilient Identity Services in IDEAS -  -
Alex Clemm
https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt

A Blockchain-based Mapping System - Jordi Paillisse

Mobility First and Global Name Resolution Service - Parishad Karimi
/Shreeyasee Mukherjee
https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt

Next Steps

See you all there!
Padma


Mailing list: IDEAS
List address: id...@ietf.org
Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas
To subscribe: https://www.ietf.org/mailman/listinfo/ideas
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] IDEAS Meeting in IETF98

[Padma Pillay-Esnault]

Hello Everyone,

We are holding an IDEAS meeting for IETF98.

Date: Tuesday, 28th March 2017
Time : 11:40am - 12:50pm
Venue: Vevey1/2

Related Areas: RTG, INT, OPS
Sponsoring AD: Alvaro Retana

Agenda
Introduction
Problem Statement for IDEAS  - Padma Pillay-Esnault
https://www.ietf.org/internet-drafts/draft-padma-ideas-probl
em-statement-01.txt

Use Cases for IDEAS - Tom Herbert
https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt

Requirements for Generic Resilient Identity Services in IDEAS -  -
Alex Clemm
https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt

A Blockchain-based Mapping System - Jordi Paillisse

Mobility First and Global Name Resolution Service - Parishad Karimi
/Shreeyasee Mukherjee
https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt

Next Steps

See you all there!
Padma


Mailing list: IDEAS
List address: id...@ietf.org
Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas
To subscribe: https://www.ietf.org/mailman/listinfo/ideas
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Meeting in IETF98

[Padma Pillay-Esnault]

Hello Everyone,

We are holding an IDEAS meeting for IETF98 and  sending this email for a
placeholder on your calendar.

See you there
Padma

Tentative Date: Tuesday, 28th March 2017
Time : 11:30am - 12:50pm
Venue: TBD

Drafts Published
https://www.ietf.org/internet-drafts/draft-padma-ideas-probl
em-statement-01.txthttps://www.ietf.org/internet-drafts/draft-padma-
ideas-use-cases-00.txt
https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt

https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt

Mailing list: IDEAS
List address: id...@ietf.org
Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas
To subscribe: https://www.ietf.org/mailman/listinfo/ideas
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] Fwd: New Version Notification for draft-padma-ideas-use-cases-00.txt

[Padma Pillay-Esnault]

Hello Everyone

FYI there is a new draft posted describing the use cases for IDEAS.

Highlights:
- describes the uses cases per category.
- there are two companion drafts covering the problem statement and the
requirements

Comments and suggestions for improvement are welcome.

Thanks
Padma (on behalf of all contributors)



-- Forwarded message --
From: 
Date: Sun, Mar 12, 2017 at 1:55 PM
Subject: New Version Notification for draft-padma-ideas-use-cases-00.txt
To: "padma.i...@gmail.com" , Michael Menth <
me...@uni-tuebingen.de>, Tom Herbert , Dino Farinacci <
farina...@gmail.com>, Christian Jacquenet ,
David Lake , "Dipenkar Raychaudhuri (Ray)" <
r...@winlab.rutgers.edu>, David Meyer 



A new version of I-D, draft-padma-ideas-use-cases-00.txt
has been successfully submitted by Padma Pillay-Esnault and posted to the
IETF repository.

Name:   draft-padma-ideas-use-cases
Revision:   00
Title:  Use Cases for Identity Enabled Networks
Document date:  2017-03-12
Group:  Individual Submission
Pages:  24
URL:https://www.ietf.org/internet-drafts/draft-padma-ideas-use-c
ases-00.txt
Status: https://datatracker.ietf.org/doc/draft-padma-ideas-use-case
s/
Htmlized:   https://tools.ietf.org/html/draft-padma-ideas-use-cases-00


Abstract:
   This document describes some use cases for Identity Enabled networks
   using a Generic Resilient Identity Services infrastructure.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

[lisp] Fwd: New Version Notification for draft-padma-ideas-req-grids-00.txt

[Padma Pillay-Esnault]

Hello Everyone

FYI there is a new draft posted describing the Requirements for IDEAS.

Highlights:
- describes the Generic Resilient Identity Services and its functionalities
- lists the different categories of requirements.
- the two companion drafts are problem statement and the use case posted
earlier on aliases

Comments and suggestions for improvement are welcome.

Thanks
Padma (on behalf of all contributors)

-- Forwarded message --
From: 
Date: Mon, Mar 13, 2017 at 4:07 PM
Subject: New Version Notification for draft-padma-ideas-req-grids-00.txt
To: "padma.i...@gmail.com" , Dino Farinacci <
farina...@gmail.com>, Alexander Clemm , David Meyer <
d...@1-4-5.net>



A new version of I-D, draft-padma-ideas-req-grids-00.txt
has been successfully submitted by Padma Pillay-Esnault and posted to the
IETF repository.

Name:   draft-padma-ideas-req-grids
Revision:   00
Title:  Requirements for Generic Resilient Identity Services in
Identity Enabled Networks
Document date:  2017-03-13
Group:  Individual Submission
Pages:  15
URL:https://www.ietf.org/internet-drafts/draft-padma-ideas-req-g
rids-00.txt
Status: https://datatracker.ietf.org/doc/draft-padma-ideas-req-grid
s/
Htmlized:   https://tools.ietf.org/html/draft-padma-ideas-req-grids-00


Abstract:
   This document describes requirements for the Generic Resilient
   Identity Services infrastructure for Identity-Enabled Networks.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

[lisp] Fwd: New Version Notification for draft-padma-ideas-problem-statement-01.txt

[Padma Pillay-Esnault]

Hello Everyone


We updated the IDEAS problem statement draft.

The document went under significant changes per feedback after the meeting
in IETF97.

Highlights:
- streamlined to only Problem Statement.
- added brief overview on ID based networks
- clarified the key problems
- there are two companion drafts covering the use cases and the
requirements (to be posted by tomorrow)

Comments and suggestions for improvement are welcome.

Thanks
Padma (on behalf of all contributors)


A new version of I-D, draft-padma-ideas-problem-statement-01.txt
has been successfully submitted by Padma Pillay-Esnault and posted to the
IETF repository.

Name:   draft-padma-ideas-problem-statement
Revision:   01
Title:  Problem Statement for Identity Enabled Networks
Document date:  2017-03-12
Group:  Individual Submission
Pages:  15
URL:https://www.ietf.org/internet-drafts/draft-padma-ideas-probl
em-statement-01.txt
Status: https://datatracker.ietf.org/doc/draft-padma-ideas-problem-
statement/
Htmlized:   https://tools.ietf.org/html/draft-padma-ideas-problem-state
ment-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-padma-ideas-problem
-statement-01

Abstract:
   The forthcoming deployment of 5G coupled with emerging applications
   such as augmented reality, virtual reality and 8k videos are likely
   to raise more stringent requirements in terms of ultra-low latency
   while ensuring session continuity.  The emergence of IoT services
   also raises new challenges (with respect to their interoperability,
   discovery, naming and addressing) which may lead to identity-based
   designs.  This problem statement examines how the existing solutions
   for networks whose forwarding scheme assumes the decoupling between
   the identifier and the locator information (called Identity Enabled
   Networks) will struggle to meet such requirements.  It advocates for
   a standardized, secured common control plane with data integrity for
   Identity Services such as identifier registration, mapping and
   resolution.  This memo also identifies several key areas to be
   further investigated for the architecture design of these services.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

[lisp] FW: [Ideas] Minutes of IDEAS side meeting @IETF97

[Padma Pillay-Esnault]

FYI. Feel free to forward.

Looking forward to working with you all
Padma



*From:* Ideas [mailto:ideas-boun...@ietf.org] *On Behalf Of *Padma
Pillay-Esnault
*Sent:* Sunday, December 11, 2016 8:51 AM
*To:* id...@ietf.org
*Subject:* [Ideas] Minutes of IDEAS side meeting @IETF97



Hello IDEAS!



Please find below the minutes of IDEAS side meeting @IETF97.

Thanks to all of you who attended the meeting and to Les Ginsberg for
taking minutes.



Please take a look and let us know if there are any changes needed.



Looking forward to your contributions.

Padma





IDEAS Side Meeting Minutes  IETF97





1. Agenda

Padma Pillay-Esnault (Huawei) - Introduction on problem statement for IDEAS
(10 mins)

Presented the problem statement draft and the Use cases.



Robert Raszuk: Should we define what identity is?

Padma: Agree. The document take a stab at this by defining identities and
in which context. There is a table in the document that captures the
different aspects of ID usage, allocation and its impact on a dynamic
mapping system.



Sam Aldrin: What is primary focus? What problem are you really trying to
solve? Narrow the scope - or are we trying to define a problem because we
have a solution?

Padma: The primary focus is the design and deployment of a dynamic mapping
system.

The Problem statement discusses in detail the problems we are trying to
solve. Among those many problems is Session continuity in mobility which is
important as we have more and more mobile modes in cellular as well as ip
mobility(DC). Another important problem that can be solved and is discussed
in the paper is Cross-silo communication. Encourage everyone to read the
document.



Luigi: We have multiple encaps and mappings and want to manage in a common
way.

But what is a common ID? Please clarify.



Padma: In this case we are not necessarily looking for a common single ID.
What we are trying to do is to map an ID to location. So that we can have
the Identity dissociated with the locator so that mobility is fully
supported. What we are proposing is to have a common control plane that
have access to a mapping system used by all. It is not very practical to
deploy one global mapping system per protocol or application.



Luigi: Do we have to solve who is allocating the ID? Maybe we do not have
to solve this problem.

Padma: Well it depends. We have both the case for public and private IDs.
For public IDs to be used by a common control plane, we will require some
rules.

Luigi: But what form will the ID take?

Dino: Different EID types for different purposes. Hopefully they will be
used

for different purposes. Should it be geographical, first come first served,

assigned at birth,...many types allocated differently.

L2 overlays have the MAC address.

ID allocation independent of database.



~General discussion about EID types and mapping systems.



Bob Moskowitz: I am the Last member of the EID cabal. :-)

Many discussions have been already What characteristics required of an EID?
What is good/bad? Capturing that would be good. There is two decades of
experience available – would be good to make use of that.

Padma: There is a table in the draft which captures some aspects of this
discussion.

How are we actually using IDs today? And how it should be used or
restricted.

Can we use ID properties to provide better security for example?

Georgios: Take into account use cases in 5G and IoT, since they will impose
requirements that we did not have up to now.



**

Tom Herbert ( Facebook) - The ILA protocol and NMS (10 mins)

Scale to 100’s of billion aggregate mappings

No aggregation assumed, 1%change per second

Able to attach ancillary data to mapping



Bob: Is this intended to be globally unique?

Tom: Globally unique in a domain.

Bob: with 7B population w 64 bit # 74% probability of collision.

This must be accounted for. Will post the formula for calculating
likelihood of collision.

Tom: We do have a method to generate unique identifiers.

Covers 20 years of experience.

Mapping system detects conflicts at registration.

Bob: Agreed. But 10 devices/person gives high probability of collisions

Kiran: Scope of identifier determined by locator?

Tom: Identifiers unique for a domain.

Reverse translation requires locator to map back to the original prefix.

Ingress/Egress translation. Both sides have to agree on the pairing.

Kiran Makhijani: If age out of cache how can you detect?

Tom: If we lose ILA routers need to have other ILA addresses available.

An open issue

Kiran Makhijani: Need to have reliability solution base requirements
related to NMS





Dino Farinacci ( Lispers) - LISP Mapping system, How it works? (10 mins)

Presented LISP Site to access of mapping System, Site Registration

10 years of experience and DDT mapping server.

Hierarchical network structure based on EID Allocation

3 levels of hierarchy to

Re: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis

[Padma Pillay-Esnault]

Support adoption and willing to review

Regards
Padma

On Thu, Nov 17, 2016 at 8:45 AM, Reshad Rahman (rrahman) 
wrote:

> I support adoption. I am willing to contribute or review.
>
> Regards,
> Reshad.
>
> From: lisp  on behalf of Luigi Iannone <
> g...@gigix.net>
> Date: Tuesday, November 15, 2016 at 9:58 PM
> To: LISP mailing list list 
> Cc: "lisp-cha...@ietf.org" 
> Subject: [lisp] Call for adoption draft-farinacci-lisp-rfc6833bis
>
> Folks,
>
> The chairs received a request for the following document to be
> adopted as a WG item:
>
> *https://datatracker.ietf.org/doc/draft-farinacci-lisp-rfc6833bis/
> *
>
> Here starts a 14 day call for adoption, this call will end on
> Wednesday the 30 November, 2016.
>
> Please email the WG list stating whether or not you support acceptance.
>
> If you email to support the acceptance of this document as a WG item,
> please
> also indicate if you are able and willing to either contribute to,
> or review, (or both) the draft.
>
> Sitting in silence does not indicate support, please respond appropriately.
>
>
> The Chairs
> Joel & Luigi
>
> ___
> 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] IETF97 IDEAS Kickoff Meeting Agenda

[Padma Pillay-Esnault]

Hello Everyone,

The kickoff meeting for the IDEAS (ID EnAbled networkS) list will be held
during IETF97.

1. Meeting Information

Date: Thursday, 17th November 2016
Time : 6:00 - 7:30pm
Venue: Studio2

Mailing list: IDEAS
List address: id...@ietf.org
Archive: https://mailarchive.ietf.org/arch/search/?email_list=ideas
To subscribe: https://www.ietf.org/mailman/listinfo/ideas

Related areas: RTG, OPS


2. Agenda

Padma Pillay-Esnault (Huawei) - Introduction on problem statement for IDEAS
(10 mins)

Tom Herbert ( Facebook) - The ILA protocol and NMS (10 mins)

Dino Farinacci ( Lispers) - LISP Mapping system, How it works? (10 mins)

Gerry Forster ( UoSurrey) - ETSi NGP: GTP, Mobility  & Flat 5G
Architecture( 15 mins)

Fabio Maino(Cisco) - Deployment experience of  Mapping Systems ( 10 mins)

Dave Meyer (UoOregon/Brocade) - Machine Learning  and Network Mapping
System  ( 15 Mins)

A. Cabellos, J Vilanova & F Maino (UoCatalunya, Ecole P. Lausanne, Cisco) –
A Blockchain-based Mapping System (15 mins)


3. Related Documents and Reads:

https://tools.ietf.org/html/draft-padma-ideas-problem-statement-00
https://tools.ietf.org/html/draft-herbert-nvo3-ila-03
https://tools.ietf.org/html/rfc6830
https://tools.ietf.org/html/rfc6833
http://www.3gpp.org/release-14


Please feel free to forward.

Looking forward to seeing you all in Seoul.

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

Re: [lisp] [Ideas] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

[Padma Pillay-Esnault]

On Sat, Oct 29, 2016 at 10:20 AM, Dino Farinacci 
wrote:

> > In section 5 of draft-padma-ideas-problem-statement, there is a section
> in the table which specifically discuss about the structure of IDs and
> whether we should used them for specific classes or as the Network Mapping
> system is proposing to attach metadata to ID.
>
> Maybe we can experiment with the EID-prefix block 2001:5::/32 from RFC
> 7954/7955 to allocate sub-blocks from large regions of the world. Yes,
> geographical allocations without the issue of the past, since EIDs are not
> injected into the underlay routing and are not based on Internet topology.
>


> Do this first and then decide which, say continent block is registered to
> a regional mapping system. And if an ID needs to register to multiple
> mapping systems. The mapping systems should considered to be relatively
> local in scope and may overlap.
>
> This could help mitigate DoS attacks to a smaller (but still scalable)
> part of the infrastructure.
>

  Agree.

Thanks
Padma

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

Re: [lisp] [Ideas] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

[Padma Pillay-Esnault]

Hi Joel

The security section has the following recommendations for overload issues
1. Rate limit the sending of messages to the mapping system.
2.To improve resiliency and reduce the overall number of messages
exchanged, LISP offers the possibility to leak information, such as reachabilty
of locators, directly into data plane packets
3. Using trustable Map-Servers that strictly respect [RFC6833] and the
lightweight authentication mechanism proposed byLISP-Sec
[I-D.ietf-lisp-sec] reduces the risk of attacks

Here are the potential problems I see with these
1. Rate limiting messages has the same result the DDOS attack was aiming at.
2. Leaking the information may have consequences for the privacy unless we
are using ephemeral EIDs
3. We can trick the system to legitimately make a lot of updates. For
example a large number of IDs distributed that keep on registering that
they have changed locations frequently and an equally large number of
devices trying to access them.

There has been a lot of digital ink about IoT devices being vulnerable to
be compromised and that the sheer number of devices (several billions) to
be the easy target for bonnets.  Discussions about use of rfc2728 or how
ISP could handle these attacks. It is a difficult problem to solve and in
the end we are pushing the responsibility to other entities to do the right
thing ...

In section 5 of draft-padma-ideas-problem-statement, there is a section in
the table which specifically discuss about the structure of IDs and whether
we should used them for specific classes or as the Network Mapping system
is proposing to attach metadata to ID.

I am inclined to think if we can give ID some inherent class which can
restrict what these devices can do. Why would a fridge ever try to access a
bank account unless something is seriously wrong? In the case of IoT, it
would have been possible to drop request from a camera or sensor requesting
to map netflix or twitter.

With IP addresses, it is difficult to differentiate who is what.
Structured IDs allocations or metadata in the NMS may be an opportunity to
simplify some of this operational complexity.

Thoughts?
Padma



On Fri, Oct 28, 2016 at 8:15 PM, Joel M. Halpern 
wrote:

> There are some preliminary thoughts on overload issues in the security
> considerations of draft-ietf-lisp-introduction.
>
> I will also be curious to see what the presentations at the technical
> plenary in Seoul have to suggest on the issue, if anything.
>
> There probably is more with considering.
>
> Yours,
> Joel
>
>
> On 10/28/16 7:39 PM, Padmadevi Pillay Esnault wrote:
>
>> The recent Denial-of-service attacks is a scenario we should have in mind
>> when building robustness in the network mapping system.
>> In draft-padma-ideas-problem-statement-00.txt, there is a section on
>> mapping system security requirements that specifically cover
>> this case.
>>
>> One of the questions that comes to mind is whether the robustness of such
>> a mapping system should drop/throttle responses when it is
>> Overloaded or should we expect it always to handle the load no matter
>> what?
>> While we do propose to rate-limit the messages in the problem statement,
>> isn't this playing into the hands of the attackers?
>>
>> Requesting feedback from the list and ccing wg with expertise in the area
>> or interest in mapping system technology.
>>
>> Thanks in advance
>> Padma
>>
>> Below an excerpt from the draft
>> 6.4.  Mapping System Security
>>
>>The secure mapping system must have the following requirements:
>>
>>1.  The components of the mapping system need to be robust against
>>direct and indirect attacks.  If any component is attacked, the
>>rest of the system should act with integrity and scale and only
>>the information associated with the compromised component is made
>>unavailable.
>>
>>2.  The addition and removal of components of the mapping system must
>>be performed in a secure matter so as to not violate the
>>integrity and operation of the system and service it provides.
>>
>>3.  The information returned by components of the mapping system
>>needs to be authenticated as to detect spoofing from
>>masqueraders.
>>
>>4.  Information registered (by publishers) to the mapping system must
>>be authenticated so the registering entity or the information is
>>not spoofed.
>>
>>5.  The mapping system must allow request access (for subscribers) to
>>be open and public.  However, it is optional to provide
>>confidentiality and authentication of the requesters and the
>>information they are requesting.
>>
>>6.  Any information provided by components of the mapping system must
>>be cryptographically signed by the provider and verified by the
>>consumer.
>>
>>7.  Message rate-limiting and other heuristics must be part of the
>>foundational support of the mapping system to protect th

Re: [lisp] [nvo3] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

[Padma Pillay-Esnault]

Hi David

Thanks for your comments.
I take note of your comment (2) and pointer.

Here is a pointer to the draft
 https://www.ietf.org/internet-drafts/draft-padma-ideas-probl
em-statement-00.txt

Padma



On Wed, Sep 21, 2016 at 4:19 PM, Black, David  wrote:

> Hi Dino,
>
> Here are a couple of areas to consider:
>
> (1) I don't see any confidentiality requirements.   For this and other
> NVO3 security
> requirements, please see the security considerations section of RFC 7365
> (NVO3
> framework) and draft-ietf-nvo3-arch.  The latter contains a new paragraph
> on
> sensitivity of performance and  other monitoring data gathered by the
> control
> plane - that paragraph was added at the behest of both Security ADs:
>
> https://tools.ietf.org/html/rfc7365#section-5
> https://tools.ietf.org/html/draft-ietf-nvo3-arch-08#section-16
>
> (2) This item:
>
> > >   7.  Message rate-limiting and other heuristics must be part of the
> > >   foundational support of the mapping system to protect the system
> > >   from invalid overloaded conditions.
>
> suggests that congestion control is also a consideration to protect the
> network.
> If an existing congestion-controlled transport protocol (e.g., TCP, SCTP,
> DCCP) is
> not used for control traffic, then see draft-ietf-tsvwg-rfc5405bis for
> discussion
> of applicable requirements:
>
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/
>
> Thanks, --David
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp