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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 06 October 2014 13:06 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F7F1A6F1E for <ospf@ietfa.amsl.com>; Mon, 6 Oct 2014 06:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.388
X-Spam-Level:
X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Mmzd5afpxQ for <ospf@ietfa.amsl.com>; Mon, 6 Oct 2014 06:06:09 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:762]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6211A6F20 for <ospf@ietf.org>; Mon, 6 Oct 2014 06:06:08 -0700 (PDT)
Received: from BY2PR05MB663.namprd05.prod.outlook.com (10.141.221.21) by BY2PR05MB254.namprd05.prod.outlook.com (10.242.41.152) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 13:05:44 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com (10.242.38.16) by BY2PR05MB663.namprd05.prod.outlook.com (10.141.221.21) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 13:05:41 +0000
Received: from BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.23]) by BY2PR05MB079.namprd05.prod.outlook.com ([169.254.8.23]) with mapi id 15.00.1044.008; Mon, 6 Oct 2014 13:05:41 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Peter Psenak <ppsenak@cisco.com>, "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric
Thread-Index: Ac+lGUvqIiqLTqfBSei7UevvhvhHhQADWYKADlJm8kAAI4XmAAAAVZRwAAEY14AAAAaHAACYY2sAAAALE8A=
Date: Mon, 6 Oct 2014 13:05:40 +0000
Message-ID: <8da4ffa36312414886b2a40e33900242@BY2PR05MB079.namprd05.prod.outlook.com>
References: <430a54c738e844e68deb26e7eaae2082@BY2PR05MB079.namprd05.prod.outlook.com> <53CD7F3F.308@cisco.com> <18267bfa69094e108546bb9812c5ee6c@BY2PR05MB079.namprd05.prod.outlook.com> <542E8A72.30209@cisco.com> <6becb8b9122147f7b5120ec5e9398762@BY2PR05MB079.namprd05.prod.outlook.com> <542E940D.2090103@cisco.com> <a9e89d8dd0754848bc2340cc86741f59@BY2PR05MB079.namprd05.prod.outlook.com> <543292E2.1090809@cisco.com>
In-Reply-To: <543292E2.1090809@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [66.129.241.13]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB663;UriScan:;
x-forefront-prvs: 03569407CC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(479174003)(41574002)(189002)(377454003)(24454002)(10300001)(108616004)(97736003)(86362001)(76482002)(101416001)(66066001)(230783001)(19580395003)(2656002)(19580405001)(20776003)(92566001)(74316001)(64706001)(40100001)(46102003)(99396003)(80022003)(31966008)(87936001)(50986999)(120916001)(95666004)(99286002)(106356001)(85306004)(105586002)(77096002)(93886004)(76176999)(33646002)(54356999)(4396001)(122556001)(21056001)(2501002)(15202345003)(76576001)(85852003)(15975445006)(107046002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB663; H:BY2PR05MB079.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB254;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/I5AVjpGcWX1RhdZ5WR0YAmK8sCE
Cc: "vibhor.julka@l-3Com.com" <vibhor.julka@l-3Com.com>, "Dave.Dubois@gdc4s.com" <Dave.Dubois@gdc4s.com>, "tom.mcmillan@l-3com.com" <tom.mcmillan@l-3com.com>
Subject: Re: [OSPF] Follow-up discussion on draft-zzhang-ospf-two-part-metric
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2014 13:06:12 -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

> -----Original Message-----
> From: Peter Psenak [mailto:ppsenak@cisco.com]
> Sent: Monday, October 06, 2014 9:02 AM
> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; 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:ppsenak@cisco.com]
> >> Sent: Friday, October 03, 2014 8:18 AM
> >> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
> >> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; 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:ppsenak@cisco.com]
> >>>> Sent: Friday, October 03, 2014 7:37 AM
> >>>> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
> >>>> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com; 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:ppsenak@cisco.com]
> >>>>>> Sent: Monday, July 21, 2014 5:00 PM
> >>>>>> To: Jeffrey (Zhaohui) Zhang; ospf@ietf.org
> >>>>>> Cc: vibhor.julka@l-3Com.com; Dave.Dubois@gdc4s.com;
> 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
> >>>>>>> OSPF@ietf.org
> >>>>>>> https://www.ietf.org/mailman/listinfo/ospf
> >>>>>>>
> >>>>>
> >>>>> .
> >>>>>
> >>>
> >>> .
> >>>
> >
> > .
> >