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

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

On 24.11.2010 15:48, Jeffrey (Zhaohui) Zhang wrote:
> Peter,
>
> Please see inline.
>
>> -----Original Message-----
>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>> Sent: Tuesday, November 23, 2010 2:14 PM
>> To: Jeffrey (Zhaohui) Zhang
>> Cc: ospf@ietf.org
>> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
>>
>> Hi Jeffrey,
>>
>> please see inline:
>>
>> On 23.11.2010 19:29, Jeffrey (Zhaohui) Zhang wrote:
>>> 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.
>>
>> 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.
>
> 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?
>>
>> yes, some form of a sub-interface using the VLAN technology. That is
>> typically a p2p connection between the two OSPF speakers.
>
> 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
>
>>
>> thanks,
>> Peter
>>>
>>> Thanks.
>>> Jeffrey
>>>
>>>> -----Original Message-----
>>>> From: Peter Psenak [mailto:ppsenak@cisco.com]
>>>> Sent: Tuesday, November 23, 2010 1:11 PM
>>>> To: Jeffrey (Zhaohui) Zhang
>>>> Cc: ospf@ietf.org
>>>> Subject: Re: [OSPF] OSPF Hybrid Broadcast and P2MP Interface Type
>>>>
>>>> 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
>>>>
>>>> On 22.11.2010 17:36, Jeffrey (Zhaohui) Zhang 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
>>>>> OSPF@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>
>>>>
>>>>
>>>
>>
>>
>