Re: [Idr] Comments on draft-ietf-idr-bgpls-inter-as-topology-ext-01

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 26 March 2019 12:47 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1536312000F; Tue, 26 Mar 2019 05:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gNa8cSWqVD_z; Tue, 26 Mar 2019 05:47:13 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id DC88C120043; Tue, 26 Mar 2019 05:47:09 -0700 (PDT)
Received: from [31.133.151.13] (unknown [31.133.151.13]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 57C376795C6; Tue, 26 Mar 2019 20:47:01 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-5D75FBE2-2D0D-4A99-ACCE-17B23297D13B"
Mime-Version: 1.0 (1.0)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <SN6PR11MB2845B59759A8F85D22E63162C15F0@SN6PR11MB2845.namprd11.prod.outlook.com>
Date: Tue, 26 Mar 2019 13:46:57 +0100
Cc: "draft-ietf-idr-bgpls-inter-as-topology-ext@ietf.org" <draft-ietf-idr-bgpls-inter-as-topology-ext@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <27CC8A9A-B773-4831-B9F0-B2E94E34FAAD@tsinghua.org.cn>
References: <SN6PR11MB2845B59759A8F85D22E63162C15F0@SN6PR11MB2845.namprd11.prod.outlook.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MAg6Sxw*VjlKOg09DxkwEAtW KxcwCwNVSlVKTk5ITUtPT0lDS05IVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlISlVKSEhVSk5KVUpIWVdZCAFZQUpLTEhINwY+
X-HM-Tid: 0a69ba0a26f09373kuws57c376795c6
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/OZ4x-YblL2GmnrDRL1tnZoNpLc8>
Subject: Re: [Idr] Comments on draft-ietf-idr-bgpls-inter-as-topology-ext-01
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 26 Mar 2019 12:47:17 -0000

Hi, Ketan:

Thanks for your comments. 
I think the newly proposed solutions can solve your concerns for the redistribution action proposed in previous version of this draft.
The newly proposed BGP-LS NLRI can provide one generic solutions for the inter-AS scenario and other more generic situations. We can rename this NLRI in next version of this draft for its more broad use cases.
I will reorganize the structure of this draft to reflect your concerns in the next version.

Look forward to discuss you on the mail list or offline during the meeting.

Best Regards.

Aijun Wang
China Telecom

> On Mar 26, 2019, at 10:52, Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
> 
> Hello Authors,
>  
> Thanks for this draft update and presenting it at the IDR session on Monday.
>  
> I refer to our exchange during the WG adoption call on some issues/concerns on this document and also some comments on the mailing list on the previous versions of this draft from Acee, Jeff and others.
>  
> I see that the draft still continues to carry this notion of "native IP" scenario and the wrong premise of redistribution of the prefixes corresponding to the inter-AS links being used to "describe" such links via BGP-LS. I have no objection if any provider wants to use the BGP-LS information in this way - after all what a consumer does with the BGP-LS information it is outside the scope of BGP-LS. However, I continue to have objections to this entire section 3.1 continuing in this WG draft. Distribution of external prefixes (via redistribution) is already covered in RFC7752. There is nothing new here. What is new is this assumption of interpreting redistributed prefixes as inter-AS links which is wrong and MUST never be generalized as such in a standards track RFC.
>  
> Can you please remove this entire Section 3.1?
>  
> The rest of this document covers the important gap that was left by https://tools.ietf.org/html/rfc7752#section-3.5 and hence my support for this document..
>  
> I see that you have defined a new Link-State NLRI type for describing an Inter-AS link. I understand your motivation for doing this since we don't have Remote Node Descriptors for such links. I would suggest that instead of making it specific to Inter-AS scenario, we can view it as a "stub" link in a generic manner. This way, it may be also used for other scenarios where we don't have a IGP adjacency or it's part of the IGP adjacency but running in passive mode.
>  
> We can discuss further on this NLRI type once we have an agreement on above.
>  
> Thanks,
> Ketan
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr