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

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 2 Oct 2014 18:42:31 +0000

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-masked]]
> Sent: Monday, July 21, 2014 5:00 PM
> To: Jeffrey (Zhaohui) Zhang; [email-masked]
> Cc: [email-masked]; [email-masked]; 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-masked]
> > https://www.ietf.org/mailman/listinfo/ospf
> >

---

From: Peter Psenak <[email-masked]>
Date: Fri, 03 Oct 2014 13:37:22 +0200

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:
> .

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 3 Oct 2014 11:54:49 +0000

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.

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

> Sent: Friday, October 03, 2014 7:37 AM
> 3com.com; Lili Wang

---

From: Peter Psenak <[email-masked]>
Date: Fri, 03 Oct 2014 14:18:21 +0200

Hi Jeffrey,

> 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 met…

       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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 3 Oct 2014 12:28:08 +0000

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

> Sent: Friday, October 03, 2014 8:18 AM
> > 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
> 
> > 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
> >
> >>>> that have different costs between different pair of routers. As
> long
> >> as
> >>>> though the stub-link approach is simpler to implement, it's a bit
> of
> >> a
> >>>> Hopefully we can reach consensus on the applicability of the
> problem
> >> &

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 3 Oct 2014 14:21:53 +0000

Hi Guys, 
With respect to OSPFv3 Extended LSAs, the direction we have taken is to
keep the E-Network-LSA free of metrics and attributes. There are two
reasons for that: 
       1. Migration Simplicity - the E-Network-LSA remains as Network-LSA
is today advertising only the routers connecting to the pseudo-node.
       2. Size constraints - Given that the LSA-ID of the Network-LSA and
E-Network-LSA is DR¹s interface ID, we are limited to a single instance of
the Network-LSA and E-Network-LSA.

Of course, I¹d be willing to revisit the E-Network-LSA encoding, but my
opinion is that all requirements can be satisfied with sub-TLVs in the
E-Router-LSA. 

Thanks,
Acee 

On 10/3/14, 7:54 AM, "Jeffrey (Zhaohui) Zhang" <[email-masked]> 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.
>
>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

---

From: Peter Psenak <[email-masked]>
Date: Mon, 06 Oct 2014 15:02:26 +0200

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

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 6 Oct 2014 13:05:40 +0000

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

> Sent: Monday, October 06, 2014 9:02 AM
> > 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
> >
> >>>>> I have posted a new revision, which uses the following to encode
> the
> >>>> from-network metric.
> >>>>>
> >>>>>> Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-
> two-
> >>>> part-
> >>>>>> metric
> >>>>>>
> >>>>>> Hi Jeffrey,
> >>>>>>
> >>>>>> please see inline:
> >>>>>>
> >>>>>>
> >>>>>> theory - we're just changing the previously zero from-network
> cost
> >> to
> >>>>>> none-zero.
> >>>>>>>
> >>>>>>> - The stub-link based approach does not depend on the in-
> progress
> >>>> LSA

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 6 Oct 2014 16:04:34 +0000

> I'll fix the contradiction, and add that the new Sub-TLV only applies to

Revision -04 has been posted: http://tools.ietf.org/html/draft-zzhang-ospf-two-part-metric-04

Thanks!
Jeffrey