Re: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard

Balaji Rajagopalan <balajir@juniper.net> Wed, 01 April 2015 17:00 UTC

Return-Path: <balajir@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BF31A87C7; Wed, 1 Apr 2015 10:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KX8RcWioaR0C; Wed, 1 Apr 2015 10:00:23 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23371A01E7; Wed, 1 Apr 2015 10:00:22 -0700 (PDT)
Received: from BN1PR05MB535.namprd05.prod.outlook.com (10.141.65.155) by BN1PR05MB437.namprd05.prod.outlook.com (10.141.58.11) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 1 Apr 2015 17:00:16 +0000
Received: from BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) by BN1PR05MB535.namprd05.prod.outlook.com ([169.254.8.244]) with mapi id 15.01.0118.022; Wed, 1 Apr 2015 17:00:16 +0000
From: Balaji Rajagopalan <balajir@juniper.net>
To: "ietf@ietf.org" <ietf@ietf.org>, Hannes Gredler <hannes@juniper.net>
Thread-Topic: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard
Thread-Index: AQHQYbN1sBT99RQ7ME2g+UypTJek+p04078A
Date: Wed, 1 Apr 2015 17:00:15 +0000
Message-ID: <D141DAC4.12D74%balajir@juniper.net>
References: <20150318194048.32558.12168.idtracker@ietfa.amsl.com>
In-Reply-To: <20150318194048.32558.12168.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [116.197.184.11]
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB437;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(15975445007)(2950100001)(2900100001)(122556002)(50986999)(102836002)(106116001)(86362001)(54356999)(77156002)(87936001)(92566002)(19617315012)(450100001)(2501003)(99286002)(83506001)(19580395003)(230783001)(36756003)(46102003)(62966003)(76176999)(40100003)(16236675004)(19580405001)(2656002)(66066001)(24704002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB437; H:BN1PR05MB535.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <BN1PR05MB4377D18C108E626884DEBEDABF30@BN1PR05MB437.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR05MB437; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB437;
x-forefront-prvs: 053315510E
Content-Type: multipart/alternative; boundary="_000_D141DAC412D74balajirjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2015 17:00:15.7024 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB437
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/KGz95w1VUMGMQbLwuAlxmZac0FY>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2015 17:00:26 -0000

I seek a correction to the following text in section 3.2.1.4.

"
IGP Router ID: <snip> For an OSPFv2 "Pseudonode" representing a LAN,

      this contains the 4 octet Router-ID of the designated router (DR)
      followed by the 4 octet IPv4 address of the DR's interface to the
      LAN (8 octets in total) <snip>"


The reason I seek this change is, the transit link representation in OSPFv2 router-LSA does not contain the router-id of the DR (section 12.4.1.2 of RFC2328). So, BGP-LS has nowhere to derive Router-ID from.


Below are more details with an example.


The 'IGP router ID' field can appear either in ‘Local Node Descriptor’ or ‘Remote Node Descriptor’. Let’s consider the case in which this field appears in ‘Remote Node Descriptor’ in the following topology.


R1(1.1.1.1::10.10.10.1) <----L1----> R2 (2.2.2.2::10.10.10.2)

Where,
R1's router-id is 1.1.1.1, and L1 interface IP address is 10.10.10.1.
R2's router-id is 2.2.2.2, and L1 interface IP address is 10.10.10.2.
L1 is a LAN.
R1 is elected as the DR for L1.

There are four distinct unidirectional links in the topology above: R1->DR, DR->R1, R2->DR, and DR->R2. Let’s consider the link R2->DR. R2’s router LSA represents R2->DR link as follows: -

Advertising router:2.2.2.2
   Link ID: 10.10.10.1
   Link data:10.10.10.2
   Type:2 (Transit)

Note that the OSPF link representation above does not include the router-id of the DR, which is 1.1.1.1.


According to the text in section 3.2.1.4, BGP-LS requires us to represent R2->DR link as follows (considering only node descriptors of relevance to this discussion, and ignoring the remaining fields) : -

Local Node(IGP-Router-Id:2.2.2.2) -> Remote Node(IGP-Router-Id:1.1.1.1-10.10.10.1)


However, the OSPF representation of the above link in R2’s router LSA does not contain 1.1.1.1 at all. Therefore, BGP-LS has nowhere to derive ‘1.1.1.1’ from, for the link R2->DR.

The example in section 3.7 is at odds with the text in section 3.2.1.4, and represents the link as follows (which works perfectly): -


Local Node(IGP-Router-Id:2.2.2.2) -> Remote Node(IGP-Router-Id:10.10.10.1-10.10.10.1)


I suggest rewording the text in 3.2.1.4 as follows:

"
IGP Router ID: <snip> For an OSPFv2 "Pseudonode" representing a LAN,

      this contains the 4 octet IPv4 address of the DR's interface to the
      LAN, followed by any non-zero 4-octet number (8 octets in total) <snip>”


—
Balaji Rajagopalan




From: The IESG <iesg-secretary@ietf.org<mailto:iesg-secretary@ietf.org>>
Reply-To: "ietf@ietf.org<mailto:ietf@ietf.org>" <ietf@ietf.org<mailto:ietf@ietf.org>>
Date: Thursday, March 19, 2015 at 1:10 AM
To: IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>
Cc: "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>
Subject: [Idr] REVISED Last Call: <draft-ietf-idr-ls-distribution-10.txt> (North-Bound Distribution of Link-State and TE Information using BGP) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document:
- 'North-Bound Distribution of Link-State and TE Information using BGP'
  <draft-ietf-idr-ls-distribution-10.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org<mailto:ietf@ietf.org> mailing lists by 2015-04-08. Exceptionally, comments may be
sent to iesg@ietf.org<mailto:iesg@ietf.org> instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   In a number of environments, a component external to a network is
   called upon to perform computations based on the network topology and
   current state of the connections within the network, including
   traffic engineering information.  This is information typically
   distributed by IGP routing protocols within the network.

   This document describes a mechanism by which links state and traffic
   engineering information can be collected from networks and shared
   with external components using the BGP routing protocol.  This is
   achieved using a new BGP Network Layer Reachability Information
   (NLRI) encoding format.  The mechanism is applicable to physical and
   virtual IGP links.  The mechanism described is subject to policy
   control.

   Applications of this technique include Application Layer Traffic
   Optimization (ALTO) servers, and Path Computation Elements (PCEs).





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution/ballot/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1864/



_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr