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 <> Thu, 02 April 2015 16:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4CA071A890F; Thu, 2 Apr 2015 09:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4TijhSd15PKF; Thu, 2 Apr 2015 09:52:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC72A1A1A4A; Thu, 2 Apr 2015 09:52:32 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 2 Apr 2015 16:52:30 +0000
Received: from ([]) by ([]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 16:52:30 +0000
From: Balaji Rajagopalan <>
To: "Acee Lindem (acee)" <>, "" <>, Hannes Gredler <>
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//+/7ICAAO8fAIAAX+WAgACBQIA=
Date: Thu, 02 Apr 2015 16:52:29 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
authentication-results:; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB438;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(51914003)(377454003)(41574002)(36756003)(46102003)(106116001)(76176999)(230783001)(54356999)(50986999)(15975445007)(102836002)(19617315012)(93886004)(122556002)(62966003)(77156002)(92566002)(99286002)(19580395003)(19580405001)(2950100001)(2900100001)(83506001)(16236675004)(86362001)(2501003)(2656002)(87936001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB438;; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR05MB438; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB438;
x-forefront-prvs: 0534947130
Content-Type: multipart/alternative; boundary="_000_D14351C71304Abalajirjunipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 16:52:29.9487 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB438
Archived-At: <>
Cc: "" <>
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-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Apr 2015 16:52:35 -0000

Hi Acee,

Thanks for the detailed response. Please see inline.

From: "Acee Lindem (acee)" <<>>
Date: Thursday, April 2, 2015 at 7:10 PM
To: Balaji Rajagopalan <<>>, "<>" <<>>, Hannes Gredler <<>>
Cc: "<>" <<>>
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

Hi Balaji,

As the IETF Routing Directorate reviewer of the this draft, I agree that it is far from perfect. However, it is very late in the review cycle and we have several implementations (refer to It is not the time to change it just to ease your implementation. See inline.

[Balaji] FWIW, I represented JUNOS (one of the implementations listed in the above draft) at one of the inter-ops, where we did not test OSPF broadcast network type due to the same issue we’re discussing now; I had notified the protocol author of this issue at that time. But, I do agree with you – there is one more implementation (ODL) listed in the draft, although I don’t know how it was all verified, since I still see an inconsistency between 3.7 and Please see below.

I also pointed out an inconsistency between the example in section 3.7 and the normative text in section So, the draft needs a correction anyway.

The question is, which one needs to be corrected – section 3.7, or section

Section 3.7 is not necessarily wrong. While this is not the best OSPF example, may be both the IP interface address and the OSPF Router ID.

[Balaji] In the specific example described in section 3.7, the router-id is not the same as the interface IP address (although I see your point that they may be the same in some scenarios). Node1’s router-id is and node2’s router-id is In the example, the DR is represented as ’' is the interface IP address of the DR(Node1).

Per section, this example should represent the DR as

So, I believe there is still a need to reconcile section 3.7 with And, I’m tilting towards the behavior described in section 3.7 :-)

IMHO, we should correct the normative text in section to align with the example in section 3.7, as the example more closely reflects how OSPFv2 represents the link.

Are you familiar with OSPFv3? In OSPFv3, the Router-ID is used in the Router-LSA to identify the DR. Hence, if we were to change it, OSPFv3 would need to be handled separately.

[Balaji] Since BGP-LS carries the ‘protocol’ type in the NLRI (which has different codes for OSPFv2 and OSPFv3), we can leave OSPFv3 representation as it is.

For that matter, I believe that BGP-LS should preserve the representation in the underlying protocol, if there is no good reason to change it. I understand that this is not an argument to make at this stage, but the inconsistency I reported above needs to be resolved. And, I would like to request that we resolve it using the principle that BGP-LS should not change the underlying protocol’s representation unnecessarily.


Balaji Rajagopalan