Return-Path: 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 ; 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 ; 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 ; 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 X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Tue, 26 Mar 2019 14:34:11 +0100 Cc: "idr@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <27CC8A9A-B773-4831-B9F0-B2E94E34FAAD@tsinghua.org.cn> To: "Ketan Talaulikar (ketant)" X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++ X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Mhg6AQw6ATlRUQ1ITEsjAzUZ Sz0KFDVVSlVKTk5ITUtMSU1JSENOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlISlVKSEhVSklCVUpPSVlXWQgBWUFKTk5OTjcG X-HM-Tid: 0a69ba3566a29865kuuuae1b14a359 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 13:34:39 -0000 --Apple-Mail-A2AB4B5A-0565-45ED-B581-759EE1DF0A2B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Ketan: Yeah, I will remove the content in section 3.1. The =E2=80=9CProtocol=E2=80=9D associated with the newly defined BGP-LS NLRI= for these stub links will be =E2=80=9Cdirect=E2=80=9D. Aijun Wang China Telecom > On Mar 26, 2019, at 14:21, Ketan Talaulikar (ketant) wr= ote: >=20 > Hi Aijun, > =20 > Are you ok to remove section 3.1 of the draft v01 which talks about interp= retation of redistributed prefixes of the Inter-AS links? > =20 > If so, then I think we can solve both the scenarios with the new =E2=80=9C= stub=E2=80=9D Link NLRI type. When IGP are flooding the Inter-AS Link info v= ia their LSA/LSP, then the Inter-AS Link info can be distributed into BGP-L= S by any IGP node in the domain. In the scenario that you call =E2=80=9Cnati= ve IP=E2=80=9D, we would need the ASBRs to originate information of the Inte= r-AS link perhaps as a =E2=80=9Cdirect=E2=80=9D protocol into BGP-LS. > =20 > Thanks, > Ketan > =20 > From: Aijun Wang =20 > Sent: 26 March 2019 13:47 > To: Ketan Talaulikar (ketant) > 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 > =20 > Hi, Ketan: > =20 > Thanks for your comments.=20 > I think the newly proposed solutions can solve your concerns for the redis= tribution action proposed in previous version of this draft. > The newly proposed BGP-LS NLRI can provide one generic solutions for the i= nter-AS scenario and other more generic situations. We can rename this NLRI i= n next version of this draft for its more broad use cases. > I will reorganize the structure of this draft to reflect your concerns in t= he next version. > =20 > Look forward to discuss you on the mail list or offline during the meeting= . > =20 > Best Regards. >=20 > Aijun Wang > China Telecom >=20 > On Mar 26, 2019, at 10:52, Ketan Talaulikar (ketant) wr= ote: >=20 > Hello Authors, > =20 > Thanks for this draft update and presenting it at the IDR session on Monda= y. > =20 > I refer to our exchange during the WG adoption call on some issues/concern= s on this document and also some comments on the mailing list on the previou= s versions of this draft from Acee, Jeff and others. > =20 > I see that the draft still continues to carry this notion of "native IP" s= cenario and the wrong premise of redistribution of the prefixes correspondin= g to the inter-AS links being used to "describe" such links via BGP-LS. I ha= ve no objection if any provider wants to use the BGP-LS information in this w= ay - after all what a consumer does with the BGP-LS information it is outsid= e 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 i= nter-AS links which is wrong and MUST never be generalized as such in a stan= dards track RFC. > =20 > Can you please remove this entire Section 3.1? > =20 > 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 docu= ment.. > =20 > I see that you have defined a new Link-State NLRI type for describing an I= nter-AS link. I understand your motivation for doing this since we don't hav= e Remote Node Descriptors for such links. I would suggest that instead of ma= king it specific to Inter-AS scenario, we can view it as a "stub" link in a g= eneric manner. This way, it may be also used for other scenarios where we do= n't have a IGP adjacency or it's part of the IGP adjacency but running in pa= ssive mode. > =20 > We can discuss further on this NLRI type once we have an agreement on abov= e. > =20 > Thanks, > Ketan > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-A2AB4B5A-0565-45ED-B581-759EE1DF0A2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Ketan:
Yeah, I will remove the cont= ent in section 3.1.
The =E2=80=9CProtocol=E2=80=9D associated with= the newly defined BGP-LS NLRI for these stub links will be =E2=80=9Cdirect=E2= =80=9D.

Aijun Wang
Chi= na Telecom

On Mar 26, 2019, at 14:21, Ketan T= alaulikar (ketant) <ketant@cisco.com<= /a>> wrote:

Hi Aijun,

 

Are you ok to remove section 3.1 of the draft v01 whi= ch talks about interpretation of redistributed prefixes of the Inter-AS link= s?

 

If so, then I think we can solve both the scenarios w= ith the new =E2=80=9Cstub=E2=80=9D 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 =E2=80=9Cnative IP=E2=80=9D, we would need th= e ASBRs to originate information of the Inter-AS link perhaps as a =E2=80=9C= direct=E2=80=9D 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 c= oncerns for the redistribution action proposed in previous version of this d= raft.

The newly proposed BGP-LS NLRI can provide one generi= c solutions for the inter-AS scenario and other more generic situations. We c= an rename this NLRI in next version of this draft for its more broad use cas= es.

I will reorganize the structure of this draft to refl= ect your concerns in the next version.

 

Look forward to discuss you on the mail list or offli= ne 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 t= he IDR session on Monday.

 

I refer to our exchange during the WG adoption call on some issues/concerns on this doc= ument 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 t= he prefixes corresponding to the inter-AS links being used to "describe" suc= h 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 c= ontinuing in this WG draft. Distribution of external prefixes (via redistribution) is already covered in RFC7752. Th= ere is nothing new here. What is new is this assumption of interpreting redi= stributed prefixes as inter-AS links which is wrong and MUST never be genera= lized 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.ie= tf.org/html/rfc7752#section-3.5 and hence my support for this document..=

 

I see that you have defined a new Link-State NLRI t= ype for describing an Inter-AS link. I understand your motivation for doing t= his since we don't have Remote Node Descriptors for such links. I would sugg= est 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 ha= ve a IGP adjacency or it's part of the IGP adjacency but running in passive m= ode.

 

We can discuss further on this NLRI type once we h= ave an agreement on above.

 

Thanks,

Ketan

 

__________= _____________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/m= ailman/listinfo/idr

= --Apple-Mail-A2AB4B5A-0565-45ED-B581-759EE1DF0A2B--