Subject: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 22 Nov 2010 11:36:24 -0500

Hi,

I presented the draft http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt in Beijing (slides http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it was deferred to the mailing list on whether the problem is worth the working group effort (some who reviewed the draft agreed that the proposed solution is reasonable for the problem).

I'd like to request folks to review the draft/slides and voice your opinion. We developed the solution for a real network situation and would like to see that it gets consensus and standardized so that more operators/vendors can benefit from this.

Thanks.
Jeffrey

---

From: pete <[email-masked]>
Date: Mon, 22 Nov 2010 10:19:27 -0800

Hi,

There is also a case of multiple ethernet switches connected together
serially, with varying propagation delays to the routers that are connected
to one of these switches. Imagine different types of transmission
technologies in the network but still having ethernet on each end of the
links.

>From the perspective of a router connected to the nearest switch, a router
on a far end switch will have higher propagation delay than a router
connected to the same (nearest) switch, so having the ability to define a
higher OSPF metric to that far end router can become important.

Thanks,
pete

On Mon, Nov 22, 2010 at 8:36 AM, Jeffrey (Zhaohui) Zhang <[email-masked]
> wrote:

> Hi,
>
> I presented the draft
> http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt in
> Beijing (slides http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and
> it was deferred to the mailing list on whether the problem is worth the
> working group effort (some who reviewed the draft agreed that the proposed
> solution is reasonable for the problem).
>
> I'd like to request folks to review the draft/slides and voice your
> opinion. We developed the solution for a real network situation and would
> like to see that it gets consensus and standardized so that more
> operators/vendors can benefit from this.
>
> Thanks.
> Jeffrey
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 22 Nov 2010 13:36:11 -0500

Pete,

Good point on the "different types of transmission technologies".

BTW, I made a mistake for the draft link. It should be http://www.ietf.org/internet-drafts/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt

Thanks.
Jeffrey

________________________________
From: pete [mailto:[email-masked]]
Sent: Monday, November 22, 2010 1:19 PM
To: Jeffrey (Zhaohui) Zhang
Cc: [email-masked]
Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type

Hi,

There is also a case of multiple ethernet switches connected together serially, with varying propagation delays to the routers that are connected to one of these switches. Imagine different types of transmission technologies in the network but still having ethernet on each end of the links.

>From the perspective of a router connected to the nearest switch, a router on a far end switch will have higher propagation delay than a router connected to the same (nearest) switch, so having the ability to define a higher OSPF metric to that far end router can become important.

Thanks,
pete

On Mon, Nov 22, 2010 at 8:36 AM, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks.
Jeffrey
_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Peter Psenak <[email-masked]>
Date: Tue, 23 Nov 2010 19:10:37 +0100

Hi Jeffrey,

one potential issue with this approach is the possible suboptimal 
traffic path if the L3 p2p topology created as you described do not 
match the L2 forwarding topology. With large L2 domains it may be be 
nontrivial to assign L3 metric correctly so that the L2/L3 forwarding match.

One possible method to address the problem in hand is to create p2p 
connections between the routers via the L2 domain, using dedicated 
VLANs. This way the L2 forwarding is forced to match the L3 p2p topology.

thanks,
Peter

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Nov 2010 13:29:37 -0500

Peter,

I think I understand the potential issue you mentioned, but not quite clear about your solution.

The draft mentions that the metrics could be dynamically learned if the underlying network support it (in that case the l2 and l3 should match). However that is outside the scope the draft, which assumes that the metrics is obtained by some means. Indeed if it is statically configured then the operator needs to be careful.

You mentioned creating p2p l2 connections. Does that mean there will be correponding l3 p2p interfaces? If yes isn't it no longer a bcast/p2mp hybrid? If not can you elaborate?

Thanks.
Jeffrey

> -----Original Message-----
> From: Peter Psenak [mailto:[email-masked]] 
> Sent: Tuesday, November 23, 2010 1:11 PM
> http://www.ietf.org/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01
> .txt in Beijing (slides 
> http://www.ietf.org/proceedings/79/slides/ospf-9.ppt) and it 
> was deferred to the mailing list on whether the problem is 
> worth the working group effort (some who reviewed the draft 
> agreed that the proposed solution is reasonable for the problem).
> >
> > I'd like to request folks to review the draft/slides and 
> voice your opinion. We developed the solution for a real 
> network situation and would like to see that it gets 
> consensus and standardized so that more operators/vendors can 
> benefit from this.
> >
> > Thanks.
> > Jeffrey

---

From: Peter Psenak <[email-masked]>
Date: Tue, 23 Nov 2010 20:13:35 +0100

Hi Jeffrey,

please see inline:

> The draft mentions that the metrics could be dynamically learned if the underlying network support it (in that case the l2 and l3 should match). However that is outside the scope the draft, which a…

dynamically updating L3 metrics based on the L2 topology is a problem of 
it own. The consequence is that L2 network changes that mostly used to 
be hidden to the L3 now becomes propagated to the L3 network.

> You mentioned creating p2p l2 connections. Does that mean there will be correponding l3 p2p interfaces? If yes isn't it no longer a bcast/p2mp hybrid? If not can you elaborate?

yes, some form of a sub-interface using the VLAN technology. That is 
typically a p2p connection between the two OSPF speakers.

thanks,
Peter

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 24 Nov 2010 09:48:51 -0500

Peter,

Please see inline. 

> Sent: Tuesday, November 23, 2010 2:14 PM
> > The draft mentions that the metrics could be dynamically 
> learned if the underlying network support it (in that case 
> the l2 and l3 should match). However that is outside the 
> scope the draft, which assumes that the metrics is obtained 
> by some means. Indeed if it is statically configured then the 
> operator needs to be careful.
> 

If L2 network changes lead to L3 metric change, then it should not be hidden though?

I agree that the propogation of the changes needs to be rate limited, and a balance needs to be kept between routing stability and routing optimization.

Also about your original concern with l2/l3 mismatch - I don't think it is unique with this proposal. When you assign an interface metric for a regular interface (or neighbor in p2mp case) you also need to make sure that the metric reflects the l2 characteristics.

> 
> >
> > You mentioned creating p2p l2 connections. Does that mean 
> there will be correponding l3 p2p interfaces? If yes isn't it 
> no longer a bcast/p2mp hybrid? If not can you elaborate?
> 

The very purpose of the proposal is to use the hybrid interface type to avoid the inefficiency with p2p/p2mp links when it comes to adjaceny and db synchronization, while being able to advertise different metrics per neighbor.

Thanks.
Jeffrey

---

From: Peter Psenak <[email-masked]>
Date: Wed, 24 Nov 2010 19:05:58 +0100

Hi Jeffrey,

sure, the L2/L3 topology mismatch is not unique to your draft. My point 
was that representing a true broadcast network as a set of p2p links has 
a fair potential of creating such a mismatch if not done properly.

thanks,
Peter