Folks,
Given Dino's response in
http://www.ietf.org/mail-archive/web/lisp/current/msg05945.html, shouldn't we
remove the entire bullet item? As Dino says, "An ITR or PITR will encapsulate
to a PETR, not when a cache miss happens but when the mapping system returns a
"forward-native" action in a Null Map-Reply (one with no locator-set)."
Ron
> -----Original Message-----
> From: lisp [mailto:[email protected]] On Behalf Of Brian Haberman
> Sent: Tuesday, April 21, 2015 8:38 AM
> To: [email protected]
> Subject: Re: [lisp] EID-Block clarification [was: VPN Leaks]
>
>
>
> 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
> >
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
