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