[mpls] draft-bishnoi-mpls-mldp-opaque-types-01.txt and figuring out all these types ..
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[mpls] draft-bishnoi-mpls-mldp-opaque-types-01.txt and figuring out all these types ..



Sandeep,

As I mentioned in the meting here are the many versions of these things :

sec 5 in draft-ietf-mpls-ldp-upstream-04.txt quotes an RFC3472 TLV which
is defined in sec
8.1.1. in RFC3472. This rfc defines an interface ID TLV , and 3471
defines an interface ID.

In draft-jounay-niger-pwe3-source-initiated-p2mp-pw-03.txt it quotes
draft-ietf-mpls-ldp-upstream-04.txt .

Then we have draft-martini-pwe3-p2mp-pw-01.txt , which is the merge of
the draft-Journay-niger , and draft-martini-pwe3-p2mp-pw-00.txt ,and I
have yet another definition of the LSP identifier , which comes from the
L3VPN draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt document. ( this is
going to be changed in the next version)

ok, Now I'm really confused !
:-)

The problem:
We are looking at somehow identifying an P2MP or M2MP LSP.

I would like to state that the specific encoding is trivial, as long as
we can get a unique ID we can all agree on.

I do not agree that we MUST not share the LSP. If there are applications
that are all going to the same locations, I do not see why we cannot
share the tree.

Why are we attempting to centralize the definition of these LDP LSP
identifiers ?

Maybe we just need a simple document defining an IANA registry, and
rules to get assignments from it .
This is very similar to the PW AII definitions, and history shows us
that a simple registry is a good way to solve this problem.

Luca






Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.