Re: [Lsr] [Technical Errata Reported] RFC6823 (6995)

[Chris Smiley]

Greetings,

We do not see the text reported in RFC 6823 but is found in RFC 823.  If this 
is correct, please submit a new errata referencing RFC 823.  Errata #6995 will 
be deleted.

Thank you.

RFC Editor/cs


> On Jun 16, 2022, at 2:12 AM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC6823,
> "Advertising Generic Information in IS-IS".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6995
> 
> --
> Type: Technical
> Reported by: keep 
> 
> Section: global
> 
> Original Text
> -
> [10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
>  Beranek and Newman Inc., August 1982.
> 
> Corrected Text
> --
> [10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
>  Beranek and Newman Inc., August 1982, not issued
> 
> Notes
> -
> RFC823 references IEN-209, which was not issued, and won't be 
> (https://www.rfc-editor.org/ien/scanned/ien209.pdf). I encourage discussion 
> of whether it should reference RFC827 instead.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC6823 (draft-ietf-isis-genapp-04)
> --
> Title   : Advertising Generic Information in IS-IS
> Publication Date: December 2012
> Author(s)   : L. Ginsberg, S. Previdi, M. Shand
> Category: PROPOSED STANDARD
> Source  : IS-IS for IP Internets
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 

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

Re: [Lsr] [Technical Errata Reported] RFC8919 (6630)

[John Scudder]

By the way,

> On Jun 13, 2022, at 1:15 AM, Les Ginsberg (ginsberg)  
> wrote:
> 
> If you want to see the diff from the respective RFCs, simply go to the IETF 
> Diff tool:  https://tools.ietf.org/rfcdiff

tools.ietf.org and everything hosted there is deprecated. You’re better off 
using https://author-tools.ietf.org/iddiff

Here are URLs for the two diffs:

https://author-tools.ietf.org/diff?doc_1=rfc8919_2=draft-ginsberg-lsr-rfc8919bis-00
https://author-tools.ietf.org/diff?doc_1=rfc8920_2=draft-ppsenak-lsr-rfc8920bis-00

HTH,

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

Re: [Lsr] [Technical Errata Reported] RFC6823 (6995)

[Les Ginsberg (ginsberg)]

Acee -

I agree.

It appears the intent was to file it against RFC 823 (which BTW is Historic).

   Les

> -Original Message-
> From: Acee Lindem (acee) 
> Sent: Thursday, June 16, 2022 11:38 AM
> To: RFC Errata System ; Les Ginsberg (ginsberg)
> ; sprev...@cisco.com; imc.sh...@gmail.com;
> aretana.i...@gmail.com; j...@juniper.net; andrew-i...@liquid.tech;
> cho...@chopps.org; han...@gredler.at
> Cc: keepplayin...@gmail.com; lsr@ietf.org
> Subject: Re: [Lsr] [Technical Errata Reported] RFC6823 (6995)
> 
> This Errata should be summarily rejected as there is no such reference in RFC
> 6823. Perhaps, it was reported against the wrong RFC.
> 
> Thanks,
> Acee (as WG Co-Chair)
> 
> On 6/16/22, 5:13 AM, "Lsr on behalf of RFC Errata System"  boun...@ietf.org on behalf of rfc-edi...@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC6823,
> "Advertising Generic Information in IS-IS".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6995
> 
> --
> Type: Technical
> Reported by: keep 
> 
> Section: global
> 
> Original Text
> -
> [10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
>   Beranek and Newman Inc., August 1982.
> 
> Corrected Text
> --
> [10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
>   Beranek and Newman Inc., August 1982, not issued
> 
> Notes
> -
> RFC823 references IEN-209, which was not issued, and won't be
> (https://www.rfc-editor.org/ien/scanned/ien209.pdf). I encourage
> discussion of whether it should reference RFC827 instead.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
> 
> --
> RFC6823 (draft-ietf-isis-genapp-04)
> --
> Title   : Advertising Generic Information in IS-IS
> Publication Date: December 2012
> Author(s)   : L. Ginsberg, S. Previdi, M. Shand
> Category: PROPOSED STANDARD
> Source  : IS-IS for IP Internets
> Area: Routing
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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] [Technical Errata Reported] RFC6823 (6995)

[Acee Lindem (acee)]

This Errata should be summarily rejected as there is no such reference in RFC 
6823. Perhaps, it was reported against the wrong RFC.

Thanks,
Acee (as WG Co-Chair)  

On 6/16/22, 5:13 AM, "Lsr on behalf of RFC Errata System" 
 wrote:

The following errata report has been submitted for RFC6823,
"Advertising Generic Information in IS-IS".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6995

--
Type: Technical
Reported by: keep 

Section: global

Original Text
-
[10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
  Beranek and Newman Inc., August 1982.

Corrected Text
--
[10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
  Beranek and Newman Inc., August 1982, not issued

Notes
-
RFC823 references IEN-209, which was not issued, and won't be 
(https://www.rfc-editor.org/ien/scanned/ien209.pdf). I encourage discussion of 
whether it should reference RFC827 instead.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6823 (draft-ietf-isis-genapp-04)
--
Title   : Advertising Generic Information in IS-IS
Publication Date: December 2012
Author(s)   : L. Ginsberg, S. Previdi, M. Shand
Category: PROPOSED STANDARD
Source  : IS-IS for IP Internets
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
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] Thoughts about PUAs - are we not over-engineering?

[Voyer, Daniel]

Hi Gunter, see [DV]

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 

Date: Thursday, June 16, 2022 at 6:38 AM
To: Robert Raszuk 
Cc: Gyan Mishra , Dan Voyer , 
"draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" 
, 
draft-wang-lsr-prefix-unreachable-annoucement 
, "lsr@ietf.org" 

Subject: [EXT]RE: [Lsr] Thoughts about PUAs - are we not over-engineering?

Hi Robert, Peter, Bruno

You wrote:
“Aas there is no association between node_id (perhaps loopback) and SIDs (note 
that egress can use many SIDs) UPA really does not signal anything about SIDs 
reachability or liveness. “

Sure, but UPA signals that a locator is unreachable, would that not result for 
the SRv6 SID to become unreachable as well?

I understood that UPA have increased value add benefit when using with SRv6. If 
suddenly a locator becomes unreachable, then it I guess the associated 128 bit 
SIDs become unreachable too, causing an event for something to happen in the 
transport network to fix the problem.

That being said, Peter makes a good point stating that UPA is not solving the 
problem of partitioning areas, and hence, maybe my use-case is not overly 
relevant.

So progressing, an operator using ABR based summarization then there are few 
options:

  1.  No summarization at all at ABRs
  2.  Summarize on ABR all prefixes that can be summarized
  3.  Summarize all prefixes that are not associated with PEs and remain 
advertising individual PE addresses
  4.  Summarize all prefixes and use UPA’s to advertise unreachability of 
protected prefixes

[DV] if “an operator using ABR based summarization” then option 1 is out, right 
? Also, option 4 is the point of this draft – but furthermore, if an 
aggregation device, inside a domain, is also being summarized – as the entire 
domain get summarized – but this agg device doesn’t have any services, because 
it’s an aggregation device, “then it’s up to the operator designing the network 
to implement” a form of policy/filter. So if that agg device reload, due to a 
maintenance, we don’t care about the unreachability advertisement (adding 
unnecessary LSP in the LSDB).

We all know that option 1 -3 work well and has been working well for long time. 
Behavior is very well understood

With the new option 4, to add value, applications need to get what is being 
referenced as ‘vendor secret sauce’ … I can already see the fun caused by 
inconsistent behavior and interop issues due to under specification.
[DV] not sure I am following your “secret sauce” point here. Following the 
RFC5305/RFC5308 should be clear.

The question I remain to have is if the UPA provide higher benefit as the tax 
it introduces. I can see operators suffer due to under specification, causing 
interop and inconsistent behaviors.


I agree with Bruno’s statement “If you believe that all you need is 
RFC5305/RFC5308 I guess this means that we don't need 
draft-ppsenak-lsr-igp-ureach-prefix-announce”


[DV] well, “draft-ppsenak-lsr-igp-ureach-prefix-announce”, is describing a use 
case/architecture and what you can do w/ RFC5305/RFC5308 – its “informational” 

G/


From: Robert Raszuk 
Sent: Thursday, June 16, 2022 11:54 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Gyan Mishra ; Voyer, Daniel 
; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Gunter,

(1) Multiple-ABRs

I was wondering for example if a ingress router receives a PUA signaling that a 
given locator becomes unreachable, does that actually really signals that the 
SID ‘really’ is unreachable for a router?

Aas there is no association between node_id (perhaps loopback) and SIDs (note 
that egress can use many SIDs) UPA really does not signal anything about SIDs 
reachability or liveness.

 For example (simple design to illustrate the corner-case):

ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
 |  |
 |  |
 +area#1---ABR#3---area---ABR#4---area#3+

What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a 
PUA/UPA.
How is ingressPE#1 supposed to handle this situation? The only thing 
ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may not 
have changed at all and remains perfectly reacheable.

Valid case. But PE1 should only switch when alternative backup path exists. If 
there is a single path it should do nothing in any case of receiving UPA. We 
have discussed that case before and as you know the formal answer was "out of 
scope" or "vendor's secret sauce" :).

The justification here is that switching to healthy backup is better then 
continue using perhaps semi-sick path.

Best,
R.


External Email: Please use caution 

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Robert Raszuk]

UPAs may not even contain the advertised locator in SIDs. That is not
clearly spelled out what exactly ABRs should advertise.

I presume:
a) something which was flooded in the local domain and was not being leaked
AND
b) something which stopped to be flooded in a local domain
AND
c) there is local policy specifying such range

 agree with Bruno’s statement “If you believe that all you need is
> RFC5305/RFC5308 I guess this means that we don't need
> draft-ppsenak-lsr-igp-ureach-prefix-announce”
>

Well at this time this is an Informational draft.

But based on Bruno's comments I am worried if any node receiving something
with MAX_PATH_METRIC which was not advertised before as valid and reachable
prefix and did not make it into LSDB or RIB/FIB will not simply introduce a
new unknown for the implementations state how to handle such prefix which
may result in different interesting undefined behaviour(s).

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

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Peter Psenak]

Hi Bruno,

please see inline (##PP2):


On 16/06/2022 12:01, bruno.decra...@orange.com wrote:

Hi Peter,

Thanks for your reply. Please see inline [Bruno2]



Orange Restricted


-Original Message-
From: Peter Psenak 
Sent: Thursday, June 16, 2022 11:22 AM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno,

thanks for your feedback, please see inline (##PP):

On 15/06/2022 16:09, bruno.decra...@orange.com wrote:

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it
can be made backward compatible and provides incremental benefits with
incremental deployment.

I also have two disagreements on the current draft. Both are minor IMO,
but authors may have a different opinion.

  1. This draft defines a new signaling from an egress ABR to all ingress
 ABR/PE. As such, this require all these nodes to agree on this
 signaling. So I’d call for a STD track document.


##PP
there is no new signalling defined in the draft. We are using what has
been defined in the RFC5305/RFC5308


[Bruno2] By "signaling", I did not meant "protocol extension". I meant "signaling of 
information". https://dictionary.cambridge.org/fr/dictionnaire/anglais/signal
Draft proposes an IGP announcement to signal something, more specifically that 
the prefix becomes unreachable


##PP2
yes, we are using the existing signaling method to signal the loss of 
reachability for the summary component.


  



  2. IMO, the behavior defined in this draft is not backward compatible
 with the specification of MAX_PATH_METRIC in an IP prefix.


##PP
I see no backward compatibility issue


RFC5305 says:

If a prefix is advertised with a metric larger then MAX_PATH_METRIC

(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered

during the normal SPF computation.This allows advertisement of a

prefix for purposes other than building the normal IP routing table.

As per the above, one (ABR) may (is allowed and free to do so) already
advertise both an aggregate prefix IP1/N with a regular metric and a
more specific prefix IP2/32 with MAX_PATH_METRIC.

With the above advertisement, all nodes compliant with RFC 5305 will
install IP1/N in their FIB and not consider IP2/32 during their SPF and
as a consequence not install it in their FIB.

In term of reachability, all nodes have IP reachability to all IP @ in
IP1 including IP2.

If one node now implements the draft, it will remove reachability for
IP2. And hence all my BGP routes using IPv2 for next-hop will be removed.


##PP
there is no such thing specified in the draft. What the drafts says is
that if the receiver is configured to do so, it can pass the UPA to the
applications that may be interested in it. How they act on it is outside
of the draft and ISIS as such.


[Bruno2] In the draft, I'm not seeing the text "if the receiver is configured to do 
so". That would be a useful change (even though not enough to me)


##PP2
sure, we can easily add that. That is the idea.

  

I'm not sure where did you get the "remove reachability for IP2".


[Bruno2] From the title "Unreachable Prefix Announcement".
1) I think we'll agree that there was reachability before the announcement.


##PP2
one that comes from the summary


2) the draft is about announcing that the "Prefix" becomes "Unreachable".
That seems to be "removing reachability for the prefix". I'm open to using a different 
terminology such as "Announcing the Prefix to be Unreachable" but I don't think that this 
would change the conclusion.

There is other text in the draft, such as "The functionality being described is 
called Unreachable Prefix Announcement (UPA)."


##PP2
yes, but you are talking forwarding. We only talk about signaling.







This looks clearly like a change in behavior to me, plus one which
introduce loss of reachability in an existing network.

3) The solution that I would suggest is:

- advertise the “unreachable prefix” with metric MAX_PATH_METRIC

- define a new “Extended Reachability Attribute Flags” ([RFC 7794])
explicitly signaling that the reachability to this prefix has been lost:

Unreachable Flag (U_flag). Set if this prefix is to be considered
unreachable.


##PP
I see no reason for the new flag. RFC5305/RFC5308 already provide a way
to signal unreachable prefix. That's all we need.


[Bruno2]
RFC5305/RFC5308 provides a way to advertise a prefix that "MUST NOT be considered during the 
normal SPF computation". That is different from "a way to signal unreachable prefix"


##PP2
RFC5305/RFC5308 says "allow advertisement of a prefix for purposes other 
than building the normal IPv4/v6 routing table"


We are just defining a new purpose why that may be done.



If you believe that all you need is RFC5305/RFC5308 I guess this means that we 
don't need draft-ppsenak-lsr-igp-ureach-prefix-announce


##PP2
What is 

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Hi Robert, Peter, Bruno

You wrote:
“Aas there is no association between node_id (perhaps loopback) and SIDs (note 
that egress can use many SIDs) UPA really does not signal anything about SIDs 
reachability or liveness. “

Sure, but UPA signals that a locator is unreachable, would that not result for 
the SRv6 SID to become unreachable as well?

I understood that UPA have increased value add benefit when using with SRv6. If 
suddenly a locator becomes unreachable, then it I guess the associated 128 bit 
SIDs become unreachable too, causing an event for something to happen in the 
transport network to fix the problem.

That being said, Peter makes a good point stating that UPA is not solving the 
problem of partitioning areas, and hence, maybe my use-case is not overly 
relevant.

So progressing, an operator using ABR based summarization then there are few 
options:

  1.  No summarization at all at ABRs
  2.  Summarize on ABR all prefixes that can be summarized
  3.  Summarize all prefixes that are not associated with PEs and remain 
advertising individual PE addresses
  4.  Summarize all prefixes and use UPA’s to advertise unreachability of 
protected prefixes

We all know that option 1 -3 work well and has been working well for long time. 
Behavior is very well understood

With the new option 4, to add value, applications need to get what is being 
referenced as ‘vendor secret sauce’ … I can already see the fun caused by 
inconsistent behavior and interop issues due to under specification.

The question I remain to have is if the UPA provide higher benefit as the tax 
it introduces. I can see operators suffer due to under specification, causing 
interop and inconsistent behaviors.


I agree with Bruno’s statement “If you believe that all you need is 
RFC5305/RFC5308 I guess this means that we don't need 
draft-ppsenak-lsr-igp-ureach-prefix-announce”

G/


From: Robert Raszuk 
Sent: Thursday, June 16, 2022 11:54 AM
To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
Cc: Gyan Mishra ; Voyer, Daniel 
; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Gunter,

(1) Multiple-ABRs

I was wondering for example if a ingress router receives a PUA signaling that a 
given locator becomes unreachable, does that actually really signals that the 
SID ‘really’ is unreachable for a router?

Aas there is no association between node_id (perhaps loopback) and SIDs (note 
that egress can use many SIDs) UPA really does not signal anything about SIDs 
reachability or liveness.

 For example (simple design to illustrate the corner-case):

ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
 |  |
 |  |
 +area#1---ABR#3---area---ABR#4---area#3+

What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a 
PUA/UPA.
How is ingressPE#1 supposed to handle this situation? The only thing 
ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may not 
have changed at all and remains perfectly reacheable.

Valid case. But PE1 should only switch when alternative backup path exists. If 
there is a single path it should do nothing in any case of receiving UPA. We 
have discussed that case before and as you know the formal answer was "out of 
scope" or "vendor's secret sauce" :).

The justification here is that switching to healthy backup is better then 
continue using perhaps semi-sick path.

Best,
R.

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

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Peter Psenak]

Hi Gunter,

please see inline (##PP):

On 16/06/2022 10:09, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:

Hi Gyan, Daniel, Peter, All,

Thanks for sharing your insights and I agree mostly with your feedback

I agree and understand that summarization is needed to reduce the size 
of the LSDB. I also agree summarization good design practice, especially 
with IPv6 and SRv6 in mind. There never has been doubt about that.


I am not sure I agree that UAP/UPA is ‘optimal-design’. Maybe it is the 
best we can do, however I have a healthy worry we could be suffering 
tunnel vision and that proposed solution may not be good enough.


We should not be blind and believe that advertising UPA/PUA does not 
come without a cost. The architectural PUA/UPA usage complexity cost may 
not be worth the effort (none of the integration of using a PUA/UPA 
event triggers come for free). Do we really believe that PUA/UPA solve 
all the SID reachability problems for all IGP network design and SR 
use-cases elegantly? Maybe some use-case design constraints and 
assumptions should be documented to clarify architecturally where 
PUA/UPA is most beneficial for operators? Just stating “outside scope of 
the draft” seems unfair to operators interested in PUA/UPAs


##PP
we are trying to solve a particular problem of remote PE going down in 
network where summarization is used. I believe that is stated clearly in 
the UPA draft.




Let me give two examples where PUA/UPA benefit is unclear:

(1) Multiple-ABRs

I was wondering for example if a ingress router receives a PUA signaling 
that a given locator becomes unreachable, does that actually really 
signals that the SID ‘really’ is unreachable for a router?


For example (simple design to illustrate the corner-case):

ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2

  |  |

  |  |

  +area#1---ABR#3---area---ABR#4---area#3+

What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?

In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate 
a PUA/UPA.


How is ingressPE#1 supposed to handle this situation? The only thing 
ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may 
not have changed at all and remains perfectly reacheable.


##PP
we are not trying to solve the area partitioning problem with UPA.

Clearly, if you summarize on both ABRs and your area partitions, you 
connectivity is broken, as you have no control on which ABR the traffic 
will use to enter the partitioned area. If you hit the one that has no 
connectivity to the egress PE, your traffic will be dropped.


With UPA, at least the service traffic can be switched to an alternate 
egress PE, if there is one, preserving the connectivity for the service 
prefixes.




(2) with sr-policy or SRv6 SRTE

What if we have an inter-area/domain/level SRTE or sr-policy and 
suddenly there is a PUA/UPA for one of the SIDs in the sid-list of the path.


will this impact the srte or sr-policy in any way? Will transit routers 
do anything with the UPA/PUA and drop packets. Will transit routers 
trigger fast-restoration?


##PP
we are not specifying any of that. If the implementation decide to use 
UPA on transit routers for some application, we do not prohibit it.




Can PCEs/controllers use the SID for crafting paths? Will all 
SRTE/sr-policy using the locator be pruned or re-signaled?


Will ingress router do something with the PUA information? Should 
PUA/UPA draft give guidelines around this?


##PP
UPA draft only describes the ISIS asignalling part, not the external 
application handling of the UPA. That would not be appropriate in IGP draft.


thanks,
Peter



Be well,

G/

If there is an SRTE or sr-policy using a given SID somewhere in the SID 
list… and suddenly


*From:*Gyan Mishra 
*Sent:* Thursday, June 16, 2022 6:12 AM
*To:* Voyer, Daniel 
*Cc:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 
; lsr@ietf.org

*Subject:* Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

Summarization has always been a best practice for network scalability 
thereby reducing the size of the RIB and LSDB.


So in this case as Dan pointed out,  the summary route is an abstraction 
of the area and so if a component prefix of the summary became 
unreachable we need a way to signal that the PE next hop is no longer 
reachable to help optimize convergence.


We are just trying to make summarization work better then it does today 
so we don’t have to rely on domain wide flooding of host routes.


Thanks

Gyan

On Wed, Jun 15, 2022 at 4:42 PM Voyer, Daniel 
> wrote:


Hi Gunter,

Thanks for your comments,

The idea, here, with summarization is to "reduce" the LSDB quite a
lots and make a 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Hi Peter,

Thanks for your reply. Please see inline [Bruno2]



Orange Restricted

> -Original Message-
> From: Peter Psenak  
> Sent: Thursday, June 16, 2022 11:22 AM
> To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
> Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce
> 
> Hi Bruno,
> 
> thanks for your feedback, please see inline (##PP):
> 
> On 15/06/2022 16:09, bruno.decra...@orange.com wrote:
> > Hi Peter, authors, all
> > 
> > Thanks for the draft. I find it a useful contribution to the problem space.
> > 
> > IMHO the use of MAX_PATH_METRIC is a good idea in particular since it 
> > can be made backward compatible and provides incremental benefits with 
> > incremental deployment.
> > 
> > I also have two disagreements on the current draft. Both are minor IMO, 
> > but authors may have a different opinion.
> > 
> >  1. This draft defines a new signaling from an egress ABR to all ingress
> > ABR/PE. As such, this require all these nodes to agree on this
> > signaling. So I’d call for a STD track document.
> 
> ##PP
> there is no new signalling defined in the draft. We are using what has 
> been defined in the RFC5305/RFC5308

[Bruno2] By "signaling", I did not meant "protocol extension". I meant 
"signaling of information". 
https://dictionary.cambridge.org/fr/dictionnaire/anglais/signal
Draft proposes an IGP announcement to signal something, more specifically that 
the prefix becomes unreachable
 
> 
> >  2. IMO, the behavior defined in this draft is not backward compatible
> > with the specification of MAX_PATH_METRIC in an IP prefix.
> 
> ##PP
> I see no backward compatibility issue
> > 
> > RFC5305 says:
> > 
> > If a prefix is advertised with a metric larger then MAX_PATH_METRIC
> > 
> > (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
> > 
> > during the normal SPF computation.This allows advertisement of a
> > 
> > prefix for purposes other than building the normal IP routing table.
> > 
> > As per the above, one (ABR) may (is allowed and free to do so) already 
> > advertise both an aggregate prefix IP1/N with a regular metric and a 
> > more specific prefix IP2/32 with MAX_PATH_METRIC.
> > 
> > With the above advertisement, all nodes compliant with RFC 5305 will 
> > install IP1/N in their FIB and not consider IP2/32 during their SPF and 
> > as a consequence not install it in their FIB.
> > 
> > In term of reachability, all nodes have IP reachability to all IP @ in 
> > IP1 including IP2.
> > 
> > If one node now implements the draft, it will remove reachability for 
> > IP2. And hence all my BGP routes using IPv2 for next-hop will be removed.
> 
> ##PP
> there is no such thing specified in the draft. What the drafts says is 
> that if the receiver is configured to do so, it can pass the UPA to the 
> applications that may be interested in it. How they act on it is outside 
> of the draft and ISIS as such.

[Bruno2] In the draft, I'm not seeing the text "if the receiver is configured 
to do so". That would be a useful change (even though not enough to me)
 
> I'm not sure where did you get the "remove reachability for IP2".

[Bruno2] From the title "Unreachable Prefix Announcement".
1) I think we'll agree that there was reachability before the announcement. 
2) the draft is about announcing that the "Prefix" becomes "Unreachable".
That seems to be "removing reachability for the prefix". I'm open to using a 
different terminology such as "Announcing the Prefix to be Unreachable" but I 
don't think that this would change the conclusion.

There is other text in the draft, such as "The functionality being described is 
called Unreachable Prefix Announcement (UPA)."

> 
> > 
> > This looks clearly like a change in behavior to me, plus one which 
> > introduce loss of reachability in an existing network.
> > 
> > 3) The solution that I would suggest is:
> > 
> > - advertise the “unreachable prefix” with metric MAX_PATH_METRIC
> > 
> > - define a new “Extended Reachability Attribute Flags” ([RFC 7794]) 
> > explicitly signaling that the reachability to this prefix has been lost:
> > 
> > Unreachable Flag (U_flag). Set if this prefix is to be considered 
> > unreachable.
> 
> ##PP
> I see no reason for the new flag. RFC5305/RFC5308 already provide a way 
> to signal unreachable prefix. That's all we need.

[Bruno2]
RFC5305/RFC5308 provides a way to advertise a prefix that "MUST NOT be 
considered during the normal SPF computation". That is different from "a way to 
signal unreachable prefix"

If you believe that all you need is RFC5305/RFC5308 I guess this means that we 
don't need draft-ppsenak-lsr-igp-ureach-prefix-announce

Thanks,
--Bruno
 
> thanks,
> Peter
> > 
> > This would allow for explicit signaling of the reachability (vs implicit 
> > currently) and would be backward compatible with existing specification 
> > and deployments.
> > 
> > Regards,
> > 
> > --Bruno
> > 
> > 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Robert Raszuk]

Bruno,

Actually I like your flag suggestion for an additional and different
reason.

If someone does not need to flood UPAs in any remote area it is trivial to
filter those on the ABRs connecting those areas to the core. Otherwise such
filtering could be more difficult if at all possible.

Thx,
R.


[Bruno] I agree that the encoding for the explicit signaling is totally
> open to discussion.
>
> I proposed a flag since:
>
> - all we need is a binary information
>
> - given the use case, this RFC7794 sub-tlv (type 4) seems likely to be
> already present. (e.g. X or R flag, possibly N-flag)
>
>
>
> Thanks for your email and your contribution to this topic.
>
> Best regards,
>
> --Bruno
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Robert Raszuk]

Gunter,

(1) Multiple-ABRs
>
>
>
> I was wondering for example if a ingress router receives a PUA signaling
> that a given locator becomes unreachable, does that actually really signals
> that the SID ‘really’ is unreachable for a router?
>

Aas there is no association between node_id (perhaps loopback) and SIDs
(note that egress can use many SIDs) UPA really does not signal anything
about SIDs reachability or liveness.


>  For example (simple design to illustrate the corner-case):
>
>
>
> ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
>
>  |  |
>
>  |  |
>
>  +area#1---ABR#3---area---ABR#4---area#3+
>
>
>
> What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
>
> In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a
> PUA/UPA.
>
> How is ingressPE#1 supposed to handle this situation? The only thing
> ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may
> not have changed at all and remains perfectly reacheable.
>

Valid case. But PE1 should only switch when alternative backup path exists.
If there is a single path it should do nothing in any case of receiving
UPA. We have discussed that case before and as you know the formal answer
was "out of scope" or "vendor's secret sauce" :).

The justification here is that switching to healthy backup is better then
continue using perhaps semi-sick path.

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

Re: [Lsr] Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding

[Robert Raszuk]

Hi Gyan,

While I agree with your final conclusion and description there is one
important detail missing.

PODs consist of both network elements and compute nodes. Virtualization
happens in the latter. Dynamic routing between those almost in all
cases talk BGP in the underlay not IGP simply as there is no great open
source IGP code to leverage to run link state protocol on the
compute nodes. We know that for over two decades. Some were eager to
produce ISIS-lite but to the best of my knowledge that never fully
surfaced (Yes there is ISIS and OSPFv2/v3 code in FRR or OSPF in BIRD, but
are those implementations ready for production scale ... not sure).

I would love to be corrected though and see any CNI deployment using ISIS.

Sure you can still interconnect clusters (collection of PODs) with IGP in
the underlay. But running IGP to computes I am unfortunately not seeing.

Thx,
Robert.




On Thu, Jun 16, 2022 at 6:42 AM Gyan Mishra  wrote:

>
> Hi Tony
>
> “So, can we PLEASE stop beating a dead horse?”
>
> As data center have evolved over the years prior to NVO overlay
> architectures becoming more prevalent, many operators had moved to from L2
> fault domains to an L3 POD based architecture carving the DC or MSDC into
> many smaller PODs sub domains where each POD is a BGP AS onto itself
> peering to a DCI core AS.
>
> From the DC POD architecture, operators have moved towards an NVO clos
> topology where  the size of the topology is not as massive as a single AS
> DC fabric, as now each POD becomes a fabric onto itself.  This does
> considerably reduce scope of the flooding as each POD is a BGP AS onto
> itself peering with a DCI core AS super spine.  As well within the POD, 2
> tier and now 3 or 4 tier micro fabrics within a POD can now further reduce
> the dense clos fabric as desired with scale up scale out as needed.  Each
> micro fabric could be carved up into mini AS or left as single AS per POD
> as desired.
>
> I  am sure there are BGP only MSDC installed base, however there are still
> plenty for of MSDC as I described above using POD architecture that have
> IGP based underlay that could definitely benefit from this draft.  As well
> operators with single AS MSDC that are not BGP Only that could take
> advantage of the draft.
>
>
> Kind Regards
>
> Gyan
>
>
> On Tue, Jun 14, 2022 at 5:01 PM Tony Li  wrote:
>
>>
>> Gyan,
>>
>> Cisco has (reportedly) implemented this, but done so with their own
>> proprietary, undocumented distributed algorithm.
>>
>> The responses that I have seen from operators have been somewhat
>> disappointing:
>>
>> “There is no  way that I would ever let a  IGP into
>> my data center.”
>>
>> Others have been more polite, but similarly dismissive.
>>
>> The fact of the matter is that there is an installed base of BGP and
>> folks are not open to experimenting with anything else.
>>
>> So, can we PLEASE stop beating a dead horse?
>>
>> Tony
>>
>>
>> On Jun 14, 2022, at 1:43 PM, Gyan Mishra  wrote:
>>
>> All
>>
>> I agree this is important work for operators in DC networks  NVO CLOS
>> architecture with extremely dense fabrics and massively scaled out spines.
>>
>> I agree we can move forward with progressing with only ISIS being
>> implemented.
>>
>> I do think that after the draft is published hopefully implementations
>> include OSPF as well as there is a lot of OSPF used by operators.
>>
>> NVO CLOS architecture I would say is being universally being deployed as
>> defacto standard  in the DC arena.  As well as most operators don’t want to
>> go for the BGP only solution in the DC due to the complexity as well as
>> having to provision many public ASNs.
>>
>> I support #1 first followed by #2.
>>
>> So far we have Arista implementation, and we have both Cisco and Juniper
>> Co-Authors as  well  on the draft.
>>
>> I think we have a good chance at #1 - Standards track.
>>
>> Les & Tony & Tony
>>
>> What is the chance of getting this implemented by Cisco & Juniper?
>>
>>
>> We also have a few major stakeholders in the industry supporting the
>> draft, Verizon, ATT and CenturyLink as co-authors which I think shows how
>> important this draft is for the industry.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Tue, Jun 14, 2022 at 4:05 PM John E Drake > 40juniper@dmarc.ietf.org> wrote:
>>
>>> Les,
>>>
>>> I'm happy with either 1 or 2.  It's good work and I think it will become
>>> important.
>>>
>>> Yours Irrespectively,
>>>
>>> John
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> > -Original Message-
>>> > From: Les Ginsberg (ginsberg) 
>>> > Sent: Tuesday, June 14, 2022 4:01 PM
>>> > To: John E Drake ; Les Ginsberg (ginsberg)
>>> > ; John Scudder 
>>> > Cc: Tony Li ; tom petch ; Acee
>>> Lindem
>>> > (acee) ; lsr@ietf.org
>>> > Subject: RE: [Lsr] Dynamic Flooding on Dense Graphs -
>>> draft-ietf-lsr-dynamic-
>>> > flooding
>>> >
>>> > [External Email. Be cautious of content]
>>> >
>>> >
>>> > John -
>>> >
>>> > I would be inclined to agree with you - but...to my knowledge 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Peter Psenak]

Hi Bruno,

thanks for your feedback, please see inline (##PP):

On 15/06/2022 16:09, bruno.decra...@orange.com wrote:

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it 
can be made backward compatible and provides incremental benefits with 
incremental deployment.


I also have two disagreements on the current draft. Both are minor IMO, 
but authors may have a different opinion.


 1. This draft defines a new signaling from an egress ABR to all ingress
ABR/PE. As such, this require all these nodes to agree on this
signaling. So I’d call for a STD track document.


##PP
there is no new signalling defined in the draft. We are using what has 
been defined in the RFC5305/RFC5308




 2. IMO, the behavior defined in this draft is not backward compatible
with the specification of MAX_PATH_METRIC in an IP prefix.


##PP
I see no backward compatibility issue



RFC5305 says:

If a prefix is advertised with a metric larger then MAX_PATH_METRIC

(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered

during the normal SPF computation.This allows advertisement of a

prefix for purposes other than building the normal IP routing table.

As per the above, one (ABR) may (is allowed and free to do so) already 
advertise both an aggregate prefix IP1/N with a regular metric and a 
more specific prefix IP2/32 with MAX_PATH_METRIC.


With the above advertisement, all nodes compliant with RFC 5305 will 
install IP1/N in their FIB and not consider IP2/32 during their SPF and 
as a consequence not install it in their FIB.


In term of reachability, all nodes have IP reachability to all IP @ in 
IP1 including IP2.


If one node now implements the draft, it will remove reachability for 
IP2. And hence all my BGP routes using IPv2 for next-hop will be removed.


##PP
there is no such thing specified in the draft. What the drafts says is 
that if the receiver is configured to do so, it can pass the UPA to the 
applications that may be interested in it. How they act on it is outside 
of the draft and ISIS as such.


I'm not sure where did you get the "remove reachability for IP2".




This looks clearly like a change in behavior to me, plus one which 
introduce loss of reachability in an existing network.


3) The solution that I would suggest is:

- advertise the “unreachable prefix” with metric MAX_PATH_METRIC

- define a new “Extended Reachability Attribute Flags” ([RFC 7794]) 
explicitly signaling that the reachability to this prefix has been lost:


Unreachable Flag (U_flag). Set if this prefix is to be considered 
unreachable.


##PP
I see no reason for the new flag. RFC5305/RFC5308 already provide a way 
to signal unreachable prefix. That's all we need.


thanks,
Peter


This would allow for explicit signaling of the reachability (vs implicit 
currently) and would be backward compatible with existing specification 
and deployments.


Regards,

--Bruno

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.



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

[Lsr] [Technical Errata Reported] RFC6823 (6995)

[RFC Errata System]

The following errata report has been submitted for RFC6823,
"Advertising Generic Information in IS-IS".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6995

--
Type: Technical
Reported by: keep 

Section: global

Original Text
-
[10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
  Beranek and Newman Inc., August 1982.

Corrected Text
--
[10] Rosen,  E.,  "Exterior  Gateway  Protocol,"  IEN-209,   Bolt
  Beranek and Newman Inc., August 1982, not issued

Notes
-
RFC823 references IEN-209, which was not issued, and won't be 
(https://www.rfc-editor.org/ien/scanned/ien209.pdf). I encourage discussion of 
whether it should reference RFC827 instead.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC6823 (draft-ietf-isis-genapp-04)
--
Title   : Advertising Generic Information in IS-IS
Publication Date: December 2012
Author(s)   : L. Ginsberg, S. Previdi, M. Shand
Category: PROPOSED STANDARD
Source  : IS-IS for IP Internets
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Gunter:

Thanks for your through thoughts.
For your mentioned case 1), the PUA draft has already the considerations: 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4

“If the nodes in the area receive the PUAM flood from all of its ABR
   routers, they will start BGP convergence process if there exist BGP
   session on this PUAM prefix.  The PUAM creates a forced fail over
   action to initiate immediate control plane convergence switchover to
   alternate egress PE.  Without the PUAM forced convergence the down
   prefix will yield black hole routing resulting in loss of
   connectivity.

   When only some of the ABRs can't reach the failure node/link, as that
   described in Section 3.2, the ABR that can reach the PUAM prefix
   should advertise one specific route to this PUAM prefix.  The
   internal routers within another area can then bypass the ABRs that
   can't reach the PUAM prefix, to reach the PUAM prefix.”

For your mentioned case 2), we think the transit receiver should do the local 
bypass if there is PLR configured, or the ingress router/PCE should switch the 
traffic to other path that can avoid the failure node. These are all 
applications of the PUA/UPA messages, and we can add some statements if 
necessary on the deployment considerations parts.

Aijun Wang
China Telecom

> On Jun 16, 2022, at 16:10, Van De Velde, Gunter (Nokia - BE/Antwerp) 
>  wrote:
> 
> 
> Hi Gyan, Daniel, Peter, All,
>  
> Thanks for sharing your insights and I agree mostly with your feedback
>  
> I agree and understand that summarization is needed to reduce the size of the 
> LSDB. I also agree summarization good design practice, especially with IPv6 
> and SRv6 in mind. There never has been doubt about that.
> I am not sure I agree that UAP/UPA is ‘optimal-design’. Maybe it is the best 
> we can do, however I have a healthy worry we could be suffering tunnel vision 
> and that proposed solution may not be good enough.
> We should not be blind and believe that advertising UPA/PUA does not come 
> without a cost. The architectural PUA/UPA usage complexity cost may not be 
> worth the effort (none of the integration of using a PUA/UPA event triggers 
> come for free). Do we really believe that PUA/UPA solve all the SID 
> reachability problems for all IGP network design and SR use-cases elegantly? 
> Maybe some use-case design constraints and assumptions should be documented 
> to clarify architecturally where PUA/UPA is most beneficial for operators? 
> Just stating “outside scope of the draft” seems unfair to operators 
> interested in PUA/UPAs
>  
> Let me give two examples where PUA/UPA benefit is unclear:
>  
> (1) Multiple-ABRs
>  
> I was wondering for example if a ingress router receives a PUA signaling that 
> a given locator becomes unreachable, does that actually really signals that 
> the SID ‘really’ is unreachable for a router?
>  
> For example (simple design to illustrate the corner-case):
>  
> ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
>  |  |
>  |  |
>  +area#1---ABR#3---area---ABR#4---area#3+
>  
> What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
> In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a 
> PUA/UPA.
> How is ingressPE#1 supposed to handle this situation? The only thing 
> ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may not 
> have changed at all and remains perfectly reacheable.
>  
>  
> (2) with sr-policy or SRv6 SRTE
> What if we have an inter-area/domain/level SRTE or sr-policy and suddenly 
> there is a PUA/UPA for one of the SIDs in the sid-list of the path.
> will this impact the srte or sr-policy in any way? Will transit routers do 
> anything with the UPA/PUA and drop packets. Will transit routers trigger 
> fast-restoration?
> Can PCEs/controllers use the SID for crafting paths? Will all SRTE/sr-policy 
> using the locator be pruned or re-signaled?
> Will ingress router do something with the PUA information? Should PUA/UPA 
> draft give guidelines around this?
>  
> Be well,
> G/
>  
>  
>  
>  
>  
>  
>  
> If there is an SRTE or sr-policy using a given SID somewhere in the SID list… 
> and suddenly
>  
>  
>  
> From: Gyan Mishra  
> Sent: Thursday, June 16, 2022 6:12 AM
> To: Voyer, Daniel 
> Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) 
> ; 
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
> draft-wang-lsr-prefix-unreachable-annoucement 
> ; lsr@ietf.org
> Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>  
>  
> Summarization has always been a best practice for network scalability thereby 
> reducing the size of the RIB and LSDB.  
>  
> So in this case as Dan pointed out,  the summary route is an abstraction of 
> the area and so if a component prefix of the 

Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS

[Jaideep Choudhary]

Hi Les,

Thanks for the response.
Yes, i understand that it would require a lot of efforts and can take some
years.

But as we discussed SYS ID 0 should  be considered valid as Standard
Documents doesn't define otherwise and at same time we should try to use a
logical value as a SYS ID so we don't create inter-operability issues where
a vendor doesn't consider it as valid.

"What reason did the customer give for configuring a systemid of 0?"

Customer had only a few Cisco nodes participating in the IS-IS , so they
started configuring the sys id .. then ..0001 and so on.

Thanks a lot for your time and understanding.

Regards
Jaideep


On Thu, 16 Jun, 2022, 12:57 am Les Ginsberg (ginsberg), 
wrote:

> Jaideep –
>
>
>
> I am not unsympathetic to problems encountered in the field.
>
> It isn’t always easy to get a customer to agree to what you and I might
> easily agree makes sense.
>
>
>
> But, in this case, consider what might be required to get an unambiguous
> standard defined:
>
>
>
> 1)We would have to establish consensus on whether 0 should/should not be
> considered as valid
>
>
>
> 2)We would have to get the vendors whose implementations do not conform to
> whatever is agreed upon in #1 to commit to changing their implementations
>
>
>
> 3)A standard would have to be written and work its way through the
> approval process. This would most practically be an IETF draft as there is
> no one actively updating ISO specs.
>
>
>
> All of this would take years – and at the end we would only have resolved
> the use of a systemid for which there is no practical deployment case.
>
>
>
> I just don’t think this is worth the effort.
>
>
>
> What reason did the customer give for configuring a systemid of 0?
>
>
>
>Les
>
>
>
> *From:* Jaideep Choudhary 
> *Sent:* Tuesday, June 14, 2022 11:59 PM
> *To:* Les Ginsberg (ginsberg) 
> *Subject:* Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS
>
>
>
> Hi Les,
>
>
>
> We have recently experienced some issue in this regards on a vendor where
> SYS ID of .. was not interpreted correctly.
>
>
>
> In a single area with level L1 and mutli-vendor setup, a Cisco node was
> configured with SYS I'd of ...
>
> The other vendor node could not interpret .. as a system id
> the way it does for other SYS IDs and there were some issues with the
> system level command outputs.
>
>
>
> Modifying the SYS id  on Cisco node did help, but it took a lot of time to
> find the cause.
>
>
>
> When I talked about routing issues, what I meant was, that if for example
> a Juniper node doesn't consider SYS ID of .. as legal, then it
> may not install the LSP from the node with SYS ID=0.
>
>
>
> If it is directly connected node, then Juniper node may not form adjacency
> and it can be found out easily, but if it is not directly connected node,
> then it would take good amount of time to find the cause.
>
>
>
> That in turn can cause some issues.
>
>
>
> I also agree 100% that it doesn't make sense to make a SYS ID of 0, but
> talking from an experience we had, it was configured.
>
>
>
> Since it is not defined as invalid as per standard documents, it also
> makes sense to have uniformity across different implementations, so no such
> issue occurs in multi-vendor setups.
>
>
>
> Also the reason of verifying this with IETF was to understand the reason
> behind Juniper defining sys I'd as illegal.
>
> We wanted to confirm if SYS ID 0 is reserved for some other use ?
>
>
>
> I hope , I am able to make my point here.
>
>
>
> Really appreciate your time.
>
> Thanks !
>
>
>
> Regards
>
> Jaideep
>
>
>
>
>
> On Wed, 15 Jun, 2022, 10:46 am Les Ginsberg (ginsberg), <
> ginsb...@cisco.com> wrote:
>
> (Taking this offlist – BCC the WG)
>
>
>
> Jaideep –
>
>
>
> From a standards perspective I have provided you with what I know.
>
>
>
> To characterize this as something which can cause “serious routing issues”
> is an exaggeration.
>
> Given that the same system ID cannot be used on more than one router, at
> worst if you were in a deployment where an implementation did not accept a
> systemid of , all you would need to do is modify the config of a single
> router.
>
>
>
> Assigning a systemid which has no relationship to the identity of the
> equipment/configuration of the node isn’t practical – I don’t think any
> thoughtful network manager would ever do such a thing.
>
> In my view you have lost perspective on this issue.
>
>
>
>Les
>
>
>
>
>
> *From:* Jaideep Choudhary 
> *Sent:* Tuesday, June 14, 2022 9:57 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Tony Li ; supp...@ietf.org; lsr@ietf.org
> *Subject:* Re: [Lsr] [rt5.ietf.org #7080] System ID in ISIS
>
>
>
> Hi Les,
>
>
>
> Thanks for the quick response.
>
>
> I also could not find anywhere in the standard documentation stating that
> SYS ID of .. in IS-IS as invalid nor is there any restriction
> to how to calculate the SYS ID.
>
>
>
> Yes, there are recommendations 

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Van De Velde, Gunter (Nokia - BE/Antwerp)]

Hi Gyan, Daniel, Peter, All,

Thanks for sharing your insights and I agree mostly with your feedback

I agree and understand that summarization is needed to reduce the size of the 
LSDB. I also agree summarization good design practice, especially with IPv6 and 
SRv6 in mind. There never has been doubt about that.
I am not sure I agree that UAP/UPA is ‘optimal-design’. Maybe it is the best we 
can do, however I have a healthy worry we could be suffering tunnel vision and 
that proposed solution may not be good enough.
We should not be blind and believe that advertising UPA/PUA does not come 
without a cost. The architectural PUA/UPA usage complexity cost may not be 
worth the effort (none of the integration of using a PUA/UPA event triggers 
come for free). Do we really believe that PUA/UPA solve all the SID 
reachability problems for all IGP network design and SR use-cases elegantly? 
Maybe some use-case design constraints and assumptions should be documented to 
clarify architecturally where PUA/UPA is most beneficial for operators? Just 
stating “outside scope of the draft” seems unfair to operators interested in 
PUA/UPAs

Let me give two examples where PUA/UPA benefit is unclear:

(1) Multiple-ABRs

I was wondering for example if a ingress router receives a PUA signaling that a 
given locator becomes unreachable, does that actually really signals that the 
SID ‘really’ is unreachable for a router?

For example (simple design to illustrate the corner-case):

ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
 |  |
 |  |
 +area#1---ABR#3---area---ABR#4---area#3+

What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a 
PUA/UPA.
How is ingressPE#1 supposed to handle this situation? The only thing 
ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may not 
have changed at all and remains perfectly reacheable.


(2) with sr-policy or SRv6 SRTE
What if we have an inter-area/domain/level SRTE or sr-policy and suddenly there 
is a PUA/UPA for one of the SIDs in the sid-list of the path.
will this impact the srte or sr-policy in any way? Will transit routers do 
anything with the UPA/PUA and drop packets. Will transit routers trigger 
fast-restoration?
Can PCEs/controllers use the SID for crafting paths? Will all SRTE/sr-policy 
using the locator be pruned or re-signaled?
Will ingress router do something with the PUA information? Should PUA/UPA draft 
give guidelines around this?

Be well,
G/







If there is an SRTE or sr-policy using a given SID somewhere in the SID list… 
and suddenly



From: Gyan Mishra 
Sent: Thursday, June 16, 2022 6:12 AM
To: Voyer, Daniel 
Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
draft-wang-lsr-prefix-unreachable-annoucement 
; lsr@ietf.org
Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?


Summarization has always been a best practice for network scalability thereby 
reducing the size of the RIB and LSDB.

So in this case as Dan pointed out,  the summary route is an abstraction of the 
area and so if a component prefix of the summary became unreachable we need a 
way to signal that the PE next hop is no longer reachable to help optimize 
convergence.

We are just trying to make summarization work better then it does today so we 
don’t have to rely on domain wide flooding of host routes.

Thanks

Gyan


On Wed, Jun 15, 2022 at 4:42 PM Voyer, Daniel 
mailto:40bell...@dmarc.ietf.org>> wrote:
Hi Gunter,

Thanks for your comments,

The idea, here, with summarization is to "reduce" the LSDB quite a lots and 
make a given backbone much more scalable / flexible and allow to simplify NNI's 
within that given backbones considerably.
Summarization is "needed" for better scale and, in the context of IPv6, will 
help in preventing blowing up the IGP.  With the size of an IPv6 prefix range 
(ex. /64) allocated per domain - summarization will help to contain the LSDB to 
that domain.

What we are "highlighting" in draft-ppsenak-lsr-igp-ureach-prefix-announce-00, 
is an easy way to overcome the fact that PEs are hidden behind a summary route 
and need a fast way to notify other PEs when they become unreachable.

I don't see "over-engineering" here, I see "optimal-engineering" instead.

Thanks
Dan

On 2022-06-14, 4:59 AM, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
mailto:gunter.van_de_ve...@nokia.com>> wrote:

Hi All,

When reading both proposals about PUA's:
* draft-ppsenak-lsr-igp-ureach-prefix-announce-00
* draft-wang-lsr-prefix-unreachable-annoucement-09

The identified problem space seems a correct observation, and indeed 
summaries hide remote area network instabilities. It is one of the perceived 
benefits of using summaries. The 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Daniel, inline



Orange Restricted
From: Voyer, Daniel 
Sent: Wednesday, June 15, 2022 9:43 PM
To: DECRAENE Bruno INNOV/NET ; lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Bruno, inline

From: Bruno Decraene 
mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 12:27 PM
To: Dan Voyer mailto:daniel.vo...@bell.ca>>, 
"lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [EXT]RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Daniel,

I agree that the draft-ppsenak-lsr-igp-ureach-prefix-announce, is presented as 
"a use case"/informational.

My point is that IMO the draft changes the behavior defined in RFC5305/RFC5308.
Indeed, as per those two RFC, I'm allowed, today, to advertise a prefix with 
MAX_PATH_METRIC for a purposes other than building the normal IP routing table..
-a) As per RFC5305/RFC5308, my reading is that such advertisement does not 
change the reachability of this prefix. IOW it's reachable if there is an 
aggregate prefix.
-b) draft-ppsenak-lsr-igp-ureach-prefix-announce would change that and hence 
would change existing behavior in my network. i.e. the existing prefixes 
advertised with MAX_PATH_METRIC would become unreachable, breaking existing 
services.

[DV] but if MAX_PATH_METRIC gets triggered, it means an existing service got 
broken or else MAX_PATH_METRIC doesn't get triggered.

[Bruno] Agreed in the context of your draft. I disagree in the general case as 
RFC5305/08 allows the use if MAX_PATH_METRIC even if the PE is up and fully 
functional.

The trigger could that that a PE is going on maintenance or .. just crashed - 
nonetheless that PE vanished and with summarization other PEs from other area 
won't get notified resulting in "breaking" service if MAX_PATH_METRIC is not 
triggered - "in this proposal". We are just reusing an existing idea.

I don't see the big deal of defining a new flag for advertising this 
unreachability: the use case defined in 
draft-ppsenak-lsr-igp-ureach-prefix-announce requires a new implementation on 
all (ingress) PEs and ABRs. Given this, what's the cost having those new 
implementation also advertising a sub-TLV/flag?

[DV] it only requires support for RFC5305/RFC5308 - hence why I am asking 
what's missing in those 2 RFC ? Basically, if I ignore 
"draft-ppsenak-lsr-igp-ureach-prefix-announce" since it's only informational, 
and wanted to do these RFCs - what's missing ?


[Bruno] There is nothing wrong with RFC5305/08.
To make it clear: on the receiver side, 
draft-ppsenak-lsr-igp-ureach-prefix-announce is not backward compatible with 
all/existing usages of MAX_PATH_METRIC as defined/allowed by RFC5305. E.g. the 
one I described in my original email.
Please review my above text and in particular the two cases "a" and "b" 
highlighted in yellow: For the same IGP advertisement from the egress (ABR) the 
behavior are different and even opposite: reachability UP for "a)"/RFC5305; 
reachability DOWN for "b)"/ draft-ppsenak-lsr-igp-ureach-prefix-announce. If 
you disagree with this reasoning, please explain why.
If you, as a network operator, wants to implement this non interoperable 
behavior in your network IGP, you are free to do so.
If an implementation that is deployed in a network that I care, implements this 
non interoperable behavior by default, and hence deliberately decide to break 
the existing behavior, for sure I'll complain to this vendor. Especially since 
the solution could easily be fixed at no cost.

Thanks,
Cheers,
--Bruno


Orange Restricted
From: Voyer, Daniel mailto:daniel.vo...@bell.ca>>
Sent: Wednesday, June 15, 2022 6:06 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; 
lsr@ietf.org
Subject: RE: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Bruno,

Thanks for your comment on the draft. I too, have a minor disagreement on your 
disagreement.

The draft-ppsenak-lsr-igp-ureach-prefix-announce, is really presented as "a use 
case"/informational. In this case, a PE being hidden from other area due to 
route summarization. The draft is not meant to "invent" something new, hence 
the reference to RFC5305/RFC5308.

If you jump to RFC5308 (as we are looking at IPv6 here), the advertising 
mechanism is well describe. What's missing from RFC5308 from your view point ?

Thanks
Dan

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Bruno Decraene mailto:bruno.decra...@orange.com>>
Date: Wednesday, June 15, 2022 at 10:09 AM
To: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [EXT][Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be 
made backward compatible and provides incremental benefits with incremental 
deployment.

I also have two disagreements on the current draft. Both are minor IMO, but 
authors may have a 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[bruno.decraene]

Hi Aijun,



Orange Restricted
From: Aijun Wang 
Sent: Thursday, June 16, 2022 1:59 AM
To: DECRAENE Bruno INNOV/NET 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

Hi, Bruno:

I agree with your thoughts on the solutions to this questions.

Actually, this is the reason that we brought up the thread “Convergence of 
Prefixes Unreachable Announcement Proposal” and I think you can review the 
discussion of this thread again.

And, in the mail 
https://mailarchive.ietf.org/arch/msg/lsr/qZ87Kjc9RdSsNpXzpOu31g1dSR0/, we have 
the following statements:
“ Anyway, to make the UPA mechanism take effect, you will also require the 
router be upgraded. And the “Max-Value” solution doesn’t necessarily indicate 
the prefix is lost. We should announce such information explicitly.”


[Bruno] Yes we seem to be in agreement on this point.

Whether defining a new flag or use the prefix originator information(as adopt 
by  
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4)
  to indicate explicitly the prefix is unreachable can be further discussed.

[Bruno] I agree that the encoding for the explicit signaling is totally open to 
discussion.
I proposed a flag since:
- all we need is a binary information
- given the use case, this RFC7794 sub-tlv (type 4) seems likely to be already 
present. (e.g. X or R flag, possibly N-flag)

Thanks for your email and your contribution to this topic.
Best regards,
--Bruno

Aijun Wang
China Telecom


On Jun 15, 2022, at 22:09, 
bruno.decra...@orange.com wrote:

Hi Peter, authors, all

Thanks for the draft. I find it a useful contribution to the problem space.

IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be 
made backward compatible and provides incremental benefits with incremental 
deployment.

I also have two disagreements on the current draft. Both are minor IMO, but 
authors may have a different opinion.


1)  This draft defines a new signaling from an egress ABR to all ingress 
ABR/PE. As such, this require all these nodes to agree on this signaling. So 
I’d call for a STD track document.

2)  IMO, the behavior defined in this draft is not backward compatible with 
the specification of MAX_PATH_METRIC in an IP prefix.

RFC5305 says:
   If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
   during the normal SPF computation.  This allows advertisement of a
   prefix for purposes other than building the normal IP routing table.

As per the above, one (ABR) may (is allowed and free to do so) already 
advertise both an aggregate prefix IP1/N with a regular metric and a more 
specific prefix IP2/32 with MAX_PATH_METRIC.
With the above advertisement, all nodes compliant with RFC 5305 will install 
IP1/N in their FIB and not consider IP2/32 during their SPF and as a 
consequence not install it in their FIB.
In term of reachability, all nodes have IP reachability to all IP @ in IP1 
including IP2.

If one node now implements the draft, it will remove reachability for IP2. And 
hence all my BGP routes using IPv2 for next-hop will be removed.
This looks clearly like a change in behavior to me, plus one which introduce 
loss of reachability in an existing network.

3) The solution that I would suggest is:
- advertise the “unreachable prefix” with metric MAX_PATH_METRIC
- define a new  “Extended Reachability Attribute Flags” ([RFC 7794]) explicitly 
signaling that the reachability to this prefix has been lost:

Unreachable Flag (U_flag). Set if this prefix is to be considered 
unreachable.

This would allow for explicit signaling of the reachability (vs implicit 
currently) and would be backward compatible with existing specification and 
deployments.

Regards,
--Bruno


_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete 
this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.

Thank you.
___
Lsr mailing list
Lsr@ietf.org