Subject: Re: [lisp] advertising shorter EID prefix

From: [email-masked] (Noel Chiappa)
Date: Fri, 20 May 2011 14:56:53 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    > Assume that a PTR advertises mapping for 10.128/16.

A PITR (advertising 10.128/16. into the backbone routing, so legacy 'external'
sites can get packets to that LISP-only node(s)) or a PETR (advertising
10.128/16 into the ALT so that LISP-only nodes(s) can get packets to external
'legacy' sites)?

(If there are any instances of PTR still in the doc, we need to get rid of
them... I forget which of the two it used to mean.)

    > It means that for any site that is not LISP-capable, but whose addresses
    > are subsidiaries of 10.128/16, traffic to that site must flow through
    > that PTR.

Not necessarily. If you meant PETR, non-LISP sites will send traffic to the
destinations covered by a PETR directly.

    > That is probably ok for sites connected to the ISP that hosts that PTR.
    > But what happen if some of these sites are connected to other ISPs? Is it
    > correct that in this case traffic to these sites could take a suboptimal
    > route, as it would need to traverse through the ISP that hosts the PTR
    > that advertises mapping for 10.128/16 ?

Use of PITRs and/or PETRs is fraught with possibility for non-optimal paths,
especially early on when there aren't many. As the number of PITRs and PETRs
deployed goes up, the problem should get less, more or less in line with the
number of PxTRs deployed. (Details for a particular site will vary depending
on the details, of course.)

Of course, some will consider any non-optimality in paths to be a feature, not
a bug - it will encourage people to deploy LISP! ;-)

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 20 May 2011 15:05:52 -0400

I would also add that if a PITR advertises a prefix that is shorter than 
what is being used for EIDs, then I think that he is producing a false, 
unauthorized, BGP advertisement.  Consequences follow.

For portions of a prefix that are used as EIDs, a PITR which receives 
traffic for those addresses encapsulates the traffic, and ships it to 
the correct ETRs.
But, if there are address in teh advertised prefix that are beign used, 
and are not reachable via ETRs, then the PITR has no way to reach them 
(sending the packets back out will loop them back.)  So it MUST avoid 
doing that.
And, before you claim we should say taht, the only thing these documents 
authorize a PITR to advertise are EID prefixes.  If it is doing 
anything, it is operating outside of the documents.

Yours,
Joel

On 5/20/2011 2:56 PM, Noel Chiappa wrote:
>      >  From: Yakov Rekhter<[email-masked]>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 07:20:03 -0700

Joel,

> anything, it is operating outside of the documents.

So, a PITR may advertise an EID prefix only if *all* the addresses
covered by this prefix are used as EIDs (and none are used as RLOCs). 
Correct ?

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 23 May 2011 07:13:38 -0700

Noel,

> 10.128/16 into the ALT so that LISP-only nodes(s) can get packets to external

The latter - PETR.

> destinations covered by a PETR directly.

And LISP sites will send traffic to the destinations covered by a PETR
via that PETR.

> especially early on when there aren't many. 

So, you agreed with the point.

Yakov.

> As the number of PITRs and PETRs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 23 May 2011 10:30:00 -0400

The first half is almost correct.  It may only advertise the prefix if 
the prefix is for EIDs, or are unused at all (unlikely in the IPv4 case, 
quite possible in the IPv6 case).
Given BGP longest match, there is no problem if some of those EID blocks 
are also advertised as RLOCs.  Both paths work.  And the BGP 
advertisement of the EID as an RLOC will continue to funciton as the 
advertiser intends.  (We want to get away from that, but it is one of 
the transition techniques.)

Yours,
Joel