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

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 26 March 2019 13:34 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 B437912035A for <idr@ietfa.amsl.com>; Tue, 26 Mar 2019 06:34:36 -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 5VH5QaS-Bgma for <idr@ietfa.amsl.com>; Tue, 26 Mar 2019 06:34:29 -0700 (PDT)
Received: from m88102.mail.qiye.163.com (m88102.mail.qiye.163.com [106.2.88.102]) by ietfa.amsl.com (Postfix) with ESMTP id E4CFD1202D1 for <idr@ietf.org>; Tue, 26 Mar 2019 06:34:25 -0700 (PDT)
Received: from [31.133.129.142] (unknown [31.133.129.142]) by m88102.mail.qiye.163.com (Hmail) with ESMTPA id AE1B14A359; Tue, 26 Mar 2019 21:34:15 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-A2AB4B5A-0565-45ED-B581-759EE1DF0A2B"
Mime-Version: 1.0 (1.0)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <SN6PR11MB28450746FCAC707B990F5C95C15F0@SN6PR11MB2845.namprd11.prod.outlook.com>
Date: Tue, 26 Mar 2019 14:34:11 +0100
Cc: "idr@ietf.org" <idr@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <DDCFC43D-35CD-4E14-99BD-0DE097ED0BC6@tsinghua.org.cn>
References: <SN6PR11MB2845B59759A8F85D22E63162C15F0@SN6PR11MB2845.namprd11.prod.outlook.com> <27CC8A9A-B773-4831-B9F0-B2E94E34FAAD@tsinghua.org.cn> <SN6PR11MB28450746FCAC707B990F5C95C15F0@SN6PR11MB2845.namprd11.prod.outlook.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Mhg6AQw6ATlRUQ1ITEsjAzUZ Sz0KFDVVSlVKTk5ITUtMSU1JSENOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlISlVKSEhVSklCVUpPSVlXWQgBWUFKTk5OTjcG
X-HM-Tid: 0a69ba3566a29865kuuuae1b14a359
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VQkobWU14ce3N7fXNEcZ1K3ZjqU>
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 13:34:39 -0000

Hi, Ketan:
Yeah, I will remove the content in section 3.1.
The “Protocol” associated with the newly defined BGP-LS NLRI for these stub links will be “direct”.

Aijun Wang
China Telecom

> On Mar 26, 2019, at 14:21, Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
> 
> Hi Aijun,
>  
> Are you ok to remove section 3.1 of the draft v01 which talks about interpretation of redistributed prefixes of the Inter-AS links?
>  
> If so, then I think we can solve both the scenarios with the new “stub” Link NLRI type. When IGP are flooding the Inter-AS Link info via their LSA/LSP,  then the Inter-AS Link info can be distributed into BGP-LS by any IGP node in the domain. In the scenario that you call “native IP”, we would need the ASBRs to originate information of the Inter-AS link perhaps as a “direct” protocol into BGP-LS.
>  
> Thanks,
> Ketan
>  
> From: Aijun Wang <wangaijun@tsinghua.org.cn> 
> Sent: 26 March 2019 13:47
> To: Ketan Talaulikar (ketant) <ketant@cisco.com>
> Cc: draft-ietf-idr-bgpls-inter-as-topology-ext@ietf.org; idr@ietf.org
> Subject: Re: [Idr] Comments on draft-ietf-idr-bgpls-inter-as-topology-ext-01
>  
> 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