Re: 6PE-Alt

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

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
> > >
> >
>