Re: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv
Aijun – When an authentication variant is not supported by all nodes in the area/domain it can’t be used safely. This isn’t a problem we are trying to solve and it was never the reason for writing the invalid TLV draft. Please reread the Abstract and Introduction in order to understand the intent of this draft. Thanx. Les From: Aijun Wang Sent: Sunday, January 05, 2020 7:20 PM To: Les Ginsberg (ginsberg) ; 'Christian Hopps' ; lsr@ietf.org Cc: lsr-...@ietf.org; 'Antoni Przygienda' Subject: 答复: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv Hi, Les: The questions is raised actually by the current description in section 3.2. It describes the incompatible issues among different RFCs, but no promising solution (maybe there is none), also not emphasizing the consequence for the incompatible deployments (may exist in other document). Anyway, I knew the answers. Put it into the document may be more helpful for others. Best Regards. Aijun Wang China Telecom 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 发送时间: 2020年1月6日 10:42 收件人: Aijun Wang; 'Christian Hopps'; lsr@ietf.org<mailto:lsr@ietf.org> 抄送: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 'Antoni Przygienda' 主题: RE: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv Aijun – Please read Section 3.2 of the draft which discusses these issues. Thanx. Les From: Aijun Wang mailto:wangai...@tsinghua.org.cn>> Sent: Sunday, January 05, 2020 6:04 PM To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 'Christian Hopps' mailto:cho...@chopps.org>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 'Antoni Przygienda' mailto:p...@juniper.net>> Subject: 答复: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv Hi, Les: Since this draft is the main entry for the management of invalid tlv in isis, will it be more useful to include the description that you provide for its completeness? Knowing the possible consequences may drive the operators to consider more carefully for their updating deployment. Anyway, I support this draft. Best Regards. Aijun Wang China Telecom 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 发送时间: 2020年1月3日 13:29 收件人: Aijun Wang; 'Christian Hopps'; lsr@ietf.org<mailto:lsr@ietf.org> 抄送: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 'Antoni Przygienda' 主题: RE: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv Aijun - Since advertising some sort of capability would also be unusable until all routers were upgraded to understand the new capability advertisement this does not help. The consequences of enabling a form of authentication which is not supported by all nodes is an inconsistent LSPDB - which means protocol function is broken. I would also point out that the incompatibilities are discussed in the original specifications (RFC 5304 and RFC 6232) - both of which have been published for a number of years. The points being made in this regard in this draft aren't new. Les > -Original Message- > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of > Aijun Wang > Sent: Thursday, January 02, 2020 6:31 PM > To: 'Christian Hopps' mailto:cho...@chopps.org>>; > lsr@ietf.org<mailto:lsr@ietf.org> > Cc: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 'Antoni Przygienda' > mailto:p...@juniper.net>> > Subject: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv > > Is there any method to indicate or negotiate the support of > ISO10589/RFC5304/RFC6233 because they are not back compatible? > What will be the consequence when not all of the routers within the IGP > domain support the same RFC? > Will it valuable to add more clarification for the above incompatible > scenario, instead of saying "... ... therefore can only be safely enabled > when all nodes support the extensions"? > > > Best Regards. > > Aijun Wang > China Telecom > > -邮件原件- > 发件人: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> > [mailto:lsr-boun...@ietf.org] 代表 Christian > Hopps > 发送时间: 2020年1月3日 3:07 > 收件人: lsr@ietf.org<mailto:lsr@ietf.org> > 抄送: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; Christian Hopps; Antoni > Przygienda > 主题: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv > > This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for > draft-ietf-lsr-isis-invalid-tlv. > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > Tony P (other authors already responded during the adoption poll), please > indicate your knowledge of any IPR related to this work to the list as well. > > Thanks, > Chris & Acee. > > ___ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.o
Re: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv
Aijun – Please read Section 3.2 of the draft which discusses these issues. Thanx. Les From: Aijun Wang Sent: Sunday, January 05, 2020 6:04 PM To: Les Ginsberg (ginsberg) ; 'Christian Hopps' ; lsr@ietf.org Cc: lsr-...@ietf.org; 'Antoni Przygienda' Subject: 答复: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv Hi, Les: Since this draft is the main entry for the management of invalid tlv in isis, will it be more useful to include the description that you provide for its completeness? Knowing the possible consequences may drive the operators to consider more carefully for their updating deployment. Anyway, I support this draft. Best Regards. Aijun Wang China Telecom 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 发送时间: 2020年1月3日 13:29 收件人: Aijun Wang; 'Christian Hopps'; lsr@ietf.org<mailto:lsr@ietf.org> 抄送: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 'Antoni Przygienda' 主题: RE: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv Aijun - Since advertising some sort of capability would also be unusable until all routers were upgraded to understand the new capability advertisement this does not help. The consequences of enabling a form of authentication which is not supported by all nodes is an inconsistent LSPDB - which means protocol function is broken. I would also point out that the incompatibilities are discussed in the original specifications (RFC 5304 and RFC 6232) - both of which have been published for a number of years. The points being made in this regard in this draft aren't new. Les > -Original Message- > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of > Aijun Wang > Sent: Thursday, January 02, 2020 6:31 PM > To: 'Christian Hopps' mailto:cho...@chopps.org>>; > lsr@ietf.org<mailto:lsr@ietf.org> > Cc: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; 'Antoni Przygienda' > mailto:p...@juniper.net>> > Subject: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv > > Is there any method to indicate or negotiate the support of > ISO10589/RFC5304/RFC6233 because they are not back compatible? > What will be the consequence when not all of the routers within the IGP > domain support the same RFC? > Will it valuable to add more clarification for the above incompatible > scenario, instead of saying "... ... therefore can only be safely enabled > when all nodes support the extensions"? > > > Best Regards. > > Aijun Wang > China Telecom > > -邮件原件- > 发件人: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> > [mailto:lsr-boun...@ietf.org] 代表 Christian > Hopps > 发送时间: 2020年1月3日 3:07 > 收件人: lsr@ietf.org<mailto:lsr@ietf.org> > 抄送: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; Christian Hopps; Antoni > Przygienda > 主题: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv > > This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for > draft-ietf-lsr-isis-invalid-tlv. > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > Tony P (other authors already responded during the adoption poll), please > indicate your knowledge of any IPR related to this work to the list as well. > > Thanks, > Chris & Acee. > > ___ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > > ___ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv
Aijun - Since advertising some sort of capability would also be unusable until all routers were upgraded to understand the new capability advertisement this does not help. The consequences of enabling a form of authentication which is not supported by all nodes is an inconsistent LSPDB - which means protocol function is broken. I would also point out that the incompatibilities are discussed in the original specifications (RFC 5304 and RFC 6232) - both of which have been published for a number of years. The points being made in this regard in this draft aren't new. Les > -Original Message- > From: Lsr On Behalf Of Aijun Wang > Sent: Thursday, January 02, 2020 6:31 PM > To: 'Christian Hopps' ; lsr@ietf.org > Cc: lsr-...@ietf.org; 'Antoni Przygienda' > Subject: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv > > Is there any method to indicate or negotiate the support of > ISO10589/RFC5304/RFC6233 because they are not back compatible? > What will be the consequence when not all of the routers within the IGP > domain support the same RFC? > Will it valuable to add more clarification for the above incompatible > scenario, instead of saying "... ... therefore can only be safely enabled > when all nodes support the extensions"? > > > Best Regards. > > Aijun Wang > China Telecom > > -邮件原件- > 发件人: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> > [mailto:lsr-boun...@ietf.org] 代表 Christian > Hopps > 发送时间: 2020年1月3日 3:07 > 收件人: lsr@ietf.org<mailto:lsr@ietf.org> > 抄送: lsr-...@ietf.org<mailto:lsr-...@ietf.org>; Christian Hopps; Antoni > Przygienda > 主题: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv > > This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for > draft-ietf-lsr-isis-invalid-tlv. > > https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ > > Tony P (other authors already responded during the adoption poll), please > indicate your knowledge of any IPR related to this work to the list as well. > > Thanks, > Chris & Acee. > > ___ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > > ___ > Lsr mailing list > Lsr@ietf.org<mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv
Is there any method to indicate or negotiate the support of ISO10589/RFC5304/RFC6233 because they are not back compatible? What will be the consequence when not all of the routers within the IGP domain support the same RFC? Will it valuable to add more clarification for the above incompatible scenario, instead of saying "... ... therefore can only be safely enabled when all nodes support the extensions"? Best Regards. Aijun Wang China Telecom -邮件原件- 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Christian Hopps 发送时间: 2020年1月3日 3:07 收件人: lsr@ietf.org 抄送: lsr-...@ietf.org; Christian Hopps; Antoni Przygienda 主题: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for draft-ietf-lsr-isis-invalid-tlv. https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ Tony P (other authors already responded during the adoption poll), please indicate your knowledge of any IPR related to this work to the list as well. Thanks, Chris & Acee. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
