Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric

[Peter Psenak <[e-mail]>]

Hi Jeffrey,

understood and the encoding in the draft looks good then.

I would propose to mention that the new Sub-TLV only applies to 
link-type 2 (Connection to a transit network) and MUST be ignored for 
other link types.


Section 3 says:

                              "This document does not currently specify
    a way to detect a router's capability of supporting this, and relies
    on operator's due diligence in provisioning.  A protocol mechanism
    may be developer in the future."

Contrary, section 3.5 defines a mechanism to detect the

   "Upon detecting the presence of a reachable Router LSA without a
    companion RI LSA that has the bit set, all routers MUST disable the
    two-part metric functionalities"

thanks,
Peter


On 10/3/14 14:28 , Jeffrey (Zhaohui) Zhang wrote:
> Peter,
>
> For the DR to learn different cost to different neighbors from the network (not from the DR), it may be difficult or may require some out of band mechanism. If the out of band mechanism is available, I would also prefer to do so - and that was indeed in revision -02 as an further optimization. It was removed per Acee's comment.
>
> Thanks.
> Jeffrey
>
>> -----Original Message-----
>> From: Peter Psenak [mailto:[e-mail]]
>> Sent: Friday, October 03, 2014 8:18 AM
>> To: Jeffrey (Zhaohui) Zhang; [e-mail]
>> Cc: [e-mail]; [e-mail]; tom.mcmillan@l-
>> 3com.com; Lili Wang
>> Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-
>> metric
>>
>> Hi Jeffrey,
>>
>> On 10/3/14 13:54 , Jeffrey (Zhaohui) Zhang wrote:
>>> Peter,
>>>
>>> Let's say we have router A on the network. The metric from the network
>> to A is encoded in router A's own extended LSA, so no neighbor
>> information is needed. You can imagine that it is AS IF the metric was
>> encoded next to the normal to-network metric side by side.
>>
>>         Router A (DR)
>>            |
>> ----------------------
>>      |          |
>> Router B   Router C
>>
>> - what you are trying to solve is the lack of metric in A->B and A->C
>> direction
>>
>> - the natural choice would be for A (DR) to advertise a metric for each
>> adjacent neighbor. Why do you prefer to advertise the reverse metric
>> from B and C instead?
>>
>> thanks,
>> Peter
>>
>>>
>>> We did consider to optionally encode that in the extended network LSA
>> for OSPFv3, so that if the underlying network has the ability for the DR
>> to learn the from-network metric for each neighbor, then it'll be able
>> encode those metrics in the network LSA, further reducing the churning
>> when an affect-all event happens. That was in -02, but it was deemed too
>> dependent on the underlying network (to let the DR know those metrics)
>> and deviating from the normal OSPF, so it was take out.
>>>
>>> Thanks.
>>> Jeffrey
>>>
>>>> -----Original Message-----
>>>> From: Peter Psenak [mailto:[e-mail]]
>>>> Sent: Friday, October 03, 2014 7:37 AM
>>>> To: Jeffrey (Zhaohui) Zhang; [e-mail]
>>>> Cc: [e-mail]; [e-mail]; tom.mcmillan@l-
>>>> 3com.com; Lili Wang
>>>> Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-
>> part-
>>>> metric
>>>>
>>>> Jeffrey,
>>>>
>>>> the encoding you proposed would not work.
>>>>
>>>> OSPFv2:
>>>>
>>>> - you added Network-to-Router Metric Sub-TLV in Extended Link TLV,
>> but
>>>> Extended Link TLV does not have any neighbor identification. Please
>> look
>>>> at LAN Adj-SID Sub-TLV defined in
>>>> draft-ietf-ospf-segment-routing-extensions - you need something
>> similar.
>>>>
>>>> OSPFv3:
>>>>
>>>> - you added Network-to-Router Metric Sub-TLV to Router-Link TLV of
>>>> E-Router-LSA. That is not the right place. You should put the metric
>>>> from DR to neighbors inside OSPFv3 E-Network-LSA and include neighbor
>>>> identifier in it.
>>>>
>>>> thanks,
>>>> Peter
>>>>
>>>>
>>>> On 10/2/14 20:42 , Jeffrey (Zhaohui) Zhang wrote:
>>>>> Peter, and all,
>>>>>
>>>>> I have posted a new revision, which uses the following to encode the
>>>> from-network metric.
>>>>>
>>>>>> 1. OSPFv2: Extended Link LSA
>>>>>> 2. OSPFv3: E-Router LSAs
>>>>>
>>>>> http://www.ietf.org/id/draft-zzhang-ospf-two-part-metric-03.txt
>>>>>
>>>>> Please review and comment.
>>>>>
>>>>> Thanks!
>>>>> Jeffrey
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Peter Psenak [mailto:[e-mail]]
>>>>>> Sent: Monday, July 21, 2014 5:00 PM
>>>>>> To: Jeffrey (Zhaohui) Zhang; [e-mail]
>>>>>> Cc: [e-mail]; [e-mail]; tom.mcmillan@l-
>>>>>> 3com.com
>>>>>> Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-
>>>> part-
>>>>>> metric
>>>>>>
>>>>>> Hi Jeffrey,
>>>>>>
>>>>>> please see inline:
>>>>>>
>>>>>>
>>>>>> On 7/21/14 15:24 , Jeffrey (Zhaohui) Zhang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> In today's OSPF session there were mainly two questions/comments
>>>>>> during my presentation:
>>>>>>>
>>>>>>> 1. Acee: more discussion on mailing list about whether this is a
>>>>>> general problem/solution that the WG should be taking on
>>>>>>> 2. Peter: should we use OSPFv3 Extended LSA for a cleaner encoding
>>>>>>
>>>>>> my comment was not specific to OSPFv3.
>>>>>> I propose to use following extensions to encode metric from DR to
>>>>>> attached router:
>>>>>>
>>>>>> 1. OSPFv2: Extended Link LSA
>>>>>> 2. OSPFv3: E-Router LSAs
>>>>>>
>>>>>>>
>>>>>>> I want to repeat and add some comments/answers here as a starting
>>>>>> point for more discussions on the mailing list.
>>>>>>>
>>>>>>> For #1:
>>>>>>>
>>>>>>> - The described problem is real for some large scale and mission
>>>>>> critical networks
>>>>>>> - The problem and solution are not only applicable to the above
>>>>>> mentioned example network, but also general to any broadcast
>> network
>>>>>> that have different costs between different pair of routers. As
>> long
>>>> as
>>>>>> the router-to-router costs can be presented as a to-network and a
>>>> from-
>>>>>> network part, then the simple solution applies
>>>>>>> - The two-part-metric concept is a natural extension of the SPF
>>>> graph
>>>>>> theory - we're just changing the previously zero from-network cost
>> to
>>>>>> none-zero.
>>>>>>>
>>>>>>> For #2, there are pros and cons with each approach.
>>>>>>>
>>>>>>> - The stub-link based approach does not depend on the in-progress
>>>> LSA
>>>>>> Extensibility work. This has larger impact on implementation - the
>>>>>> feature can be supported w/o big changes to support extended LSA
>>>> format.
>>>>>>
>>>>>> though the stub-link approach is simpler to implement, it's a bit
>> of
>>>> a
>>>>>> "hack", as you are using a standard encoding for a stub link to
>>>>>> advertise a metric for a neighbor on a broadcast link.
>>>>>>
>>>>>>> - The LSA Extensibility work is only applicable for OSPFv3. That
>>>> means
>>>>>> OSPFv2 would need a different approach for the problem. Acee also
>>>>>> mentioned that it would be good to have consistent approaches
>> between
>>>>>> OSPFv2 and OSPFv3.
>>>>>>
>>>>>> what I proposed is consistent - uses new extended LSAs in both
>> OSPFv2
>>>>>> and OSPFv3.
>>>>>>
>>>>>> thanks,
>>>>>> Peter
>>>>>>
>>>>>>> - As a result at this time we would prefer the stub-link approach.
>>>>>>>
>>>>>>> The authors would like to hear more of your opinions/suggestions.
>>>>>> Hopefully we can reach consensus on the applicability of the
>> problem
>>>> &
>>>>>> solution so that it can become a WG item, and choose the best
>>>> encoding
>>>>>> approach.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Jeffrey
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OSPF mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/ospf
>>>>>>>
>>>>>
>>>>> .
>>>>>
>>>
>>> .
>>>
>
> .
>