Skip to main content

Minutes IETF113: lisp
minutes-113-lisp-01

Meeting Minutes Locator/ID Separation Protocol (lisp) WG
Title Minutes IETF113: lisp
State Active
Other versions plain text
Last updated 2022-04-19

minutes-113-lisp-01
IETF 113
LISP Working Group Meeting Minutes

CHAIR(s):  Joel Halpern ( jmh AT joelhalpern.com )
                Luigi Iannone ( ggx AT gigix.net )

SECRETARY: Padma Pillay-Esnault ( padma.ietf AT gmail.com )


AGENDA
Session 1/1 (60 Minutes)
=-=-=-=-=-=-=-=-=-

Tuesday, March 22, 2022
12:00 - 13:00 (UTC), Session I, 60 Minutes

Administration
    Halpern/Iannone
    - Agenda Bashing
    - Status reports for WG drafts
	10 Minutes 	(Cumulative Time: 10 Minutes)

Luigi:
-	A few documents in the RFC editor queue, stuck due to references to other
documents in the queue.
-	Yang model document has been worked on since last 2 years very close to
WG LC and may be next.
-	LISP-DDT is an experimental document and may need to move to standard
track to make early allocation number permanent
-	NAT document progress target for this year.


o WG Items

- LISP EID Mobility
  15 Minutes (Cumulative Time: 25 Minutes)
  Fabio Maino

Fabio presented a quick update on EID mobility and some work on L2 multi-homing.
There are some comments from last IETF but not updated the document yet.

Discussion:
Dino: Recalling that there was no reason not to use the site id. Do you know why
that has changed and because now we have an issue because what if the site id is
different than the ES-ID are the XTRs known to be in the same site or not. The
reason for using the site id was because then we wouldn't have to change the packet
formats. Do you know why now we would want to make that change?
Alberto: This is actually reflecting the discussion on the mailing list.  You have a
good point that a XTR may have different VLANs so you may have different
segments on the on the XTR. You may or may not want to put them in the same site
id or using a single site to cover all those different layer 2 segments.  So we tried to
include your point and be coherent with the discussion on the list.
Dino:  It is confusing because the slides say that it's an ES-ID for two XTRs where it's
actually an ES-ID per VLAN per pair of XTRs or more than one.  Is that true?
Alberto: Yes.  The ES-ID would be for layer 2 segment. Does that make sense now?
Dino: May be you should call it a VLAN segment id, or something like that but  it
needs to be clear.
Alberto: Regarding the name I may need to check what other protocols use as well.
Dino: Fine on name. I'm worried about the scalability of this now. Can't we say that
one or more XTRs are selected as a designated forwarder for all VLANs like a
default. This is the big change of the Map-register and I don't know if it's worth it for
L2 overlays. There's a big cost here in for the benefit so it is a judgment call.
Alberto: I don't have an answer for you now, the ES-ID is intended to address at
least three problems: the frequent multicast, the split horizon and aliasing of the
EIDs. If you have a specific optimization for the residential case we can certainly
include that.
Dino: Suggesting to use site id and you use a designated forwarder election or
selection for all VLANs that's all. You make that statement and we don't have to
change the packet formats.
Alberto: I'm not entirely sure whether we are back to the problem that we had
originally, namely that you may have multiple VLANs in the same xtr.
Dino: It's all or one issue, that's how we could solve the problem because now you
have to list each VLANs that are active. Potentially have up to 4 000 entries in the
map register which makes the packet really large even if VLANs are not in use.  If
one gets configured at some point you have to know who the designated forwarder
is. Either you do it before you configure the VLANs at the site or you're going to have
a broadcast loop.
Alberto: Can it really happen to have all those VLANs configured at once?
Dino : Even 50 is still a lot.
Alberto: But typically you send just one EID per Map-register message.
Dino: But you may want to pack them.
Alberto: Yes, you may, but typically we don't do that.
Dino: There's a lot more discussion that has to go in like how you're going to do it.
Alberto: Between now and then next IETF we can look at the scalability of number
of VLANs and we can discuss. Sounds good?
Dino: Sure.
Luigi:  You can even start the discussion on the mailing list.
Fabio: Can you send a note to the mailing list. What you're saying is that we should
consider scalability because there are up to 4 000 entries for each id any id can be
grouped in registration.
Dino:  The other problem is that there's one segment id per Map-register where if
you are going to put multiple MAC address EIDs in the Map-register then you have
an ES-ID per EID which means it has to go in the EID record which means now you
have to specify wherever an EID record is used in all the messages you have to
specify what the segment id is. For layer 3 you do not need that and it is very
inefficient use of space. That's why I think it should be all or nothing. Just select the
designated forward for the site for all VLANs.
Alberto: Let's do the discussion on the list.
Dino: Sounds good. I'll send a note.

o Non WG Items

- LISP Reliable Transport
  10 Minutes (Cumulative Time: 35 Minutes)
  Alberto Rodriguez-Natal

Discussions:
Dino: Lowercase r bit in the map notify should be next to the record count field
because if you need to use more bits in the map notify you want to keep the
contiguous bits.
Alberto ? Fine with me.
The other point to discuss is which port to use for QUIC reliable transfer.
Discussion on port number convergend on the need to ask an expert on how to use
QUIC (especially port number).
Joel: Sent message to QUIC expert.
Luigi: How to signal which reliable protocol to use? A specific bit? I will send email
to open the question on the mailing list.
Luigi: How security works? What if we use TLS? Need security review. Not
necessarily before adoption.

Poll for adoption and this document is useful?
Luigi: clear consensus.

Dino: This does not create any pending reference that may block further the main
specs, right?
Luigi ? There are no reference to this document in the main spec.


- Ground Based LISP - A Mobility and Multilink Solution for Safety Critical
Communication in Aviation  15 Minutes (Cumulative Time: 50 Minutes)
 Bernhard Haindl

Overview of Ground-Based LISP for Aeronautical communications discussed in
ICAO.

Discussions:
Albert: Requested some clarifications on selective and wildcard
subscription/unsubscription.
Bernhard: Is to subscribe to specific EIDs (not a prefix).
Albert: What is the digital signature?
Bernhard: Is for the aircraft to sign certain control messages, so that the destination
can verify the sender, and we do not have this on LISP.
Alberto: We support the work let?s continue on the mailing list
Luigi: Yes, send email to the mailing list with your needs and let?s discuss there.

- LISP Mobility Routing
  10 Minutes (Cumulative Time: 60 Minutes)
  Sharon Barkai

Discussions:
Ran out of time