On 4/21/15 6:00 AM, Luigi Iannone wrote: > >> 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.
The EID-block draft is in IETF Last Call, so you could consider the above discussion a LC comment on it. Brian > > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
