> On 20 Apr 2015, at 17:34, Dino Farinacci <[email protected]> wrote: > > >> Hi, >> >>>> specifications. The existence of a LISP specific EID block >>>> would allow to avoid scenarios with excessive overhead, where >>>> the destination is a LISP EID and where (while the mapping is >>>> looked up) packets are forwarded over paths like >>>> Source->ITR->PETR->PITR->ETR->Destination, which may show an >>> >>> This is totally wrong. PITR, by definition, are not decapsulators. >> >> The example is correct, and the PITR in the example is an encapsulator. The >> ITR->PETR bit is encapsulated. The PETR->PITR bit is unencapsulated >> (probably BGP routed) internet traffic, and the PITR->ETR bit is >> encapsulated again. > > Then the example is not coded properly. It nees to be more specific for > accuracy: > > source (native forward) -> ITR (encap) -> PETR (native forward) -> PITR > (encap) -> ETR (native forward) -> dest
I would suggest: source -> ITR (encap) -> PETR (recap) -> (native forward) -> PITR (encap) -> ETR (decap) -> dest Because of the current status of the document (and as co-author) this can be done during the IESG review or right before forwarding it to the RFC queue if no other changes are required. ciao L. > > Dino > >> >> Cheers! >> Sander >> > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
