Minutes IETF109: lisp
minutes-109-lisp-00

LISP WG IETF 109 Minutes

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
                Luigi Iannone ( ggx AT gigix.net )
SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com )

o WG Items
- Update on 6830bis/6833bis documents
      - https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/
      - https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/
  10 Minutes (Cumulative Time: 15 Minutes) Albert Cabellos

Albert C. gave a brief update on the progress of these drafts. Both documents
have Discuss and he expects after addressing those discuss to be done with the
document.

Discussion/Questions:None

- Publish/Subscribe Functionality for LISP -
https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/
  15 Minutes (Cumulative Time: 30 Minutes) Alberto Rodriguez Natal

Alberto presented the changes since -05 version. These are
Removal of deployment assumption of pre-established security,
Added mechanism for security associations via LISP-SEC for PubSubKey and
PubSubNonce is now kept per xTR-ID +EID-record.

He also presented the outcome and comments from early SECDIR review. Some
clarification on use of the term “nonce”. There is some inconsistency on usage
of the term in LISP doc (random but in some cases more like a token and can be
reused,stored..) and RFC 4949(random and no reuse).

Alberto asked the WG’s view?

Albert C.: We have the same issue in the big documents but as it has been used
in the past for a long time so it seems to be accepted but doesn’t know if it
applies here.

Luigi: Proposed that it might be good to use “nonce” in this document to be
consistent with the base LISP spec. Proposed we should add a sentence that says
we use this term nonce to be consistent with the base specs of LISP and that if
we look at the RFC 4949 this would be characterized as a token.

Alberto: Works for me.

Dino: Thinks we should not change it at all and there is a large number of
occurrences of nonce all across the documents. Just busy work.

Alberto: SECDIR 2nd Comment on the value exceed the field space but it looks
like they will last for a very long time.

Luigi: Suggested to add that if it does wrap around to say in the doc what to
do for completeness.

Dino: In previous protocols, when there is a sequence number is wrapping around
then you check with your previous number and see the difference and detect the
wrap around.

Albert: Makes perfect sense.

Alberto: Feels the doc is ready for last call.

Matt: proposed to fix these and take it to the last call

- Network-Hexagons: H3-LISP GeoState & Mobility Network -
https://datatracker.ietf.org/doc/draft-ietf-lisp-nexagon/
  15 Minutes (Cumulative Time: 45 Minutes)
  Sharon Barkai

Sharon gave an update of changes since 108 meeting

Discussion:
Sharon: Given that we want to mark this problem and move on. Every problem has
its own tiles, feeds, channels etc., would like to finish the hexagon draft and
move it to be an rfc. Do we have to wait for base spec or can we publish this
as is? Or refer to the bis in the generalized draft?

Joel: if we try to publish any LISP drafts that are pointing at the current
experimental RFCs even if those drafts are themselves experimental the IESG is
going to look at us and say go wait but you're having us work on all this other
stuff. I understand why you want to get it done and I sympathize but I really
think you should be pointing at the bis drafts and get everything done.  We're
close enough don't worry about the time difference.

Sharon: OK

Alberto:  Quick comment, don't have an opinion I just raised the point on the
intended status of Nexagon draft right now is informational not experimental so
I don't know if we still have to wait for the bis.

Sharon: I'm perfectly fine waiting
Luigi: I don't know if we need to. My personal opinion honestly is even if
It is informational it would be better if it points to the bis documents. Just
for more credibility for the content because at some point somebody could read
and say yeah that is based on the old specs not the proposed standard. We are
close enough, worst case will sit a little bit in the editor queue.

Sharon: It's your consideration is your decision. I understand what Joel said
just be aware of the other side of it. which is if you want to hand off this
nexagon as an RFC to organizations like AACC, the auto edge,  or anything that
IETF is not in their industry it's not like dealing with Juniper and Cisco. The
minimum has to be in RFC.  So until then you know it's really delaying it so
you know just um observe the progress and if it's  reasonable then fine or not
just make a call up to you.

Luigi: Again I will give you my personal opinion okay these documents are very
close to being done. I would wait a few weeks just to see if the Albert just
submitted new versions maybe today or tomorrow they clear all the discuss.
Please have a look to the new versions okay so maybe in a couple of weeks these
documents are through so if you move your document right behind it's just two
weeks delay I mean it's not a big deal but again this is my personal opinion
Sharon: all right

o Non WG Items

- NAT traversal for LISP -
https://datatracker.ietf.org/doc/draft-ermagan-lisp-nat-traversal/
  15 Minutes (Cumulative Time: 60 Minutes)
  Albert Lopez

Albert Lopez presented the motivation of doc and updates. The doc is now very
close to be completed

Albert C: Commented that to his knowledge there are at least 2 implementations
and that the draft is still an individual contribution and would like to ask
for the WG adoption.

Luigi: Excellent question. Like the work done, this is based on the pain you
experienced. Last time Dino also presented a universal solution. So, Dino what
are your plans?

Dino: If you are asking about my implementation plans, I am not going to
implement because the performance of the system is going to be way worse than
what we have because of all the intermediate processing that has to be relayed
through the RTR. Fundamental point, there is too much indirection of messaging
and I showed an alternative solution that performs better. Handoffs are really
important if you want fast convergence.

Luigi: What do you plan to do with your document? We cannot have 2 documents to
discuss the NAT traversal so at one point the WG will have to discuss whether
to merge the documents.

Dino: What I presented last IETF and doc, I will support whatever the WG wants
to do with. Not sure I will support a merge as you will need to do the pros and
cons of each one merge it. That would be a lot of work and compromise the
design. You will have to go through the pros and cons of each and decide to go
with one or the other or come up a 3rd alternative (merge) but I’ve never seen
that successful before.  It always produces something worse than either of the
other two alternatives

Luigi: What I suggest is the following the request for the authors to adopt the
document and if Joel’s agree what we can do is to formulate a call on the
mailing list. Just formulate it in in a way that makes that all the
participants in the mailing list aware that there has been a recently a
different approach from Thank you for the clear presentation.

Joel: We need to bring it to the WG.  WG needs to be clear what it  wants.

- LISP Distinguished Name Encoding -
https://datatracker.ietf.org/doc/draft-farinacci-lisp-name-encoding/
  10 Minutes (Cumulative Time: 70 Minutes)
  Dino Farinacci

Dino presented the draft and saying that it was very useful for
troubleshooting, the idea is not new but derived from similar feature in ISIS
and OSPF. He addressed the comments on the list by adding use case section with
examples. Added also a collision consideration section after Joel had a comment
that if there's two different types of distinguished names registered. Will
they counter conflict with each other and if they would have to be in separate
instance ids just like two routers that are behind NQTs use 192.168.1. Those
two things are registered to the same mapping system but they don't collide
because they're in separate instance ids.

Dino : So, we started the draft in April of 2016 and we're now at um the latest
draft that I just submitted a few days ago is 2020. So, this very simple seven
page draft has been going on now for four years. Comes to a point where you
have to ask why is the progress been so slow. There is utility, there has been
some support.  There has been commentary over the course of the six years and
there's really has been no strong objections so I’m wondering why.

Joel: I have to disagree with that once.  I went and looked carefully at this I
do have strong objections what is in here are not distinguished names and as
I've said on the list the solutions you've proposed are not good enough. This
is a “I can just dump an arbitrary string in and well it'll work with my use
cases and as long as everybody's careful it'll work but I can't tell you
exactly how to be careful”.  Other protocols that have done this have gotten
into big trouble and he really doesn’t want LISP going down this path. <Chat:
Joel want it to be noted in minutes that he has objection to the slides with
Dino's claim that there is no strong disagreement.>

Dino: well I have no reply to that I don't know what your definition of a
distinguished name is but I’m using that term because it's assigned to afi 17. 
What it is an ascii encoding which or can be a unique Unicode encoding if we
use a different AFI but it's just a it's just a string and you know it's no
different than a DNS name where you have to coordinate what the value is.

Joel: The DNS names are structured. Yes, they are distinguished these things
are not distinguished they're just arbitrary .

Dino: Not calling them distinguished. Saying that the AFI is distinguished on
the particular use case they have to have structure. The ECDSA draft shows an
encoding where you do not have collisions and it's as simple as that. If you
think another use of it's going to collide with that specification you don't
run it in the same instance id so these are very solvable problems so don't
know what the objection is.

Joel: No, they are not. Fundamentally you're expecting everybody to magically
go over and use it without going to finding how to distinguish it.

Dino: Those drafts specify how  the names are supposed to be encoded. Read the
drafts and give me specific comments please rather than I don't like it because
it's been done that way before

Joel: You’re missing my point. The usage draft specifies how to encode it but
the draft doesn't specify what the requirements are that must be met so that
things are distinguishable so that different uses don't collide. Just saying
don't think they might collide into different instance ids is not going to work
for writing other specs. It requires magic knowledge.

Dino: It does work Joel, I don't know what the problem is they won't collide if
they stay separate. Why do RFC 1918 addresses not collide?

Joel:  That's a big problem

Dino: The system works because we keep them separated because we have
virtualized networks that's how it works.

Dino: Third attempt at least to request at least the working group draft.
Had support few months ago, but chairs thought otherwise and then Joel objected
to it.

Luigi: I have to disagree as well.  Let me try to explain my concerns -the
document has not been really evaluated by the group. You had once presented the
document then you had several updates etc. What happened is that you moved
forward the document at some point and said it's time for the working loop to
adopt this document.

Dino: Clarified that he never said so that he is requesting the working group
to consider it as a working group document.

Luigi: yeah okay fair enough.

Dino: If we make a working group document more people will review it.
Appreciate the comments

Luigi:  The point is to become working group document, there must be some
interest people have to see the interest in the document and say I need this.
What happened on the mailing list was more about “yes why not”

Dino: Type of support? there was support on the list people said it should be a
working group document. For some reason, the chairs are deciding to ignore that.

Luigi: no no that's not fair, trying to see what is happening. There are some
concerns about development. What I suggest is that you and Joel really try to
discuss what are the concerns and what are the technical issues concerning the
this document okay and then we go back to the mailing list and the working
group. These are the issues that Joel had and does anybody has concerns and 
are people really interested in having these in lisp because you think whether
this is a feature that is needed or not. It works for you when you are alone in
your implementation something that has to work with the Internet and the LISP
as a whole that's my point. If we reach this level of specification because in
my opinion the documents I told you this on the mailing list is under
specified. There are missing pieces that maybe they are clear to you but are
not written there.

Dino: okay so I would like to receive specific comments please rather than just
making a high-level problem.

Luigi: Said he will send specific comments.  The point is to check if the
working group should consider adopting this document. It's about the interest
how useful is for the least I understand from your perspective it is very
useful but it's about the working group.

Dino: We have other implementations of it too, not the only one using an
implementation so.

Luigi: Maybe I'm missing something and we will work in the coming weeks to
clarify everything.  But Joel has strong concerns. We work on this and then we
move on we check what the working group thinks.

Fabio: I just wanted to make a short comment. Looks like Joel has some specific
objection right probably it seems that the word might help from him
articulating better what are the objections. The suggestion that Luigi's giving
is spend some time with Joel. The two of you sit down and you try to basically
understand what Joel is saying and Joel is trying to articulate in more detail.
That will eventually lead to having more content for your document so I don't
see how that is detrimental.

Dino: Right we have started that process and we had one round. The document
was written and Joel's not satisfied so we have to do it again so that's all
there's to it.

Fabio: That's how it works right sometimes

Luigi:  Then we will check if the working group is interested in this work I
hear your voice you say it is but we have to check it as for the usual process
okay. Is it okay for everybody if we proceed in this way does anybody has
further comments? I invite you all of the people to read anyway the document
and beside the technical concerns that you may or may not have make up your
mind if whether or not this is something useful for this and the working group

Dino: Mentioned that there was several supports on the mailing list.

Luigi: Mentioned that nobody said that nobody is interested. Rather we were not
able to declare a strong consensus and there were technical concerns about your
document. We can work on the technical concerns and make a full normal checking
whether or not the working group is interested or not.

- SD-Access: Practical Experiences in Designing and Deploying Software Defined
Enterprise Networks - https://arxiv.org/abs/2010.15236
  30 Minutes (Cumulative Time: 100 Minutes)
  Jordi Paillissé

Alberto: Jordy has done a great summary of the paper in the presentation but
the actual paper that is available on that link.

Luigi: You seem to rely quite a bit on the MAC address. That works very well in
enterprise networks but if you have a public deployment let's say a huge campus
that wants to get Wi-Fi connectivity now maybe you will connect to user in iOS
or Android and I discovered this week that they have features to change
dynamically the mac address because of privacy concerns. Maybe you don't have
an answer now but have you thought how ? Can you comment how would work if
there is this thing of dynamically changing the mac address?

Jordi: Well that's really good question I should probably think about it
because I couldn't attend the BOF yesterday and also because I’m not very savvy
in the implementation. We have Mark here that can comment more on the
implementation but so lisp is just something on top of all the layer 2. I
really don't know how it would solve it but I think it's a problem that
everyone would have also still because it's not LISP specific;

Joel: no no it's not LISP specific but for those who are tracking the missing
pieces this there was a BOF called MADINAS  yesterday driven by a bunch of work
over at IEEE on randomizing mac addresses periodically changing MAC addresses
and what that does for IP activities which depend on MAC addresses .

Mark: actually we have started discussing how to address this problem in the
with the sda solution there are and this was explained yesterday in that BOF
there are multiple approaches to randomization of MAC. I would say that thanks
to the way that LISP works multiple of those use cases could still be handled
well the most extreme one though I think it's the one that Apple has
implemented in some of the latest Ios where when they really randomize or they
really generate the different MAC address every time they change access point
and this is the one that we are studying now but there is this mode in sda
where you can work L3 only and just use IP addresses as identifiers that could
be one possible first approach but still yeah some work to be done. As you say
right it's affecting everybody right not just at LISP

- Overflow Time/ Discussion
  20 Minutes (Cumulative Time: 120 Minutes)

Dino: Are RFC numbers soon to be assigned to the bis document?

Joel: we are hoping we will go in soon but it depends on the RFC editor queue.
And we do not get to tell them what is the priority.

Dino: if we could still write documents and reference the rfc doc #

Joel: says that we are not supposed to use these numbers as they can change.

Sharon: that is where I want to be careful. That paper to go to ITU but we
cannot.

Joel: We all want it to be done but we need to do things in order