Hi Brian,
I thank you and Erik for your feedback. It is important for making
progress on the draft.
It seems that my perspective on the source routed tunnel comes from an
angle that needs to be clarified. As I understand it, the role of the
bi-directional tunneling draft is to describe/define mechanisms, and
give one or several examples of their use.
Traffic engineering is a darling to network operators. In a pure IP
network, a network manager alleviates traffic bottle-necks, by
redirecting certain flows of traffic away from congested dynamically
routed IP paths. This can be or is done by way of creating tunnels that
are pinned to sets of nodes distinct from those that are part of the
optimal paths chosen by dynamic routing. The pinning of routes is done
through source routing. So, source routed tunnels is a valuable
mechanism. Furthermore, it is or can be used for many other purposes
besides the traffic engineering just mentioned.
Erik mentioned MPLS. For clarification, and to make sure we are on a
common ground, it is true that MPLS is well suited for traffic
engineering, but traffic engineering can be done and it is done
in pure IP networks independent of MPLS, as I gave an example above.
In my view, source routed, or path pinned tunnels (whatever one wants to
call them), including bi-directional source routed tunnels would be part
of the description/defining of the set of mechanisms and examples of
their use, which is the role of a specification. Therefore, I believe
that in fact the draft is currently missing the mentioning or an
adequate documentation of source routed tunnels (unidirectional). By
adding such a documentation on uni-directional source routing, the
section on symmetric bi-directional tunnel would fall better in its
place as a bi-directional source routed tunnel.
What seems to make sense to me is to question whether the text on source
routed tunnels be considered mechanisms or examples? If it was
considered mechanism would it be mandatory? No, I think. I think it
would be a SHOULD, or MAY, even though for routers it is very useful.
Perhaps such clarification in the draft would help?
In light of this, I am confused by the suggestion of removing the
symmetrical bi-directional tunnels, and more clarification would help.
Thanks,
Alex
Brian Zill wrote:
>
> Hi Alex,
>
> I agree completely with Erik here, and heard much the same from others
> present at the meeting.
>
> --Brian
>
> > From: Erik Nordmark [mailto:[EMAIL PROTECTED]]
> >
> > Alex,
> >
> > I really really don't see the need for what the draft
> > calls "symmetric bi-directional tunnels".
> >
> > While such constructs might be used in the traffic
> > engineering context the TE context comes with a control
> > protocol (MPLS) for setting up the explicit paths and
> > recovering from failure. Getting MPLS to control
> > IPv6-in-IPv6 tunnels would be a huge exercise of very
> > questionable value.
> >
> > Thus my personal opinion is that the draft should only
> > specify "regular" bi-directional tunnels.
> >
> > Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
