Re: 6PE-Alt

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

Hi Jeremy,

You are absolutely right.

This is not an alternate mechanism it is just an interesting way of
using already existing functionality BGP-IPv6 to derive the same
functionality as 6PE. We can get 6PE functionality without having to
do any different signaling at all.

It saves all the complicated mechanisms of label distribution, label
signaling, defining AFI/ SAFI and the complicated Inter-AS
distribution to achieve the same functionality. We do not need to
populate the hardware either with that many entries. I think that is
the idea of the draft.

Thanks,
Vishwas

On Jan 31, 2008 3:41 PM, DE CLERCQ Jeremy
<jeremy.de_clercq@alcatel-lucent.be> wrote:
> Hi Vishwas,
>
> Aha. Now I see; I got carried away by the discussion instead of looking
> at the draft ;).
>
> So the question remains whether the possible benefits of this solution
> justify bringing another alternative approach solving the same problem
> into the standards.
>
>
> 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
> > > > >
> > > >
> > >
> >
>