Re: 6PE-Alt

["Vishwas Manral" <vishwas.ietf@gmail.com>]

Hi Jeremy,

I did look at the draft-ietf-ngtrans-bgp-tunnel-02.txt. I could not
find a mention of the mechanism I have mentioned. Could you please
point me to the place where the mechanism is mentioned?

BTW, the simple mechanism you talk about, adds a AFI/ SAFI pair to
BGP, unnecessarily passes labels around which are not used at all. It
increases the memory requirement of each route, increases the size of
the serach key and has complicated Transit provider mechanisms. It in
turn clutters the forwarding tables with data which could be easily
done without. The interesting part is the same could be done without
any extensions at all.

You seem to say that due to some interoperability concerns you added
the mechanism to explicitly signal labels, which serve no purpose. Can
you let me know which implementations had interoperability concerns?
It would be great if you can give a more exact technical reason of why
the approach we intend to bring to the IETF (which by default is
inter-operable - as no extensions are required). It is hard to for a
person who has not been through the entire history to understand the
same.

Thanks,
Vishwas

On Jan 31, 2008 12:56 PM, DE CLERCQ Jeremy
<jeremy.de_clercq@alcatel-lucent.be> wrote:
> Hi Vishwas,
>
> > I however am surprised how
> > this simple mechanism was not captured earlier in the review or coding
> > process.
>
> The work that lead to what is now known as 6PE has seen many forms and
> many many iterations. Including approaches without label signaling and
> allocation, even including approaches without MPLS. You should be able
> to find out about this history via earlier versions of the draft like
> draft-nguyen-ngtrans-bgp-tunnel-00.txt and
> draft-ietf-ngtrans-bgp-tunnel-02.txt.
>
> So I'd say that this simple mechanism was captured earlier but that it
> has been decided not to retain it, and to keep only one mandatory
> procedure for interoperability purposes.
>
> At the end it was working group consensus and interoperable
> implementations that lead to the current 6PE approach.
>
> Regards,
> Jeremy
>