Hi Dino,
thanks for your replay.
The main goal of this draft is to document what is implemented in ODL
(https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architecture),
with the hope that comments and feedback will help us improve that
solution, and facilitate interoperability.
The driving requirement (as stated upfront in the abstract) is
interoperability with EXISTING xTRs, as specified in RFC 6830.
The reason for that requirement is that, willing or not, we have to
deal with those xTRs for at least another couple of years (and then
some...). We want to deploy SDN/LISP solutions today, or LISP will just
become irrelevant in the architecture of programmable overlays.
I will try to make the best use of all the comments sent, but in my
opinion the comments that belong to this thread (as most of those that
you include below) are those that help improve the solution within the
constraints of that requirement.
I believe there's a broader conversation that needs to happen at the WG
level, that is how to augment LISP (xTR+MS/MR+Protocol) with
publish/subscribe extensions (and possibly more) to address the SDN use
case. As you mention we started that conversation within a small group,
and looking at the Boucadair draft there are other people that are
looking into similar problems.
I think Alberto is putting together a set of slides to summarize the
conversation we had and some observations on
draft-boucadair-lisp-subscribe that may help the working group to kick
off a discussion on this topic. I suggest we use that thread, and maybe
some time in Japan, to make progress on that work that is done under
much broader assumptions than this draft (and would make for a great
working item in the new charter).
Thanks,
Fabio
On 9/29/15 11:27 AM, Dino Farinacci wrote:
Hi guys, thanks for the draft. I have some comments. But to note, in private
discussions, we have talked about a more general mechanism that is in another
draft to be published. Thanks Alberto for contributing to both drafts.
For others on the list, the main difference is the use of Map-Notify versus
SMRs as the means to inform an ITR or PITR a mapping entry has changed. In this
draft SMRs are used so ITRs do not need any changes. However, RFC 6830 says
that ETRs are the only ones to send SMRs.
The general design uses Map-Notify messages, because the mapping system
typically sends Map-Notify messages (for the VM-mobility use-case and
signal-free-multicast mechanism). But ITRs or PITRs that do not support
signal-free-multicast or implement the VM-mobility use-case may not support
them at this point in time.
In any event, we can discuss this at next WG meeting.
Here are my comments, your text comes first and is indented and my comments
follow:
2. Map Server extension
This document enables MS to generate and send SMR messages towards
(P)ITRs. SMRs originated in a MS follow the same format described in
[RFC6830]. Besides the fact that they are sent from a MS, there is
no difference between an SMR originated in an ETR and one originated
in a MS.
When a MS generates an SMR, it uses as source-EID the EID-prefix it
wants the (P)ITR to send the SMR-invoked Map-Request for. The EID
included in the EID-record field is the one belonging to the (P)ITR
EIDs don’t “belong” to PITRs. Typically, the ETR sends SMRs with an EID-record
to the EID-preifx the ITR is encapsulating for. Since there are no configured
database mappings on PITRs, you have to specifiy what actually is put in the
EID-record. I suggest an AFI=0 or an EID-record count of 0.
the MS sends the SMR towards. As source locator for the SMR message,
the MS uses one of its available locators. This has implications in
the processing of the SMR at the (P)ITR as described in Section 4
When the MS has to send an SMR is implementation specific. However,
as specified in [RFC6830] and noted in Section 7, SMRs MUST be rate-
limited. It must be noted as well that, as described in Section 3, a
MS that sends an SMR may not receive the SMR-invoked Map-Request that
the (P)ITR generates as response to the SMR.
So when a mapping changes, an ETR will register to more than one map-server. I
did not see any text to indicate if more than one map-server will send an SMR
to the (P)ITR. Are multiple messages sent? And does the ITR ignore subsequent
messages or sends a SMR-invoked Map-Request for each SMR received? Note, this
will add unnecessary messaging to the global system.
This document introduces no changes in the specification of (P)ITRs
and thus it is backwards compatible with legacy equipment only
compliant with [RFC6830]. However, since SMRs were designed to be
sent by ETRs, and legacy (P)ITRs expect to receive SMRs only from
ETRs, the implications of sending SMRs from a MS are discussed in
this section.
You need to indicate what PITR does with an SMR when the EID in the EID-record
is not cached, or not configured.
Also, note, that a map-server may also be an RTR, so the RTR’s locator may be
in the map-cache locator-set of an PITR or ITR. In that case, you need to
explain if the SMR-invoked Map-Request should go directly to the RTR/MS system
or via the mapping system (ie. via a Map-Resolver).
Note, the Map-Notify approach scales much better, because when the MS sends the
Map-Notify the locator information is in the message. So, in a trusted system,
the ITR need not send a x-invoked Map-Request. So it will scale much better.
See draft-farinacci-lisp-signal-free-multicast for details on
replication-list-entry changes (which is a locator-set merge change).
And could the authors please state your intentions on the temporary or
permanent nature of this draft. I have heard that this is something proposed as
a transition for SDN environments.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
