Re: [Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Les Ginsberg (ginsberg)]

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] 代表 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: Questions on Prefix Unreachable Announcement

[Aijun Wang]

Hi, Huaimo:

 

Thanks for your review.  After the holiday, let’s begin the discussion.

Your understanding for generating the PUA(Prefix Unreachable Announcement)
is correct, but the process for stop the PUA is not the way that we
proposed.

In theory, the ABR will send the PUA once when it notices the specific
prefix is unreachable. 

When the other router receives the PUA, it will generate one black hole
route, and this black hole route will be kept for a short time(configurable)
to facilitate the service convergence that depends on this failed prefix.

The PUA will be generated and announced by the ABR only on the following
circumstances:

1. The ABR do the summary work

2. The failed prefix located within the summary route range.

3. The numbered of the failed prefixes not exceed the
MAA(MAX_Address_Announcement) as defined in
https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-01
#section-6

 

More implementation consideration can be found on the above section.

We are also appreciate to get more feedbacks for the current implementation
consideration.

 

More specific answers are also presented inline below.

 

Best Regards.

 

Aijun Wang

China Telecom

 

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Huaimo Chen
发送时间: 2019年12月20日 22:50
收件人: Aijun Wang; lsr@ietf.org
主题: [Lsr] Questions on Prefix Unreachable Announcement

 

Hi Aijun,

 

My understanding of your draft
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annouceme
nt/
  as follows: 

After the ABR originates the Extended Prefix Opaque LSA, which contains
a prefix and its originator (i.e., the router originating the prefix), it
will announce that the prefix is unreachable when it can not reach the
prefix (i.e., the prefix becomes unreachable from reachable from the ABR's
perspective). 

 Is my understanding right?

   [Aijun Wang]: Yes

 

Should the ABR remove the prefix from the Extended Prefix Opaque LSA after
it announces the prefix unreachable for a give period of time?

  [Aijun Wang]: In theory, the ABR will only announce once when it
notices the disappear of the specific prefix.

 

After a router in another area receives the unreachable announcement of the
prefix, it installs a black hole route to the prefix, and then removes the
black hole route after a configurable time. After the black hole route
derived from the unreachable announcement of the prefix is removed, it seems
better to remove the unreachable prefix from the LSA. 

[Aijun Wang]: the PUA will not be announced continuously.



 Can the ABR just remove the prefix (i.e., the TLV for the prefix) from
the Extended Prefix Opaque LSA when it can not reach the prefix? 

[Aijun Wang]: When the ABR do the summary work, it will not announce the
detailed prefixes that located within the summary route range. Then the
unreachable prefixes located in the summary range should be announced
explicitly.

 

Best Regards,

Huaimo

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Aijun Wang]

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Jeff Tantsura]

yes/support

Happy New Year all!

Cheers,
Jeff
On Jan 2, 2020, 11:07 AM -0800, Christian Hopps , wrote:
> 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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Tony Li]

As co-author:


This is only 20 years overdue.  Ship it already.  :-)

T


> On Jan 2, 2020, at 11:06 AM, Christian Hopps  wrote:
> 
> 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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Antoni Przygienda]

No knowledge of any undisclosed IPR

On 1/2/20, 11:40 AM, "Paul Wells"  wrote:

Support (as co-author).

Thanks,
Paul

On 1/2/20 2:06 PM, Christian Hopps wrote:
> This begins a 2 week WG Last Call, ending after Jan 16th, 2020, for
> draft-ietf-lsr-isis-invalid-tlv.
>
>
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/__;!!NEt6yMaO-gk!SOzqP-LOJ5vQHvJt7ptRik0WDQIHhKFBgZzxo6c1fwUo7MHPgmejedaGbuCdHg$
 
>
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!SOzqP-LOJ5vQHvJt7ptRik0WDQIHhKFBgZzxo6c1fwUo7MHPgmejeda1gk9Taw$
 



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Paul Wells]

Support (as co-author).

Thanks,
Paul

On 1/2/20 2:06 PM, Christian Hopps wrote:

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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Antoni Przygienda]

Support +1 obviously 

--- tony 

On 1/2/20, 11:35 AM, "Les Ginsberg (ginsberg)"  wrote:

As co-author, I obviously support moving the draft forward.

The impetus for writing the draft was a real world interoperability problem 
- so there should be no debate about whether the draft is needed.
All parties involved in the problem have actively participated in writing 
the draft - so I think we can be confident that we have appropriately addressed 
the related issues.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Thursday, January 02, 2020 11:07 AM
> To: lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; Antoni
> Przygienda 
> Subject: [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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/__;!!NEt6yMaO-gk!Xqr-8QUzi2w5xHSiBoC1-Cb1CiQk8b_C9wiUKST8PRGbEfHsUpZJh2XnuuxB2Q$
 
> 
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!Xqr-8QUzi2w5xHSiBoC1-Cb1CiQk8b_C9wiUKST8PRGbEfHsUpZJh2XJ7B9p_w$
 


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Les Ginsberg (ginsberg)]

As co-author, I obviously support moving the draft forward.

The impetus for writing the draft was a real world interoperability problem - 
so there should be no debate about whether the draft is needed.
All parties involved in the problem have actively participated in writing the 
draft - so I think we can be confident that we have appropriately addressed the 
related issues.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Christian Hopps
> Sent: Thursday, January 02, 2020 11:07 AM
> To: lsr@ietf.org
> Cc: lsr-...@ietf.org; Christian Hopps ; Antoni
> Przygienda 
> Subject: [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

Re: [Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Acee Lindem (acee)]

Speaking as WG Member:

I support publication. This is document fills a long-standing gap in the IS-IS 
specification. 

Thanks,
Acee

On 1/2/20, 2:09 PM, "Lsr on behalf of Christian Hopps"  wrote:

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

[Lsr] WG Last Call draft-ietf-lsr-isis-invalid-tlv

[Christian Hopps]

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] lsr - New Meeting Session Request for IETF 107

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Acee Lindem, a Chair 
of the lsr working group.


-
Working Group Name: Link State Routing
Area Name: Routing Area
Session Requester: Acee Lindem

Number of Sessions: 2
Length of Session(s):  2 Hours, 1 Hour
Number of Attendees: 100
Conflicts to Avoid: 
 Chair Conflict: ipsecme idr rtgwg lsvr
 Technology Overlap: rift spring
 Key Participant Conflict: bfd bess


People who must be present:
  Acee Lindem
  Christian Hopps
  Alvaro Retana

Resources Requested:

Special Requests:
  
-

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr