Dino,
I am not convinced that draft-farinacci-lisp-te provides a superset of the
functionality provided by MPLS-TE. A more accurate statement would be to say
that it provides a partially overlapping set of functionality.
That said, I think that it is possible to avoid the entire argument not using
the words "Traffic Engineering". A better approach would be to describe what
LISP offers in this area, explicitly, in a few paragraphs.
Ron
> -----Original Message-----
> From: Dino Farinacci [mailto:[email protected]]
> Sent: Monday, August 11, 2014 12:00 PM
> To: Ronald Bonica
> Cc: Albert Cabellos; LISP mailing list list
> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1)
>
>
> > Hi Albert,
> >
> > LISP solves one part of the TE problem. That is, it allows the ITR to choose
> the ETR through which traffic enters the destination LISP site. However, it
> doesn't determine the path that traffic takes between IETR and ETR. So, it
> that sense, LISP TE is different from traffic engineering with MPLS.
>
> Read draft-farinacci-lisp-te Ron. A path CAN be chosen. And it is a super-set
> of functionality that MPLS-TE provides.
>
> > Also, I am not sure that it is *always* a good idea to let the ITR choose
> > the
> ETR through which traffic enters the destination LISP site. A discussion of
> when this is and isn't a good idea might be appropriate in the intro
> document.
>
> The intro document should not be subjective. We should have learned from
> previous mistakes on this topic.
>
> Dino
>
> >
> > Ron
> >
> >>> - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same
> >> sense that MPLS does. It's quite different.
> >>>
> >>
> >> RFC6830 states that LISP offers TE.
> >>
> >
> > _______________________________________________
> > lisp mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
