Subject: Re: [mpls] mpls Digest, Vol 60, Issue 7

From: "Jin, Lizhong (NSN - CN/Shanghai)" <[email-masked]>
Date: Mon, 20 Apr 2009 10:24:01 +0800

Hi Ice:
Leaf status notification for mLDP is still valuable for P2MP PW
multiplexing/demultiplexing. Although we can use other signaling to do
the mLDP leaf auto-discovery, it is not a perfect solution as we
discussed before.

Best Regards
Lizhong Jin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext [email-masked]
Sent: Saturday, April 18, 2009 3:00
To: [email-masked]
Subject: mpls Digest, Vol 60, Issue 7

Send mpls mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/mpls
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mpls digest..."

Today's Topics:

   1. Re: LDP P2MP draft status (IJsbrand Wijnands)
   2. Re: LDP P2MP draft status (BISHNOI Sandeep)

----------------------------------------------------------------------

Message: 1
Date: Fri, 17 Apr 2009 14:22:34 +0200
From: IJsbrand Wijnands <[email-masked]>
Subject: Re: [mpls] LDP P2MP draft status
To: BISHNOI Sandeep <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

Sandeep,

>
>
> Ina/IJsbrand and all,
>
> Please revive the ldp-p2mp draft as it expired a while ago.

Thx for the reminder.

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

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?

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

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

Yes.

Thx,

Ice.

------------------------------

Message: 2
Date: Fri, 17 Apr 2009 12:24:40 -0500
From: "BISHNOI Sandeep" <[email-masked]>
Subject: Re: [mpls] LDP P2MP draft status
To: "IJsbrand Wijnands" <[email-masked]>
Cc: [email-masked]
Message-ID:
	
<[email-masked]
	
Content-Type: text/plain;	charset="us-ascii"

Thanks for a prompt reply.

SB> Please see inline.

Sandeep,

>
>
> Ina/IJsbrand and all,
>
> Please revive the ldp-p2mp draft as it expired a while ago.

Thx for the reminder.

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

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?

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.

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

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

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. 

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

Yes.

Thx,

Ice.

------------------------------

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

End of mpls Digest, Vol 60, Issue 7
***********************************