Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document

"Pradosh Mohapatra (pmohapat)" <> Tue, 25 November 2008 15:58 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id CEC383A6864; Tue, 25 Nov 2008 07:58:27 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB6AF3A6864 for <>; Tue, 25 Nov 2008 07:58:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S3Kv454KpiUS for <>; Tue, 25 Nov 2008 07:58:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DE2E13A67B2 for <>; Tue, 25 Nov 2008 07:58:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,664,1220227200"; d="scan'208";a="109880388"
Received: from ([]) by with ESMTP; 25 Nov 2008 15:58:23 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id mAPFwNjd030738; Tue, 25 Nov 2008 07:58:23 -0800
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id mAPFwNDQ005057; Tue, 25 Nov 2008 15:58:23 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 07:58:23 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 25 Nov 2008 07:58:21 -0800
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document
Thread-Index: AclOq8G0Ue3+7HjfRRaNa4gRpxTnkgAINXqA
References: <> <>
From: "Pradosh Mohapatra (pmohapat)" <>
To: "Danny McPherson" <>, "Yakov Rekhter" <>
X-OriginalArrivalTime: 25 Nov 2008 15:58:23.0434 (UTC) FILETIME=[A51632A0:01C94F16]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1691; t=1227628703; x=1228492703; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Pradosh=20Mohapatra=20(pmohapat)=22=20<pmohapat> |Subject:=20RE=3A=20[Idr]=20draft-walton-bgp-add-paths-06.t xt=20as=20IDR=20WG=20document |Sender:=20; bh=2Js2Rc0xGtLw6yeqmwufenGms4JT14xyeitgzke0sVA=; b=k3Tt47y3M1GWBkSctPyU4fGweuu4YQ8bNLrMF8aWiD0Mv00r92qJlX4Ops 2NSo89oIKapH+URDjJoheDiATR2r6SsnyaKV8fhYVDpIoShEkwFeDnvnFIQn okezVzkEZA;
Authentication-Results: sj-dkim-3;; dkim=pass ( sig from verified; );
Subject: Re: [Idr] draft-walton-bgp-add-paths-06.txt as IDR WG document
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

| ---
| While Path Identifier assignment is purely a local matter, 
| for operational reasons I believe that a receiving BGP 
| speaker SHOULD (MUST?) preserve any Path Identifier for an 
| associated path on receipt.  This will aid in operational debugging.

Right. It MUST preserve the path-id that it received in the path
structure since the id would be used for replacing any new 
advertisement received for that path or removing the path upon 

| ---
| I wonder if it's necessary to state handling procedures in 
| S.6 of receipt of an update message that does not use 
| extended NLRI encoding from a peer that advertised they 
| support receive processing of the capability?  For example, 
| if an implementation wanted to optimize in some manner where 
| if only one path exists then don't use the the extended NLRI 
| encoding, because you could never pack updates, etc..
| Perhaps receipt of an update for a prefix that does not use 
| extended ecoding from a peer that advertised the capability 
| should be handled normally, and not considered or generate an 
| error condition?

This makes parsing extremely difficult. Reception of the capability
from a peer is the only indication that the UPDATE parsing needs
to retrieve the first four octets as path-id and the prefix
follows after that. How would you differentiate an UPDATE message
where prefixes are encoded with path-id vs. another where they

If a speaker is able to send only one path and has advertised
add-path capability, there are simpler ways to encode a (dummy)
path-id, like always encode 0 or 1 or whatever...

- Pradosh
Idr mailing list