Subject: [mpls] Re: Some questions about draft-ietf-mpls-ldp-p2mp-01, thank you!

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 3 Jul 2006 11:27:00 +0200

Hi,

>
> 2.3.1.1.  Determining one's 'upstream LSR'
>
>    A node Z that is part of P2MP LSP <X, Y> determines the LDP peer U
>    which lies on the best path from Z to the root node X. If there are
>    more than one such LDP peers, only one of them is picked.  U is Z's
>    "Upstream LSR" for <X, Y>.
>
> Which is the "best path" for Z. Two ways can determine the best path.
> 1. Z can look up the normal "route table", and get the best path  
> according the route.(The route table may be generated by OSPF, ISIS,  
> RIP, or even OSPF-TE)
>
> 2. Z can get the best path according the multicast table (this table  
> may be generated by various multicast routing protocols), and the P2MP  
> LSP or MP2MP LSP will only work on the routers that support  
> corresponding multicast routing protocols.

Can you give an example of a multicast routing protocol that populates  
such a table?

>
> The two ways are not compatiable, and the two P2MP LSPs or MP2MP LSPs  
> are defferent. Maybe this draft should describe the two ways, and  
> specify one way or both the two ways. The best path selection problem  
> should be solved.

Are you suggesting we should set priority to one table over the other?

It looks to me that the table selection is a local policy and does not  
necessarily need to be the same on each LSR. You may want to use a  
MuRIB between 2 LSRs just to make Multicast divert from Unicast for a  
specific link. How these two tables are used is up to the operator to  
define. It does not seems to be something the draft must spell out. So  
I think this is out side the scope of the document.

Thx,

Ice.

>
>
>
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail 
>  is solely property of the sender's organization. This mail communicati 
> on is confidential. Recipients named above are obligated to maintain se 
> crecy and are not permitted to disclose the contents of this communicat 
> ion to others.
> This email and any files transmitted with it are confidential and inten 
> ded solely for the use of the individual or entity to whom they are add 
> ressed. If you have received this email in error please notify the orig 
> inator of the message. Any views expressed in this message are those of 
>  the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti- 
> Spam system.

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

---

From: [email-masked]
Date: Mon, 3 Jul 2006 11:16:38 +0800

Which is the "best path" for Z. Two ways can determine the best path.
1. Z can look up the normal "route table", and get the best path according 
the route.(The route table may be generated by OSPF, ISIS, RIP, or even 
OSPF-TE)

2. Z can get the best path according the multicast table (this table may 
be generated by various multicast routing protocols), and the P2MP LSP or 
MP2MP LSP will only work on the routers that support corresponding 
multicast routing protocols.

The two ways are not compatiable, and the two P2MP LSPs or MP2MP LSPs are 
defferent. Maybe this draft should describe the two ways, and specify one 
way or both the two ways. The best path selection problem should be 
solved.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Thomas Morin <[email-masked]>
Date: Tue, 11 Jul 2006 10:00:08 -0400

Hi Ice,

IJsbrand Wijnands :
> define. It does not seems to be something the draft must spell out.

I don't think that the above is exact: to ensure no routing loop is
created, consistency between SPF calculated by different routers is
needed.

If, for instance, a multi-topology IGP is used, then we may want to say
that all routers should use the same topology to lookup upstream
interface to LSP root. 

We could say for instance that multicast topology MUST be used if
multi-topology ISIS is used (or an alternate new multi-topology topology
ID, if we don't like reusing the one dedicated to IP multicast).

Cheers,

-Thomas

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 11 Jul 2006 16:56:29 +0200

Hi Thomas,

> that all routers should use the same topology to lookup upstream

I agree that with a multi-topology IGP it is the most obvious way to 
build your tree. But it is still possible to only run a multi-topology 
in a sub section of the network where you have specific needs to do so. 
I don't think it is up the mLDP draft to limit the scope.

> ID, if we don't like reusing the one dedicated to IP multicast).

I see multi-topology IGP as different unicast tables. These tables 
represent different topologies where you may want to pick one for mLDP 
build trees. If we don't want to call one the multicast IGP, how do you 
want to define this in the draft?

Thx,

Ice.

---

From: Thomas Morin <[email-masked]>
Date: Tue, 11 Jul 2006 11:07:13 -0400

> in a sub section of the network where you have specific needs to do so. 

True, there are topologies that will be loop free guaranteed even if MT
is not run everywhere. 

> I don't think it is up the mLDP draft to limit the scope.

I agree.

> want to define this in the draft?

The draft might include some "warning" statement against
misconfiguration, but probably the one included in
draft-ietf-isis-wg-multi-topology, Section 6, is enough ("The nexthops
derived from the MT SPF MUST belong to the adjacencies conforming to the
same MT for correct forwarding. It is recommended for the administrators
to ensure consistent configuration of all routers in the domain to
prevent undesirable forwarding behavior.")

Cheers,

-Thomas