SECRETARY: Alberto Rodriguez-Natal ( natal AT cisco.com )
Session 1/1 (60 Minutes)
Room: Wicklow Hall 1
Padma/Luigi/Alberto
Agenda Bashing
Status reports for WG drafts
Marc Portoles Comeras: Concerning 24 vs 32 IID. AFAIR you use the
restricted 24 bits when you use it in the data plane, but in the control
plane you can use the full 32 bits.
Luigi Iannone: This was true at the beginning. During publication of
9300/9301, because it was not clear how to go from 32 to 24 bits and
vice versa, decision has been made to fix it at 24 bits. As such in
order to align to existing specification the IID must be 24 bits. The
extended EID should use 24 bits. We can add an appendix to explain the
situation in the 8111bis document.
Damien Saucez: We need a security review to see the document is in line
with currently practices.
Luigi Iannone: We can ask an early review from the security directorate.
Dino Farinacci: This duplicates functionality that LISP already has when
you're doing EID Mobility. EID Mobility definitely validates the source
EID against a configured list of "roamable" EIDs prefixes. I assume that
SAVI is done just for EID type not RLOC addresses.
Marc Portoles Comeras: Yes, it is just for EID Addresses. It brings also
duplicate address detection.
Dino Farinacci: In the EID Mobility draft we say first come first served
to the mapping system. An XTR that sees my packet could drop packets
while it's validating that there's nobody else using the same address.
Now the guy can move and he can be deregistered so the spoofer could
actually sneak in.
The spoofer does not even need to run LISP if it is depending on a
trusted XTR that has the keys to the mapping system. So, it looks not
reliable.
Marc Portoles Comeras: May be. But SAVI offers a framework for multiple
use cases. For example, the use of DHCP, which is also kind of a
external trusted source that we integrate via SAVI to the whole network.
But we can discuss offline to see where there are overlaps with EID
Mobility
Dino Farinacci: OK.
Dino Farinacci: Is this going to add latency in case of mobility?
Marc Portoles Comeras: Yes, and it depends on the level of trust that
you want. But we have a fast roaming section that allows to start
quickly and correct things later if there is a duplicate address.
Padma Pillay-Esnault: Imagine the case where you have somebody who is
legitimate that goes away and somebody sneaking in. How do you reclaim
your IP address? I think we need to write a little bit more about how to
handle this case.
Marc Portoles Comeras: Good point. This is where we rely on the work
that the SAVI working group did. You bind the IP to an anchor point. But
it has some limitations and especially in the first come first served
model. If someone goes away and someone else comes and claims the
address, the problem that you will have is that that IP won't collide
with anybody. You are right. We can explore whether or not SAVI did
consider this issue.
Padma Pillay-Esnault: How will this work if we have Anonymous EIDs?
(Question will be addressed offline because of audio issues)
Dino Farinacci: Is there any provision in SAVI to have a one IP to many
anchor point bindings?
Marc Portoles Comeras: I do not think SAVI is ready for that.
Luigi Iannone: Invite authors to send email on the mailing list to
receive feedback especially since it has been submitted few days ago
(missed cut-off date).
The Locator/ID Separation Protocol (LISP) for Multicast Environments
Signal-Free Locator/ID Separation Protocol (LISP) Multicast
LISP Multicast Overlay Group to Underlay RLOC Mappings
Vengada Prasad Govindan: I confirm that we can signal the underlay
multicast group using the join prune attributes.
Vengada Prasad Govindan: Making the draft vdas-lisp-group-mapping
experimental is a good idea. There are two part in the document, the
hash based and the mapping system based. In my opinion the hash based is
good enough to become standard track.
Dino Farinacci: Good point. The hash based can be run independently. But
I have no opinion on whether to split it.
Vengada Prasad Govindan: We can continue the discussion offline.
Vengada Prasad Govindan: RFC 6831 is very well implemented in multiple
implementations. The biggest addition since RFC 6831 is that we have
included the Ingress replication part which is also been implemented in
production so just a data point about stable implementations running in
large production networks for many years.
Dino Farinacci: Does Cisco has a signal free implementation as well?
Vengada Prasad Govindan: Yes, but not yet released.
Dino Farinacci: Additional documents to deal with: lisp-satellite;
lisp-decent; lispers-net-nat.
Alberto Rodriguez-Natal: I think makes sense having an informational
document on the satellite use case. I would like to point out that we
have other two use case documents that have been hanging around for a
while the ground base lisp for civil aviation and the nexagon one for
connected vehicles. I would like to see if we have a common approach for
those documents. I would suggest that we take the three of them can
follow ISE process.
Luigi Iannone: One of the last milestones is about an informational
document about LISP new use cases. One approach could be to merge the
documents and have short overview of the use cases at the beginning and
details in appendixes. Or we keep them separate. TO be discussed.
Dino Farinacci: Is that a good idea to merge big documents?
Alberto Rodriguez-Natal: Personal opinion is to have separate documents
to keep them readable. But they need to follow the same process.
Luigi Iannone: On the NAT document. I discussed with Eliot Lear (ISE) he
expects an update on the WG NAT approach before IETF 122 so that he can
make an assessment on the lispers-net-nat document. Damien Saucez and
myself will work on it. We just gave priority to 8111bis.
Luigi Iannone: For the LISP-decent document. This went through two
unsuccessful WG adoption calls and is now out of the scope of the
charter. So, it make sense to submit to ISE. Please go ahead.
Luigi Iannone: Concerning the request for WG last call of the multicast
documents. Padma, Alberto, and myself discussed over it and in order to
be in line with the procedure we prefer to have reviews of the documents
before moving them forward. We will do our best to have the reviews
quickly.
Luigi Iannone: Please submit a new revision addressing the remaining
review and we will issue the WG last call.