Peter, I'll fix the contradiction, and add that the new Sub-TLV only applies to link-type 2.
Thanks a lot for your suggestions, review and commnets! Jeffrey > -----Original Message----- > From: Peter Psenak [mailto:[email protected]] > Sent: Monday, October 06, 2014 9:02 AM > To: Jeffrey (Zhaohui) Zhang; [email protected] > Cc: [email protected]; [email protected]; tom.mcmillan@l- > 3com.com; Lili Wang > Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part- > metric > > 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:[email protected]] > >> Sent: Friday, October 03, 2014 8:18 AM > >> To: Jeffrey (Zhaohui) Zhang; [email protected] > >> Cc: [email protected]; [email protected]; 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:[email protected]] > >>>> Sent: Friday, October 03, 2014 7:37 AM > >>>> To: Jeffrey (Zhaohui) Zhang; [email protected] > >>>> Cc: [email protected]; [email protected]; 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:[email protected]] > >>>>>> Sent: Monday, July 21, 2014 5:00 PM > >>>>>> To: Jeffrey (Zhaohui) Zhang; [email protected] > >>>>>> Cc: [email protected]; [email protected]; > 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 > >>>>>>> [email protected] > >>>>>>> https://www.ietf.org/mailman/listinfo/ospf > >>>>>>> > >>>>> > >>>>> . > >>>>> > >>> > >>> . > >>> > > > > . > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
