Hi, Shraddha:
If there are a large number of CE-to-PE mix-homing scenarios, specifying
the master/backup relationship of egress protection is complex, which greatly
increases deployment complexity. Therefore, local protection is not applicable
to all scenarios. In addition, local protection also generates suboptimal
paths. Therefore, even if local protection is deployed, speeding up ingress PE
convergence is useful.
Regards
Zhibo
From: Lsr [mailto:[email protected]] On Behalf Of Shraddha Hegde
Sent: Friday, November 26, 2021 12:49 PM
To: Huzhibo <[email protected]>; Aijun Wang
<[email protected]>; 'Tony Li' <[email protected]>
Cc: 'Les Ginsberg (ginsberg)' <[email protected]>; 'Gyan Mishra'
<[email protected]>; 'Christian Hopps' <[email protected]>; 'lsr'
<[email protected]>; 'Acee Lindem (acee)' <[email protected]>; 'Tony Przygienda'
<[email protected]>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
Huzhibo,
Local protection is always executed on the node where failure occurs (for link
protection) and the previous node
(for node failure). You don’t really require the failure event to propagate to
another domain to trigger local protection.
Rgds
Shraddha
Juniper Business Use Only
From: Huzhibo
<[email protected]<mailto:[email protected]>>
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde <[email protected]<mailto:[email protected]>>; Aijun
Wang <[email protected]<mailto:[email protected]>>; 'Tony Li'
<[email protected]<mailto:[email protected]>>
Cc: 'Les Ginsberg (ginsberg)' <[email protected]<mailto:[email protected]>>;
'Gyan Mishra' <[email protected]<mailto:[email protected]>>; 'Christian
Hopps' <[email protected]<mailto:[email protected]>>; 'lsr'
<[email protected]<mailto:[email protected]>>; 'Acee Lindem (acee)'
<[email protected]<mailto:[email protected]>>; 'Tony Przygienda'
<[email protected]<mailto:[email protected]>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
[External Email. Be cautious of content]
Hi, Shraddha:
If you punch a hole in the summary, the other area nodes come to know about the
mid-point failure.---> Yes, you're right. Once any node knows about the
mid-point failure，It can execution local protection by looking up next sid to
fix SRv6 Policy reachability.
Thanks
Zhibo
From: Lsr [mailto:[email protected]] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang <[email protected]<mailto:[email protected]>>;
'Tony Li' <[email protected]<mailto:[email protected]>>
Cc: 'Les Ginsberg (ginsberg)' <[email protected]<mailto:[email protected]>>;
'Gyan Mishra' <[email protected]<mailto:[email protected]>>; 'Christian
Hopps' <[email protected]<mailto:[email protected]>>; 'lsr'
<[email protected]<mailto:[email protected]>>; 'Acee Lindem (acee)'
<[email protected]<mailto:[email protected]>>; 'Tony Przygienda'
<[email protected]<mailto:[email protected]>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
Aijun,
There are multiple possible solutions for the SR-Policy mid-point failure
scenario
1. Use anycast SID as mid-points for redundancy
2. Mid-point failure local protection by looking up next sid (This is
probably the one you pointed out)
3. E2E S-BFD for SR-Policy path liveness detection
If you punch a hole in the summary, the other area nodes come to know about the
mid-point failure
and remove the failed node reachability. It is not clear how that is solving
the SR-Policy liveness problem.
Rgds
Shraddha
Juniper Business Use Only
From: Aijun Wang <[email protected]<mailto:[email protected]>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde <[email protected]<mailto:[email protected]>>; 'Tony
Li' <[email protected]<mailto:[email protected]>>
Cc: 'Les Ginsberg (ginsberg)' <[email protected]<mailto:[email protected]>>;
'Gyan Mishra' <[email protected]<mailto:[email protected]>>; 'Christian
Hopps' <[email protected]<mailto:[email protected]>>; 'lsr'
<[email protected]<mailto:[email protected]>>; 'Acee Lindem (acee)'
<[email protected]<mailto:[email protected]>>; 'Tony Przygienda'
<[email protected]<mailto:[email protected]>>
Subject: RE: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
[External Email. Be cautious of content]
Hi, Shraddha:
If the traffic is steered via the SRv6 policy, the intermediate points should
also be protected. There are already one draft to propose the solution( please
refer to
https://datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chen-rtgwg-srv6-midpoint-protection-05__;!!NEt6yMaO-gk!SSAVRO90Q62ieX5DTTgZBW4FKiC_YHXU9biL8pK-jEOUv7jmUHGUaHAt89kXBaSb$>.)
In such situation, if the intermediate points located in different areas, how
then know the liveness of each other if ABR has the summary address advertised?
We will not consider to configure BFD on every intermediate points.
Best Regards
Aijun Wang
China Telecom
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li <[email protected]<mailto:[email protected]>>; Aijun Wang
<[email protected]<mailto:[email protected]>>
Cc: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
Gyan Mishra <[email protected]<mailto:[email protected]>>; Christian
Hopps <[email protected]<mailto:[email protected]>>; lsr
<[email protected]<mailto:[email protected]>>; Acee Lindem (acee)
<[email protected]<mailto:[email protected]>>; Tony Przygienda
<[email protected]<mailto:[email protected]>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
WG,
MPLS egress protection framework RFC 8679 provides a mechanism to locally
protect the traffic during
PE failures. The concepts can be applied to SRv6 as well. This mechanism is
much more efficient and quick because it locally provides fast protection
And switchover to the other PE.
If you compare this to the mechanisms being discussed in this thread where
the failure information is being
propagated by the egress PE to ABR and then ABR to the ingress, the failover
is going to be much slower.
The egress protection technology does not flood any information outside of the
domain and hence does not
affect the IGP scale.
This is a valid alternate solution to solve the problem at hand IMO.
I would be interested to see if people have use cases where egress protection
can’t be applied.
Rgds
Shraddha
Juniper Business Use Only
From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Tony
Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang <[email protected]<mailto:[email protected]>>
Cc: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
Gyan Mishra <[email protected]<mailto:[email protected]>>; Christian
Hopps <[email protected]<mailto:[email protected]>>; lsr
<[email protected]<mailto:[email protected]>>; Acee Lindem (acee)
<[email protected]<mailto:[email protected]>>; Tony Przygienda
<[email protected]<mailto:[email protected]>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR
Meeting Minutes
[External Email. Be cautious of content]
Hi Aijun,
I object to adding negative liveness to the LSDB because of the scale and
because it adds scale during failures.
[WAJ] If we have no such mechanism, operator should either advertise the host
routes across areas(which has scale problem), or lose the fast convergences for
some overlay services(which defeat the user experiences).
Within the real network, there is very rare chance for the massive failure. And
even such thing happen accidently, the information about node liveness is
countable, is there any router can’t process such information?
The received unreachable information does not trigger the SPF calculation. Will
they influence intensively the performance of the router?
If the scale is equal, then I would prefer to see flooding positive information
rather than negative information. Operationally this is key: if there is a
failure and positive information doesn’t propagate, then it’s a bug that will
be found in due course and the operator can react outside of a failure scenario.
Having a scale failure on top of a topology failure is a far more painful
scenario.
The odds of a mass failure may be low. The fact of the matter is that they
still happen. It is our job to ensure that the IGP performs well when it does.
Increasing the size of the LSDB always affects performance. It slows flooding.
Some nodes may not realize that SPF is not needed. When LSP fragments are
rearranged, inferring that SPF is not necessary is non-trivial. Impacting
router and network performance is a given.
My understanding is that N node failures would result in O(N) bytes added to
the LSDB. If someone has a way to compress that information to O(1), I (and
Claude Shannon) would be interested.
[WAJ] Do you have other determined solutions except the PUB/SUB mechanism that
does not exist in current IGP?
None of the mechanisms being discussed currently exist.
I have no objections to Robert’s BGP propagation ideas if that’s workable.
This is simply not the IGP’s job and the IGP is not a dump truck.
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
