Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts

Alan Davey <Alan.Davey@metaswitch.com> Thu, 18 February 2016 11:28 UTC

Return-Path: <Alan.Davey@metaswitch.com>
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 B14521B3E26; Thu, 18 Feb 2016 03:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 3WA2GCBwR6Cg; Thu, 18 Feb 2016 03:28:22 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2F91B3E25; Thu, 18 Feb 2016 03:28:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Tp9ZV7wqbpknJQ9VrEIMf0eXhuRFUSyEt7FeRUQFHao=; b=OPg3pxsDPTPhyMGQFzp1ytzJVzMgraSpEpc8lvQTYN5hj+o5Ky+8Uyv2Cf9D/hxQSaVH9lxY4UqgHs/Gyg5QZV5ZMv/WDpkZ/dGyIWNlbNA1prjls0HpPWxmKb/cFkrPUoyaWzJmiLVW8kWASUNp8Jop+tzco0AaG+Q2YdHPCRI=
Received: from CY1PR0201MB1066.namprd02.prod.outlook.com (10.161.214.155) by CY1PR0201MB1065.namprd02.prod.outlook.com (10.161.214.154) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 18 Feb 2016 11:28:19 +0000
Received: from CY1PR0201MB1066.namprd02.prod.outlook.com ([10.161.214.155]) by CY1PR0201MB1066.namprd02.prod.outlook.com ([10.161.214.155]) with mapi id 15.01.0409.017; Thu, 18 Feb 2016 11:28:19 +0000
From: Alan Davey <Alan.Davey@metaswitch.com>
To: "Derek Man-Kit Yeung (myeung)" <myeung@cisco.com>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>
Thread-Topic: draft-ietf-ospf-yang-03 questions and doubts
Thread-Index: AdE3NLGjjtMGuql0QfiSt+s9ulh9zgoPjYmAAiVQNuA=
Date: Thu, 18 Feb 2016 11:28:19 +0000
Message-ID: <CY1PR0201MB1066110895F4C141E7779015F9AF0@CY1PR0201MB1066.namprd02.prod.outlook.com>
References: <C2EE31C852049D499842B19FC01C0804012A72782A@ENFICSMBX1.datcon.co.uk> <D2D8C451.73937%myeung@cisco.com>
In-Reply-To: <D2D8C451.73937%myeung@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=metaswitch.com;
x-originating-ip: [2620:104:4001:72:bdde:ca18:1c4a:b53e]
x-microsoft-exchange-diagnostics: 1; CY1PR0201MB1065; 5:UlpQEJGFx76fi+7FXZsivVAlXUnjAhZHnY7SeAqX7KVR2RFNS1+qEeCsxq0JM1LxDrEFVidDyWxGtRC+8oDyvGiPIX05WpV6v65n327cJemaxvZnwHuFA4uTcN4ukNhZN5KLYYv6XhF5njcmVrTJdA==; 24:JM4GFGJTuLPootc9+wk6fH14pla3mNQJKhR7uQKmuNf5TyPTl7sG7Or3dgilPic47rT6eY+IJ2nByQmkowh71STfZ9u9eq065r+oK9wPy8o=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0201MB1065;
x-ms-office365-filtering-correlation-id: fb5a6876-c98d-4d8f-056d-08d338569a17
x-microsoft-antispam-prvs: <CY1PR0201MB10651CF80C75C410C8BE8657F9AF0@CY1PR0201MB1065.namprd02.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR0201MB1065; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0201MB1065;
x-forefront-prvs: 085634EFF4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51914003)(164054003)(377454003)(92566002)(99286002)(5001960100002)(189998001)(15975445007)(74316001)(5890100001)(19625215002)(4326007)(11100500001)(50986999)(77096005)(76576001)(19300405004)(2906002)(5003600100002)(5002640100001)(76176999)(5004730100002)(54356999)(5001770100001)(33656002)(230783001)(2900100001)(86362001)(2950100001)(3660700001)(790700001)(102836003)(6116002)(10400500002)(1220700001)(19580395003)(19580405001)(1096002)(586003)(87936001)(122556002)(40100003)(5008740100001)(3280700002)(16236675004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0201MB1065; H:CY1PR0201MB1066.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0201MB1066110895F4C141E7779015F9AF0CY1PR0201MB1066_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2016 11:28:19.1508 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1065
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/uWmrDITp1COTrqVuXPxDTENEhrA>
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 18 Feb 2016 11:28:26 -0000

Hi Derek

Thank you for your response, and apologies for the delay in getting back to you.  Have you considered distinct ospfv3-interface-operation and ospfv2-interface-operation?  Or even distinct "container ospfv2" and "container ospfv3"?

There are a number of differences between the Interface Data Structure defined in RFC2328 and in RFC5340.  In particular, the following.  Do you plan to add all of these differences to the interface-operation grouping?


-          DR and BDR identification.

o   As you wrote, section 9 of RFC2328 specifies that the Interface Data Structure includes the Router ID and IP address for the DR and BDR.

o   Section 4.1.2 of RFC5340 does not specify how to identify the DR and BDR, but given the OSPFv3 protocol, it seems reasonable that the router ID and interface ID would be stored.

-          Section 4.1.2 of RFC5340 specifies a number of objects that do not appear in the RFC2328 version of the Interface Data Structure, as follows.

o   Interface ID.

o   Instance ID.

o   List of LSAs with link-local scope.

o   List of IPv6 prefixes configured for the attached link.

Regards
Alan

From: Derek Man-Kit Yeung (myeung) [mailto:myeung@cisco.com]
Sent: 04 February 2016 19:39
To: Alan Davey <Alan.Davey@metaswitch.com>; draft-ietf-ospf-yang@ietf.org
Cc: ospf@ietf.org
Subject: Re: draft-ietf-ospf-yang-03 questions and doubts

Hi Alan,

Thanks for the comments.
As you have pointed out, there are OSPFv3 specific fields missing in the model now. For example, instance ID and interface ID. We will add them in the next update.

As for the DR, DR is conceptually one of the neighbor.
In OSPFv2, the DR's router ID and IP address are used in protocol operation.
While in OSPFv3, the DR's router ID and interface ID are used in protocol operation.
According to OSPFv2 and OSPFv3 RFC, the interface structure should keep both the DR's router ID and IP address.

We have the following in the current model.

  grouping interface-operation {
    leaf dr {
      type inet:ipv4-address;
      description "Designated Router (DR) IP address.";
    }
  }
  grouping neighbor-operation {
    leaf dr {
      type yang:dotted-quad;
      description
        "Designated Router.";
    }
  }

To better match the RFC and accommodate both OSPFv2 and OSPFv3 in a cleaner way, we plan to make the following changes.

  grouping interface-operation {
    leaf dr-router-id {
      type yang:dotted-quad;
      description
        "Designated Router (DR) router ID.";
    }
    leaf dr-ip-address {
      type inet:ip-address;
      description "Designated Router (DR) IP address.";
    }
  }
  grouping neighbor-operation {
    leaf dr-router-id {
      type yang:dotted-quad;
      description
        "Neighbor's Designated Router (DR) router ID.";
    }
    leaf dr-ip-address {
      type inet:ip-address;
      description "Neighbor's Designated Router (DR) IP address.";
    }
  }

If one need the DR's interface ID in the OSPFv3 case, it could be found by locating the neighbor entry for the DR and get the interface ID (To be added) field there.

Comments welcome.

Thanks,
- Derek

From: Alan Davey <Alan.Davey@metaswitch.com<mailto:Alan.Davey@metaswitch.com>>
Date: Tuesday, December 15, 2015 8:23 AM
To: "draft-ietf-ospf-yang@ietf.org<mailto:draft-ietf-ospf-yang@ietf.org>" <draft-ietf-ospf-yang@ietf.org<mailto:draft-ietf-ospf-yang@ietf.org>>
Cc: "ospf@ietf.org<mailto:ospf@ietf.org>" <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: draft-ietf-ospf-yang-03 questions and doubts

Folks

I have a doubt about draft-ietf-ospf-yang-03.  Please let me know your thoughts on the following.

The text is OSPFv2-specific in places.  I think that it would be better to define separate top-level groupings and containers for OSPFv2 and OSPFv3 and define common groupings and containers, where possible, that are used by both.

For example, grouping interface-operation contains the following, which is incorrect for OSPFv3.


-          leaf dr with type ipv4-address

-          leaf bdr with type ipv4-address.

I think that it would be better to define something along the following lines.


-          ospfv3-interface-operation {

o   uses interface-config

o   uses ospf-common-interface-operation

o   leaf dr {

?  type if:interface-ref

?  description:

*                   "The remote interface ID used by the Designated Router on

*                   this link.  This is the interface index of the interface local to the DR.";

o   etc

-          ospfv2-interface-operation {

o   uses interface-config

o   uses ospf-common-interface-operation

o   leaf dr {

?           type inet:ipv4-address;

?           description "Designated Router (DR) IP address.";

o   etc.

Regards
Alan Davey