Subject: Re: [lisp] Some ideas about the interworking issues.

From: Xu Xiaohu <[email-masked]>
Date: Sat, 30 Jan 2010 15:47:39 +0800

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年1月30日 10:38
> 收件人: 'Darrel Lewis (darlewis)'; 'Xuewei Wang'; [email-masked]'
> 主题: re: [lisp] Some ideas about the interworking issues.
> 
> 
> 
> > -----邮件原件-----
> > 发件人: [email-masked] [mailto:[email-masked]] 代表 Darrel
> > Lewis (darlewis)
> > 发送时间: 2010年1月30日 5:38
> > 收件人: Xuewei Wang; [email-masked]
> > 主题: Re: [lisp] Some ideas about the interworking issues.
> >
> >
> > > Hi all,
> > >
> > >
> > > I am a newcomer of this group. Recently i read the
> > > interworking draft, below is some my considerations.
> > >
> >
> > Thanks for your feedback!
> >
> > >
> > >
> > > The PTR mechanism allows a non-LISP site to send packets to a
> > > LISP-NR site. Traffics from the non-LISP to the LISP-NR sites
> > > will be routed towards the PTRs, which will force heavy
> > > burden on the PTRs, and possibly PTRs will be the bottleneck
> > > of the network. LISP-NAT mechanism allows a LISP-NR site to
> > > speak to a non-LISP site, which has no the problem of the PTR
> > > mechanism, but not consider the case of a non-LISP site
> > > speaking to a LISP-NR site.
> >
> > I'm sorry the draft was not clear.  A non-LISP site can communicate with
a
> > LISP-NR which is using LISP-NAT because the outer-NAT addresses are
routable.
> > So a LISP-NAT site would put this outer address into DNS.  Of course,
this
> has
> > all the classic limitations of IPv4 NAT.
> 
> If so, the hosts in a LISP site would have to also use the routable outer
address
> as destination address for initiating communication to the hosts in a
LISP-NR.
> As a result, the traffic between two LISP sites would also have to
traverse
> the PTRs. I think this is not your expection.

Hi Darrel,

By the way, assuming a internal host at the LISP-NR site wants to initiate a
communication to another internal host at the same site, if the initiator
obtained the routable outer address of the responder as a response to its
DNS query, packets from the initiator to the responder would have to be
forwarded up to the nearest xTR, which in turn would then rewrite the outer
address to appropriate inner address (i.e., EID), and forward the packet
towards the initiator. This so-called hairpin issue should be avoided,
right?

> > > I am thinking another method for the case of a non-LISP site
> > > speaking to a LISP-NR site as an extension to the LISP-NAT
> > > mechanism, with which the traffic load on RTRs could be
> > > reduced to some extent. This method only requires some
> > > changes to DNS、ITR and ETR. By defining a new opcode for the
> > > DNS message, we can identify whether a DNS query message is
> > > from a LISP site or not.
> > >
> >
> > So if I understand you correctly, in theory a LISP site would return the
outer
> > address to non-LISP sites, and the inner address to LISP-NR sites.  It
would
> > know to do this because the incoming DNS request indicated that the
source
> was
> > a LISP site.
> >
> > >
> > >
> > > At the source site an host initiates a DNS query for the
> > > destination host in a LISP-NR site. If the source site is a
> > > LISP site we make the DNS resolver or the ITR of the site to
> > > set the new defined opcode which indicates the DNS request is
> > > from a LISP site. If the source site is a non-LISP site no
> > > change is needed.
> > >
> >
> > Understood.
> >
> > >
> > >
> > > At the destination site when receiving a DNS query message,
> > > the DNS server responds with the EID of the destination host
> > > and copies the new defined opcode of the query message to the
> > > response message. The ETR intercepts the response message and
> > > judges whether the query is from a LISP site or not according
> > > to the opcode of the response message. If the query comes
> > > from a LISP site the ETR assigns a routable address of the
> > > ETR for the destination host(reusing the LISP-NAT function on
> > > ETR) and responds with the routable address to the source
> > > host, and if the query comes from a non-LISP site the ETR
> > > just forwards the response message to the source host.
> >
> > I'm not sure that its viable to expect the ETR to intercept the DNS
reply
> packet
> > and do something to it.  There are many reasons for this, including the
fact
> > that the ITR may be on a separate device from the ETR, so the ETR will
never

Can the LISP-NAT mechanism works well if the ITR is on a separate device
from the ETR?

> > see the response.  Also, hijacking and changing the contents of
data-packets
> > on the fly is not something I feel comfortable having a protocol doing
> > (performance, security, lots of issues).

Changing the DNS messages on the fly (i.e., DNS-ALG) is not unusual in the
current NAT deployment scenario, I guess.

> > >
> > >
> > > Thus the host from the non-LISP site can communcate with the
> > > host in the LISP-NR site with this routable address as
> > > destination address, and the ETR of the LISP-NR site plays
> > > the same role as a NAT.
> > >
> > >
> > >
> > > How do you think this method?
> > >
> > >
> > My initial reaction that, while an interesting idea, it suffers from
some
> > problems (if I understand this proposal correctly):
> >
> > 1)  Its complicated LISP-NAT is supposed to be a local, simple mechanism
to
> > allow for communication

Yes. However, the current LISP-NAT mechanism is only suitable for the
communication from LISP-NR site to non-LISP site, not vice versa, if I
understood it correctly.

> > 2)  It requires middle boxes to modify DNS reply packets

Yes, see the above.

> > 3)  It assumes a LISP-NR site is using DNS when it communicates with a
LISP-NR
> > site.

Yes. However, this is just an optional trick to lowering the traffic burden
on the PTRs (just like the route optimization trick in Mobile IP to reducing
the burden on the home-agents), rather than an alternative to the PTR
mechanism.

> > 4)  It requires DNS changes when a site migrates to LISP

No, maybe only ITRs and ETRs need to change.

Xiaohu

> > Thanks for taking the time to write this idea up!
> >
> > -Darrel
> >
> > >
> > > Xuewei Wang
> > > _______________________________________________
> > > lisp mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/lisp
> > >
> > _______________________________________________
> > lisp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/lisp

---

From: John Zwiebel <[email-masked]>
Date: Sat, 30 Jan 2010 04:35:25 -1000

> speaking to a LISP-NR site.

Good day.

There is an implicit assumption in your statement that we hope
will be incorrect.  That is that the PTR will be a bottleneck.
While PTRs will highly aggregate EID-prefixes, if a given PTR
is supporting too much traffic, one can deploy a second (or third)
PTR in a new geographical location for the same prefixes or one can 
reconfigure all PTRs for a given set of EID-prefixes to provide
more specific prefixes and reallocating those prefixes longer
prefixes among all of this group of PTRs.

Given that the prefixes advertised from a PTR have no direct
relationship to the DFZ routing, you can deploy a new PTR
anywhere.

Hope this helps.