Hi Paul, I missed this email when it was sent, I was traveling at the time. I just reviewed mailing list traffic now, and saw this was unanswered. Please see inline below:
On 10/28/12 16:35, Paul Vinciguerra wrote: > > As I read section 4.2, I’d like to point out two issues that could > simplify/optimize deployment : > > P-ETRs can be deployed by ISPs wishing to offer value-added services > > to their customers. As is the case with P-ITRs, P-ETRs too may > > introduce path stretch. Because of this the ISP needs to consider > > the tradeoff of using several devices, close to the customers, to > > minimize it, or few devices, farther away from the customers, > > minimizing cost instead. > > We see this in practice as well. Much more of the traffic path winds > up on the EID side. (All the non-LISP prefixes are EID’s to a PeTR, > yes?) This minimizes the amount of time that packets are encapsulated > between RLOCS. I see a need for traffic engineering where PeTR’s could > advertise prefixes into the mapping system (with some kind of > no-export tag into the DDT). Our specific use would be to egress > traffic at our peering points where we directly connect to the endpoint. > This is a very interesting optimization, which may reduce path strech even with a relatively low number of deployed PxTRs. How about configuring source based replies in the DDT, instead of the "no-export"? This could be an easier way to accomplish the same goal, and we can keep P-ETRs simple, without the need to send Map-Registers. The ETRs of the site would register the P-ETR RLOCs for queries coming from P-ITRs from peers. I like the source based approach better, because there are other use cases already for LISP, when a source based reply may be necessary. > If the encapsulated path were longer, the intermediary providers would > also see empirical evidence of LISP running on their networks, as the > packets would be UDP/4342. Once the packet passes through the PeTR, > it’s just a regular packet again. This process should happen as close > to the endpoints as possible. This suggests that as a best practice, > anycast addresses should not be used for PeTR addresses, because > anycast addresses minimize the encapsulated path. > I will incorporate this suggestion into the document, thanks! > As a security measure, access to P-ETRs should be limited to > legitimate users by enforcing ACLs. > > > In practice, this is hard to do. It is hard to do with outer header source > addresses if you support DHCP based RLOCs. > Likewise, ACL’s on the inner header source addresses help against theft of > service, but packets with IP options set can move the fixed offset of the > inner header source address and make using ACL’s a challenge. > With ACL’s, limiting legitimate users would imply matching the proper pairing > of both inner and outer header source addresses at a minimum. An alternative > approach would be valuable as suggested in the interworking document. > > A Proxy-ETR should verify the (inner) source EID of the packet at > time of decapsulation in order to verify that this is from a > configured LISP site. This is to prevent spoofed inner sources from > being encapsulated through the Proxy-ETR. Ok, in that case we will remove this recommendation. -Lori > > Paul _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
