Subject: [mpls] LDP P2MP draft status

From: "BISHNOI Sandeep" <[email-masked]>
Date: Thu, 16 Apr 2009 13:34:19 -0500

Ina/IJsbrand and all, 

Please revive the ldp-p2mp draft as it expired a while ago.

Few comments:
- Currently a single method of provisioning a p2mp tree is provided
(section 2.3.1 - The Generic LSP Identifier). With multiple client
applications we may run into issues that may require multiple identifier
spaces defined. I would suggest separating out identifier space by
client application (similar to FEC 128/129). Current Generic LSP
identifier may be reserved for static provision and in future each
client application may define its own standard identifier format.
- Leaf status notification from a branch node to the root node must be
defined. As the protocol is leaf initiated, there is no provision to
inform the root node or a leaf node of failure in allocation of
resources on an intermediate LSR node.
- IANA is yet to assign TLV identifiers. Please include them in next
version.

Thanks,
Sandeep

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 17 Apr 2009 14:22:34 +0200

Sandeep,

> Please revive the ldp-p2mp draft as it expired a while ago.

Thx for the reminder.

> client application may define its own standard identifier format.

So you are you suggesting to use the current Generic LSP identifier  
for static provisioning and define new opaque encodings for each  
application using mLDP. Each application can manage its own LSP  
identifier space. Is that right? Or do you want to carve up the  
Generic LSP identifier space in order to do that?

> resources on an intermediate LSR node.

What is the advantage of doing that? Does the root node need to take  
action on that information? Or is this purely informational?

> - IANA is yet to assign TLV identifiers. Please include them in next

Yes.

Thx,

Ice.

---

From: "BISHNOI Sandeep" <[email-masked]>
Date: Fri, 17 Apr 2009 12:24:40 -0500

Thanks for a prompt reply.

SB> Please see inline.

Sandeep,

Thx for the reminder.

SB> Correct. Carving up generic LSP identifier would probably not the
best option. Let the identifier be an opaque value/format based on
client application.

SB> As per the current defined behavior, the root node would have no
information on number successful leaf nodes connected to the tree.
Though lot of native IP multicast protocols work like that but now with
other means possible to have better connectivity, the root node may
choose to fallback on other available transport methods (e.g. RSVP
P2MP). Action on failure information is local decision but we should
probably have an optional method defined to propagate notifications to
the root node. 

Yes.

Thx,

Ice.