Re: 6PE-Alt

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

Hi Francois,

From your very mail it clearly shows that 6PE-Alt is already
inter-operable. It also shows that because of the cumbersome
extensions you made, you actually had to go through some
interoperability tests too specifically to gain this functionality.

You bring up some other interesting points. The first one is that the
current code can anyway work with the "Explicit NULL label" which
clearly means that solution works fine and has been interoperated. It
also clearly means that using 6PE-Alt mechanism without all the
additional signaling extensions defined in 6PE the solution could
work. This also clearly means it has been added to aid some particular
implementation, so that a part of the code which may be harder to
change (it seems label allocation scheme) is not done, instead a whole
new extension is burdened on all the other vendors.

The question again is just to gain one less IPv6 lookup, for some
applications for some cases, you have defined a whole gamut of new
signaling extensions. And yes the IPv6 lookup is not saved in all the
cases either.

I would really like to raise the question to the working group, if
they think we should allow protocol extensions which are not required,
and can be done without, but are made so that other implementations
have to do the same. Trust me it would have been simpler to just fix
the label allocation schemes in implementations than to burden the
whole IETF with cumbersome extensions.

Thanks,
Vishwas

On Feb 1, 2008 1:38 AM, Francois Le Faucheur IMAP <flefauch@cisco.com> wrote:
>
>
> On 1 Feb 2008, at 00:41, DE CLERCQ Jeremy wrote:
>
>
> So the question remains whether the possible benefits of this solution
> justify bringing another alternative approach solving the same problem
> into the standards.
>
> Supporting different label allocation schemes (eg Explicit-Null and
> per-prefix-label so IPv6 traffic is label switched) was an explicit goal of
> the 6PE work. The solution has been specified to achieve that flexibility
> and corresponding interoperability validated.
>
> One can always come up with point solutions that are somewhat leaner if you
> sacrifice flexibility. In this case, I personally don't see that the
> trade-offs of 6PE-Alt justify revisiting the current solution to either add
> a restriction on label-allocation (that we explicitly rejected before), or
> add an extra option that will only make overall interoperability more
> difficult.
>
> Francois
>
>
>
>
> Regards,
> Jeremy.
>
>
>
> Hi Jeremy,
>
> I agree a single level of label should not be used. The 6PE RFC
> clearly talks about reasons for the same in great detail.
>
> That option should not be used and I agree to it. However the 6PE-Alt
> approach uses 2 level of labels. The inner label is the Explicit NULL
> label and the outer label is the tunnel label which gets the packet
> from one 6Pe router to the other. The document below clearly misses
> the idea of using a predefined label as the tunnel label.
>
> I hope things are clearer now to you.
>
> Thanks,
> Vishwas
>
> On Jan 31, 2008 2:07 PM, DE CLERCQ Jeremy
> <jeremy.de_clercq@alcatel-lucent.be> wrote:
> Hi Vishwas,
>
> I was refering to e.g. section 6.2 in
> draft-ietf-ngtrans-bgp-tunnel-02.txt, where it says
>
> "
> Where a single level of label is used and no label are advertised by
> MP-BGP, the SAFI used in MP-BGP will be one of the basic values:
> unicast, multicast or both (1,2 or 3).
> "
>
> With regards to the reason why the labelled approach was finally
> selected: it had to do on one hand with the main
> applicability of the
> approach for routers that typically do labelled BGP distribution for
> VPNs, and on the other hand with the fact that the
> advantages of using
> labelled distribution seemed to outweigh the disadvantages
> like memory
> requirements etc.
>
> With regards to interoperability, what I meant was that it
> was deemed
> better to have not too many optional and alternative
> solutions in one
> RFC and to limit it to the chosen approach.
>
> Regards,
> Jeremy.
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>