Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Aijun,

[WAJ] For SRv6 policy based tunnel, the previous node may not be the
> neighbor node. It may locate in other area.
>

Only in the case of binding SIDs on the penultimate segment endpoint such
signalling would perhaps help.

In all other cases the information MUST be propagated to the ingress node
which applies a full SID list. And that IMHO is a role of SR inband OAM not
IGP especially when you are crossing areas.

Many thx,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi,Shraddha:

Aijun Wang
China Telecom

> On Nov 26, 2021, at 12:49, Shraddha Hegde  wrote:
> 
> 
> Huzhibo,
>  
> Local protection is always executed on the node where failure occurs (for 
> link protection) and the previous node
> (for node failure).
[WAJ] For SRv6 policy based tunnel, the previous node may not be the neighbor 
node. It may locate in other area.
> 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  
> Sent: Thursday, November 25, 2021 3:04 PM
> To: Shraddha Hegde ; Aijun Wang 
> ; 'Tony Li' 
> Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
> ; 'Christian Hopps' ; 'lsr' 
> ; 'Acee Lindem (acee)' ; 'Tony Przygienda' 
> 
> 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:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
> Sent: Thursday, November 25, 2021 12:11 PM
> To: Aijun Wang ; 'Tony Li' 
> Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
> ; 'Christian Hopps' ; 'lsr' 
> ; 'Acee Lindem (acee)' ; 'Tony Przygienda' 
> 
> 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
> Use anycast SID as mid-points for redundancy
> Mid-point failure local protection by looking up next sid (This is probably 
> the one you pointed out)
> 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  
> Sent: Wednesday, November 24, 2021 11:14 AM
> To: Shraddha Hegde ; 'Tony Li' 
> Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
> ; 'Christian Hopps' ; 'lsr' 
> ; 'Acee Lindem (acee)' ; 'Tony Przygienda' 
> 
> 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.)
>   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: lsr-boun...@ietf.org  On Behalf Of Shraddha Hegde
> Sent: Wednesday, November 24, 2021 1:20 PM
> To: Tony Li ; Aijun Wang 
> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
> ; Christian Hopps ; lsr 
> ; Acee Lindem (acee) ; Tony Przygienda 
> 
> 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  On Behalf Of Tony Li
> Sent: Tuesday, November 23, 2021 10:22 PM
> To: Aijun Wang 
> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
> ; Christian Hopps ; lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Huzhibo,

> specifying the master/backup relationship of egress protection is complex

Sure is - but there is absolutely no requirement to do it. BGP already
carries all information needed to instantiate such protection. It is
therefore all dynamic and automated.

As said cost is extra LFIB space on the PEs acting as a backup. With per
VRF or per CE label allocation that is not big deal. With per prefix label
allocation yes that can be a resource constraint to consider.

So if we are discussing drawbacks of any proposal let's just use correct
arguments :)

Cheers,
R.






On Fri, Nov 26, 2021 at 9:09 AM Huzhibo 
wrote:

> 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:lsr-boun...@ietf.org] *On Behalf Of *Shraddha Hegde
> *Sent:* Friday, November 26, 2021 12:49 PM
> *To:* Huzhibo ; Aijun Wang <
> wangai...@tsinghua.org.cn>; 'Tony Li' 
> *Cc:* 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' <
> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' <
> lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' <
> tonysi...@gmail.com>
> *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 
> *Sent:* Thursday, November 25, 2021 3:04 PM
> *To:* Shraddha Hegde ; Aijun Wang <
> wangai...@tsinghua.org.cn>; 'Tony Li' 
> *Cc:* 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' <
> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' <
> lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' <
> tonysi...@gmail.com>
> *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:lsr-boun...@ietf.org ] *On
> Behalf Of *Shraddha Hegde
> *Sent:* Thursday, November 25, 2021 12:11 PM
> *To:* Aijun Wang ; 'Tony Li' 
> *Cc:* 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' <
> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' <
> lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' <
> tonysi...@gmail.com>
> *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 
> *Sent:* Wednesday, November 24, 2021 11:14 AM
> *To:* Shraddha Hegde ; 'Tony Li' 
> *Cc:* 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' <
> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' <
> lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' <
> tonysi...@gmail.com>
> *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 prop

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huzhibo]

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:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Friday, November 26, 2021 12:49 PM
To: Huzhibo ; Aijun Wang 
; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

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 
mailto:huzhibo=40huawei@dmarc.ietf.org>>
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; Aijun 
Wang mailto:wangai...@tsinghua.org.cn>>; 'Tony Li' 
mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
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:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Tony Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
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 mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 'Tony 
Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
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: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Shraddha Hegde]

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 
Sent: Thursday, November 25, 2021 3:04 PM
To: Shraddha Hegde ; Aijun Wang 
; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

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:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>; 
'Tony Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
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 mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 'Tony 
Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
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: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Understood as this egress protection framework applies to all current and
future protocols, however if you are using RSVP-TE which in most cases you
are today with converged transport aggregation domain then you would use
the RFC 8400 extension.

Happy Thanksgiving!旅

Gyan

On Thu, Nov 25, 2021 at 11:33 AM Robert Raszuk  wrote:

>
> RFC 8679 does not require RSVP-TE to work.
>
> Best,
> R.
>
>
> On Thu, Nov 25, 2021 at 5:30 PM Gyan Mishra  wrote:
>
>>
>> Hi Shraddha
>>
>> The  PUA draft is detecting the BGP  NH liveliness based on the PUA
>> protection mechanism for immediate  control plane convergence immediately
>> on alternative next - next hop, analogous to FRR link and node protection
>> but without the complexity.
>>
>> I agree the egress protection RFC 8679  mechanism using RSVP-TE Egress
>> protection extension RFC 8400 can provide fast  FRR link and mode
>> protection mechanism for global repair but at a operational cost of RSVP-TE
>> FRR protection schemes which may or may not be deployed by the operator.
>>
>> The PUA and event notification drafts provide a simple IGP extension
>> based mechanism to provide the same and can be utilized in scenarios where
>> RSVP-TE may not be deployed or desirable.  I agree in most cases  large
>> aggregation domains converged  transport networks with MPLS-TP transport
>> core that RSVP-TE is deployed.
>>
>> PUA provides next hop  liveliness detection and protection that can be
>> applied to SRv6 SR-TE policy as well, similar to what S-BFD SR-TE policy
>> liveliness, this PUA draft is providing similar via next hop liveliness in
>> protecting the egress PE SRv6 SR-TE policy.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Wed, Nov 24, 2021 at 11:10 PM Shraddha Hegde 
>> wrote:
>>
>>> 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 
>>> *Sent:* Wednesday, November 24, 2021 11:14 AM
>>> *To:* Shraddha Hegde ; 'Tony Li' 
>>> *Cc:* 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' <
>>> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' <
>>> lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda'
>>> 
>>> *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:* lsr-boun...@ietf.org  *On Behalf Of *Shraddha
>>> Hegde
>>> *Sent:* Wednesday, November 24, 2021 1:20 PM
>>> *To:* Tony Li ; Aijun Wang 
>>> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
>>> hayabusa...@gmail.com>; Christian Hopps ; lsr <
>>> lsr@ietf.org>; Acee

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

RFC 8679 does not require RSVP-TE to work.

Best,
R.


On Thu, Nov 25, 2021 at 5:30 PM Gyan Mishra  wrote:

>
> Hi Shraddha
>
> The  PUA draft is detecting the BGP  NH liveliness based on the PUA
> protection mechanism for immediate  control plane convergence immediately
> on alternative next - next hop, analogous to FRR link and node protection
> but without the complexity.
>
> I agree the egress protection RFC 8679  mechanism using RSVP-TE Egress
> protection extension RFC 8400 can provide fast  FRR link and mode
> protection mechanism for global repair but at a operational cost of RSVP-TE
> FRR protection schemes which may or may not be deployed by the operator.
>
> The PUA and event notification drafts provide a simple IGP extension based
> mechanism to provide the same and can be utilized in scenarios where
> RSVP-TE may not be deployed or desirable.  I agree in most cases  large
> aggregation domains converged  transport networks with MPLS-TP transport
> core that RSVP-TE is deployed.
>
> PUA provides next hop  liveliness detection and protection that can be
> applied to SRv6 SR-TE policy as well, similar to what S-BFD SR-TE policy
> liveliness, this PUA draft is providing similar via next hop liveliness in
> protecting the egress PE SRv6 SR-TE policy.
>
> Kind Regards
>
> Gyan
>
> On Wed, Nov 24, 2021 at 11:10 PM Shraddha Hegde 
> wrote:
>
>> 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 
>> *Sent:* Wednesday, November 24, 2021 11:14 AM
>> *To:* Shraddha Hegde ; 'Tony Li' 
>> *Cc:* 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' <
>> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' <
>> lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' <
>> tonysi...@gmail.com>
>> *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:* lsr-boun...@ietf.org  *On Behalf Of *Shraddha
>> Hegde
>> *Sent:* Wednesday, November 24, 2021 1:20 PM
>> *To:* Tony Li ; Aijun Wang 
>> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
>> hayabusa...@gmail.com>; Christian Hopps ; lsr <
>> lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda <
>> tonysi...@gmail.com>
>> *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 ingre

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Hi Shraddha

The  PUA draft is detecting the BGP  NH liveliness based on the PUA
protection mechanism for immediate  control plane convergence immediately
on alternative next - next hop, analogous to FRR link and node protection
but without the complexity.

I agree the egress protection RFC 8679  mechanism using RSVP-TE Egress
protection extension RFC 8400 can provide fast  FRR link and mode
protection mechanism for global repair but at a operational cost of RSVP-TE
FRR protection schemes which may or may not be deployed by the operator.

The PUA and event notification drafts provide a simple IGP extension based
mechanism to provide the same and can be utilized in scenarios where
RSVP-TE may not be deployed or desirable.  I agree in most cases  large
aggregation domains converged  transport networks with MPLS-TP transport
core that RSVP-TE is deployed.

PUA provides next hop  liveliness detection and protection that can be
applied to SRv6 SR-TE policy as well, similar to what S-BFD SR-TE policy
liveliness, this PUA draft is providing similar via next hop liveliness in
protecting the egress PE SRv6 SR-TE policy.

Kind Regards

Gyan

On Wed, Nov 24, 2021 at 11:10 PM Shraddha Hegde 
wrote:

> 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 
> *Sent:* Wednesday, November 24, 2021 11:14 AM
> *To:* Shraddha Hegde ; 'Tony Li' 
> *Cc:* 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' <
> hayabusa...@gmail.com>; 'Christian Hopps' ; 'lsr' <
> lsr@ietf.org>; 'Acee Lindem (acee)' ; 'Tony Przygienda' <
> tonysi...@gmail.com>
> *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:* lsr-boun...@ietf.org  *On Behalf Of *Shraddha
> Hegde
> *Sent:* Wednesday, November 24, 2021 1:20 PM
> *To:* Tony Li ; Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Christian Hopps ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda <
> tonysi...@gmail.com>
> *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  *On Behalf Of *Tony Li
> *Sent:* Tuesday, November 23, 2021 10:22 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gya

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Hi Aijun,

> #3
>
> > [WAJ] It is the IGP advertises the inaccurate information, why let BGP
> clear up? Won’t you estimate the IDR experts will resist?
>
> There is nothing inaccurate in the IGP advertisement. IGP does
> precisely what the operator configured it to do.
>
> [WAJ] It lack some more precise control mechanisms. Currently it can only
> allow all, or advertise all.
>


Yes - and this is a good problem to be fixed. To me this is day one spec
bug.

Leaking should not be sender, but receiver driven. In fact one could also
argue that leaking does not need to be flooded, but send by IGP as unicast.
Maybe using reflection for scalability.

I think no one here will object to fixing it. However if you want to break
what is working fine (even if only during rear and stressful moments to the
IGP) that is not the right approach.

[WAJ] First, the reachable underlay information is not advertised via BGP.
>

I am talking about building hierarchy.

You have:

#3 - NLRI: Service Routing with PE_NH (BGP)
#2 - NLRI: PE_NH advertisement with ABR as NH (BGP)
#1 - ABR IGP underlay (with summaries) (IGP)

Thinking more on this #2 perhaps can use BGP-LS (maybe first decent use
case for this SAFI :)

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huzhibo]

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:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Thursday, November 25, 2021 12:11 PM
To: Aijun Wang ; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

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 mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 'Tony 
Li' mailto:tony...@tony.li>>
Cc: 'Les Ginsberg (ginsberg)' mailto:ginsb...@cisco.com>>; 
'Gyan Mishra' mailto:hayabusa...@gmail.com>>; 'Christian 
Hopps' mailto:cho...@chopps.org>>; 'lsr' 
mailto:lsr@ietf.org>>; 'Acee Lindem (acee)' 
mailto:a...@cisco.com>>; 'Tony Przygienda' 
mailto:tonysi...@gmail.com>>
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: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
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 mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
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 converge

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huzhibo]

Hi Shraddha:
 MPLS egress protection is a FRR mechanism, PUA is a hard convergence 
mechanism. I don't think there's a conflict between the two solution.
Also, as far as I know, MPLS egress protection has not been deployed on a large 
scale.

Thanks

Zhibo

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li ; Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

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 mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Shraddha Hegde]

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 
Sent: Wednesday, November 24, 2021 11:14 AM
To: Shraddha Hegde ; 'Tony Li' 
Cc: 'Les Ginsberg (ginsberg)' ; 'Gyan Mishra' 
; 'Christian Hopps' ; 'lsr' 
; 'Acee Lindem (acee)' ; 'Tony Przygienda' 

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: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> 
mailto:lsr-boun...@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li mailto:tony...@tony.li>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
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 mailto:lsr-boun...@ietf.org>> On Behalf Of Tony 
Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Gyan Mishra mailto:hayabusa...@gmail.com>>; Christian 
Hopps mailto:cho...@chopps.org>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 25, 2021, at 07:35, Robert Raszuk  wrote:
> 
> 
> Hi Aijun,
> 
> Just few points to your note. 
> 
> #1 
> 
> > when ABR does the summary work
> 
> In a lot of your emails you keep stating that ABR or IGPs do summarization. 
> Well that is not true. It is operators which configure the summarization. 
> 
> It is important to recognize this difference. 
> 
> It is also operators who configure leaking for a subset of area routes. 
> 
> When you configure a summary half of the addresses may be not even 
> configured. ABRs do nothing about it. 

[WAJ] OK. The operator let the ABR do something. If we follow this logic, I 
think these configuration act as the ACL of the prefixes. Won’t some thing 
likes the following let the work of operator easier?
#Deny one
#Permit All

And, we also can think further under this POV: the IGP itself cannot meet all 
the scale requirements. The network design, the operator intervention are all 
key factors for this aim. Then why you and Tony assert that advertise the 
necessary negative information will significantly degrade the scalability of 
IGP? I think they are similar with the positive information.

> 
> 
> #2 
> 
> > As we have discussed on the list, there is no other better solution to 
> > solve the problem.
> 
> Of course there are. Bunch of them in fact. Trivial to demonstrate too in 
> shipping code. 

[WAJ] Please illustrate one of them that can solve the problems that we 
mentioned simultaneously. For example, the liveness of BGP PEER, the liveness 
of SRv6 intermediate points .

> 
> But neither lack nor presence of alternative solutions is a valid 
> justification to any protocol extension. 

[WAJ] Then, what is the valid justification?

> 
> 
> #3
> 
> > [WAJ] It is the IGP advertises the inaccurate information, why let BGP 
> > clear up? Won’t you estimate the IDR experts will resist?
> 
> There is nothing inaccurate in the IGP advertisement. IGP does precisely what 
> the operator configured it to do. 

[WAJ] It lack some more precise control mechanisms. Currently it can only allow 
all, or advertise all. 
> 
> BGP propagates service routes and if service is not up those routes should be 
> removed asap. I think this is clear to anyone. 

[WAJ] First, the reachable underlay information is not advertised via BGP. 
But we can still think further along your proposal: If the BGP advertise this 
host route is unreachable, but the IGP still think it has the knowledge to 
reach it, will this puzzle the router?

> 
> In addition BGP can also and with much better scaling properties to a link 
> state protocol withdraw next hops for such service routes which I am sure 
> will be much faster end to end then IGP. After all please consider that it is 
> also BGP which needs to trigger best path on all remote PEs to select 
> alternative path. 

[WAJ] The above action is for the overlay prefixes, not for underlying prefixes.

> 
> Last please tell me one person in IDR who will oppose to make BGP withdraws 
> go faster (if needed as personally if your configuration is rigth I believe 
> it is already fine - of course provided that you are using decent BGP 
> implementation all the way). 

[WAJ] BGP should be responsible for advertising and revoking of the prefixes 
that it advertised. It should not interfere with the information that other 
protocol advertised.
> 
> Kind regards,
> Robert
> 
> 
> 
> 
> 
> 
>> On Thu, Nov 25, 2021 at 12:14 AM Aijun Wang  
>> wrote:
>> Hi, Tony:
>> 
>> Aijun Wang
>> China Telecom
>> 
 On Nov 25, 2021, at 03:59, Tony Li  wrote:
 
>>> 
>>> 
>>> Hi Aijun,
>>> 
 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.
 [WAJ] What we want to do is the “Positive Summary”+” Specific Negative 
 Information”. This can have both the summary scale advantage and also 
 decrease the convergence time that based on the protocol hello timer.
>>> 
>>> 
>>> I do understand that.  Do you understand that I think that that’s a Really 
>>> Bad Idea?
>> [WAJ] No. As we have discussed on the list, there is no other better 
>> solution to solve the problem. Actually, when ABR does the summary work, it 
>> may overstate the reachable addresses. 
>> When the host is within the summary range but is not used, it’s OK.  But 
>> when the in-service host become unreachable and ABR knows this, it should 
>> give the other nodes the accurate information to assist them to switch to 
>> other services/backup points.
>> 
>>> 
>>> 
>>> 
  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 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Hi Aijun,

Just few points to your note.

#1

> when ABR does the summary work

In a lot of your emails you keep stating that ABR or IGPs do summarization.
Well that is not true. It is operators which configure the summarization.

It is important to recognize this difference.

It is also operators who configure leaking for a subset of area routes.

When you configure a summary half of the addresses may be not even
configured. ABRs do nothing about it.


#2

> As we have discussed on the list, there is no other better solution to
solve the problem.

Of course there are. Bunch of them in fact. Trivial to demonstrate too in
shipping code.

But neither lack nor presence of alternative solutions is a valid
justification to any protocol extension.


#3

> [WAJ] It is the IGP advertises the inaccurate information, why let BGP
clear up? Won’t you estimate the IDR experts will resist?

There is nothing inaccurate in the IGP advertisement. IGP does
precisely what the operator configured it to do.

BGP propagates service routes and if service is not up those routes should
be removed asap. I think this is clear to anyone.

In addition BGP can also and with much better scaling properties to a link
state protocol withdraw next hops for such service routes which I am sure
will be much faster end to end then IGP. After all please consider that it
is also BGP which needs to trigger best path on all remote PEs to select
alternative path.

Last please tell me one person in IDR who will oppose to make BGP withdraws
go faster (if needed as personally if your configuration is rigth I believe
it is already fine - of course provided that you are using decent BGP
implementation all the way).

Kind regards,
Robert






On Thu, Nov 25, 2021 at 12:14 AM Aijun Wang 
wrote:

> Hi, Tony:
>
> Aijun Wang
> China Telecom
>
> On Nov 25, 2021, at 03:59, Tony Li  wrote:
>
> 
>
> Hi Aijun,
>
> 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.
> *[WAJ] What we want to do is the “Positive Summary”+” Specific Negative
> Information”. This can have both the summary scale advantage and also
> decrease the convergence time that based on the protocol hello timer.*
>
>
>
> I do understand that.  Do you understand that I think that that’s a Really
> Bad Idea?
>
> [WAJ] No. As we have discussed on the list, there is no other better
> solution to solve the problem. Actually, when ABR does the summary work, it
> may overstate the reachable addresses.
> When the host is within the summary range but is not used, it’s OK.  But
> when the in-service host become unreachable and ABR knows this, it should
> give the other nodes the accurate information to assist them to switch to
> other services/backup points.
>
>
>
>
>  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.
> *[WAJ] PUAM does not increase the overall size of the LSDB. It utilizes
> the existing LSA/TLV/Sub-TLV.*
>
>
>
> You’re advertising bits that would not be otherwise advertised.  That
> increases the size of the LSDB.  Utilizing existing TLVs is irrelevant.
>
>
> [WAJ] No. OSPF/ISIS has been designed to be extensible to accommodate the
> newly necessary information. If we stick to your point, the fixed format
> LSA is sufficient.
>
>
>
> 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.
> *[WAJ] BGP is used within the internet, adding the false information
> within its protocol should be examined more carefully. As we have mentioned
> several times, the overall goals are not only for BGP usecaes, but also the
> prevailing Tunnel services.*
>
>
>
> Understood.  BGP is also not a dump truck, but has far better scaling
> properties, so is less likely to have catastrophic failures due to some
> negative information.
>
>
> [WAJ] It is the IGP advertises the inaccurate information, why let BGP
> clear up? Won’t you estimate the IDR experts will resist?
>
>
> T
>
>
> ___
> 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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 25, 2021, at 03:59, Tony Li  wrote:
> 
> 
> 
> Hi Aijun,
> 
>> 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.
>> [WAJ] What we want to do is the “Positive Summary”+” Specific Negative 
>> Information”. This can have both the summary scale advantage and also 
>> decrease the convergence time that based on the protocol hello timer.
> 
> 
> I do understand that.  Do you understand that I think that that’s a Really 
> Bad Idea?
[WAJ] No. As we have discussed on the list, there is no other better solution 
to solve the problem. Actually, when ABR does the summary work, it may 
overstate the reachable addresses. 
When the host is within the summary range but is not used, it’s OK.  But when 
the in-service host become unreachable and ABR knows this, it should give the 
other nodes the accurate information to assist them to switch to other 
services/backup points.

> 
> 
> 
>>  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.
>> [WAJ] PUAM does not increase the overall size of the LSDB. It utilizes the 
>> existing LSA/TLV/Sub-TLV.
> 
> 
> You’re advertising bits that would not be otherwise advertised.  That 
> increases the size of the LSDB.  Utilizing existing TLVs is irrelevant.

[WAJ] No. OSPF/ISIS has been designed to be extensible to accommodate the newly 
necessary information. If we stick to your point, the fixed format LSA is 
sufficient.

> 
> 
>> 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.
>> [WAJ] BGP is used within the internet, adding the false information within 
>> its protocol should be examined more carefully. As we have mentioned several 
>> times, the overall goals are not only for BGP usecaes, but also the 
>> prevailing Tunnel services.
> 
> 
> Understood.  BGP is also not a dump truck, but has far better scaling 
> properties, so is less likely to have catastrophic failures due to some 
> negative information.

[WAJ] It is the IGP advertises the inaccurate information, why let BGP clear 
up? Won’t you estimate the IDR experts will resist?

> 
> T
> 
> 
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

> 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.
> [WAJ] What we want to do is the “Positive Summary”+” Specific Negative 
> Information”. This can have both the summary scale advantage and also 
> decrease the convergence time that based on the protocol hello timer.


I do understand that.  Do you understand that I think that that’s a Really Bad 
Idea?



>  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.
> [WAJ] PUAM does not increase the overall size of the LSDB. It utilizes the 
> existing LSA/TLV/Sub-TLV.


You’re advertising bits that would not be otherwise advertised.  That increases 
the size of the LSDB.  Utilizing existing TLVs is irrelevant.


> 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.
> [WAJ] BGP is used within the internet, adding the false information within 
> its protocol should be examined more carefully. As we have mentioned several 
> times, the overall goals are not only for BGP usecaes, but also the 
> prevailing Tunnel services.


Understood.  BGP is also not a dump truck, but has far better scaling 
properties, so is less likely to have catastrophic failures due to some 
negative information.

T


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 24, 2021, at 18:12, Robert Raszuk  wrote:
> 
> 
> Aijun,
> 
> Nothing Shraddha is describing is about protecting intermediate hops. 
> 
> She illustrated different solutions for egress protection of PEs. 
> 
> It has some cost and some deployment limitations but it is an option to 
> consider. 

[WAJ] Yes. What I want to express is that there are situations that Egress 
Protection only is not enough, which is asking by Shraddha.

> 
> Thx,
> R.
> 
>> On Wed, Nov 24, 2021 at 6:44 AM Aijun Wang  wrote:
>> 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.)
>>   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: lsr-boun...@ietf.org  On Behalf Of Shraddha Hegde
>> Sent: Wednesday, November 24, 2021 1:20 PM
>> To: Tony Li ; Aijun Wang 
>> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
>> ; Christian Hopps ; lsr 
>> ; Acee Lindem (acee) ; Tony Przygienda 
>> 
>> 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  On Behalf Of Tony Li
>> Sent: Tuesday, November 23, 2021 10:22 PM
>> To: Aijun Wang 
>> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
>> ; Christian Hopps ; lsr 
>> ; Acee Lindem (acee) ; Tony Przygienda 
>> 
>> 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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Aijun,

Nothing Shraddha is describing is about protecting intermediate hops.

She illustrated different solutions for egress protection of PEs.

It has some cost and some deployment limitations but it is an option to
consider.

Thx,
R.

On Wed, Nov 24, 2021 at 6:44 AM Aijun Wang 
wrote:

> 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.)
> 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:* lsr-boun...@ietf.org  *On Behalf Of *Shraddha
> Hegde
> *Sent:* Wednesday, November 24, 2021 1:20 PM
> *To:* Tony Li ; Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Christian Hopps ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda <
> tonysi...@gmail.com>
> *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  *On Behalf Of *Tony Li
> *Sent:* Tuesday, November 23, 2021 10:22 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Christian Hopps ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda <
> tonysi...@gmail.com>
> *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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Peter,

> it requires SID allocation to be synchronized between multiple egress PEs.

That is not correct.

The concept Shraddha is describing does not require any synchronization of
either VPN demux label or SIDs.

In an essence you create based on regular service routing propagation a
shadow FIB/LFIB/SID-FIB on the backup PEs. The PLR uses different label/SID
to steer traffic to such shadow FIB/LFIB/SID-FIB.

Yes it costs some resources but other then that it is a viable option.

I was thinking if I should bring it to this thread however it is a
different category of solution hence and pretty well known hence did not
mentioned it.

Cheers,
R.





On Wed, Nov 24, 2021 at 10:23 AM Peter Psenak  wrote:

> Shraddha,
>
> On 24/11/2021 06:19, Shraddha Hegde wrote:
> > 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
>
> it requires SID allocation to be synchronized between multiple egress
> PEs. With per CE SID allocation and multiple next-hops on each PE, the
> number of SIDs become large and keeping them in sync is challenging.
>
> Using anycast SID approach, you are loosing overlay (BGP) ECMP performed
> at the ingress and replace it with underlay (IGP) ECMP towards the
> egress. This may prevent BGP to load balance across multiple PEs or even
> pick one as a preferred one.
>
> So while it is a alternative, it has its drawbacks. We are trying to
> provide a solution which would not pose any extra requirement to SID
> allocation, nor affect BGP in any way.
>
> thanks,
> Peter
>
>
> >
> > 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  *On Behalf Of *Tony Li
> > *Sent:* Tuesday, November 23, 2021 10:22 PM
> > *To:* Aijun Wang 
> > *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra
> > ; Christian Hopps ; lsr
> > ; Acee Lindem (acee) ; Tony Przygienda
> > 
> > *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 n

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Shraddha,

On 24/11/2021 06:19, Shraddha Hegde wrote:

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


it requires SID allocation to be synchronized between multiple egress 
PEs. With per CE SID allocation and multiple next-hops on each PE, the 
number of SIDs become large and keeping them in sync is challenging.


Using anycast SID approach, you are loosing overlay (BGP) ECMP performed 
at the ingress and replace it with underlay (IGP) ECMP towards the 
egress. This may prevent BGP to load balance across multiple PEs or even 
pick one as a preferred one.


So while it is a alternative, it has its drawbacks. We are trying to 
provide a solution which would not pose any extra requirement to SID 
allocation, nor affect BGP in any way.


thanks,
Peter




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  *On Behalf Of *Tony Li
*Sent:* Tuesday, November 23, 2021 10:22 PM
*To:* Aijun Wang 
*Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

*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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

 

From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Wednesday, November 24, 2021 12:52 AM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

 

 

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.

[WAJ] What we want to do is the “Positive Summary”+” Specific Negative 
Information”. This can have both the summary scale advantage and also decrease 
the convergence time that based on the protocol hello timer.

 

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.

[WAJ] PUAM does not increase the overall size of the LSDB. It utilizes the 
existing LSA/TLV/Sub-TLV.

 

 

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.

[WAJ] BGP is used within the internet, adding the false information within its 
protocol should be examined more carefully. As we have mentioned several times, 
the overall goals are not only for BGP usecaes, but also the prevailing Tunnel 
services.

 

Tony

 

 

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

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-protect
ion-05.)  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: lsr-boun...@ietf.org  On Behalf Of Shraddha
Hegde
Sent: Wednesday, November 24, 2021 1:20 PM
To: Tony Li ; Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra
; Christian Hopps ; lsr ; Acee Lindem (acee) ; Tony Przygienda 
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 mailto:lsr-boun...@ietf.org> > On Behalf Of
Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>
>
Cc: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>
>; Gyan Mishra mailto:hayabusa...@gmail.com> >;
Christian Hopps mailto:cho...@chopps.org> >; lsr
mailto:lsr@ietf.org> >; Acee Lindem (acee) mailto:a...@cisco.com> >; Tony Przygienda mailto:tonysi...@gmail.com> >
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Shraddha Hegde]

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  On Behalf Of Tony Li
Sent: Tuesday, November 23, 2021 10:22 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

> [WAJ] What I want to express is the overall time from the failures occur to 
> the ABR notice it via only IGP procedures. Shouldn’t it be within millisecond 
> within one area? 
> 
> No. Not at all. 
> 
> OSPF hello def timer is 10 sec in some implementations I just checked. 
> 
> So unless you can quickly detect the failure, all works discussed are 
> pointless. That's why your statement that no BFD is needed is just not 
> correct. 
> 
> And if BFD is there as a prerequisite it can equally bring IGP adj down or 
> BGP session down. 

Furthermore, once there is detection, the adjacencies need to update LSAs/LSPs 
and flood them. Flooding may require many hops to get to the ABR.

If your requirement really is one millisecond, then nothing that we’ve 
discussed is even the right order of magnitude.

Tony


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

> On Nov 23, 2021, at 6:56 AM, Aijun Wang  wrote:
> 
> For BFD configuration, I think central control has less help for the work. 
> Let’s consider the SRv6 tunnel, would you configure on every intermediate 
> node to detect the liveness of destination via BFD?


Normally, BFD would be configured on each hop individually.

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Christian Hopps]

Aijun Wang  writes:


Hi, Chris:

For BFD configuration, I think central control has less help for the work. Let’s
consider the SRv6 tunnel, would you configure on every intermediate node to
detect the liveness of destination via BFD?


I was replying to you saying you wanted to use IGP neighbor down detection b/c 
BFD was too hard to configure. I'm not sure what use case you are talking about 
above.

Configuring things is not hard, and isn't a reason to invent new technology by 
itself, is what I'm saying. Operators of large networks generally have central 
management systems where they enable services and the mgmt system then 
automatically generates configuration files as complex as they need to be which 
the system then loads onto the devices.

Thanks,
Chris.
[wg member hat]




Aijun Wang
China Telecom


On Nov 23, 2021, at 20:44, Christian Hopps  wrote:


Aijun Wang  writes:


Hi, Robert:

Aijun Wang
China Telecom


   On Nov 23, 2021, at 20:00, Robert Raszuk 
   wrote:


   Dear Aijun,


   [WAJ] Once there is a link/node failure, upon receiving the
   updated LSA, the ABR 


   That node failure will need to be detected fast.

   The entire discussion here is to do it reasonably fast or as fast
   as possible.

[WAJ] And also as less configuration as possible. We have invested
several tools to increase the speed of LSA flooding.


You keep mentioning less configuration or less configuration complexity when 
people mention BFD. This isn't any sort of justification for not using BFD.

Operators use central management systems now a days, that generate a routers
configuration, they aren't hand typing configuration into routers anymore.
There's no problem at all with enabling BFD through configuration, and it's
use is absolutely not predicated based on how one has to configure it.

Saying BFD is hard to configure is not valid to me. If you are advocating for 
something that would replace BFD, I hope you have a stronger argument against 
using BFD.

Thanks,
Chris.
[WG member hat - for previous emails on this thread too -- forgot to include]



   That is why such detection must happen quickly via LOS or BFD or
   CFM etc That is way before ABR will receive any LSA/LSP from
   the adjacent nodes informing it of the failed adj. And in fact
   all such adj nodes MUST do it fast as ABR will not react till it
   hears bad news from every node previously connected to such PE.

[WAJ] The reaction time depend on the IGP convergence time after one
node is detached from the network. It should be in milliseconds
within one area? Right?


   In every solution we work on we must see a full picture, not just
   single pieces of the puzzle.

   Thx,
   R.




   ___
   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




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> Such results can be deducted from active LSA updates.

That is great !

With just a little caveat ... those active LSA updates arriving on ABRs
must be triggered by some network event. And that is precisely what we are
talking about here.

Kind regards,
R.


On Tue, Nov 23, 2021 at 4:14 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 21:22, Robert Raszuk  wrote:
>
> 
>
> [WAJ] What I want to express is the overall time from the failures occur
>> to the ABR notice it via only IGP procedures. Shouldn’t it be within
>> millisecond within one area?
>>
>
> No. Not at all.
>
> OSPF hello def timer is 10 sec in some implementations I just checked.
>
> So unless you can quickly detect the failure, all works discussed are
> pointless. That's why your statement that no BFD is needed is just not
> correct.
>
> And if BFD is there as a prerequisite it can equally bring IGP adj down or
> BGP session down.
>
> [WAJ] we do not care the liveness of OSPF instance. What we want to know
> is the reachable or unreachable status of some host routes. Such results
> can be deducted from active LSA updates.
>
> Thx a lot,
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 21:22, Robert Raszuk  wrote:
> 
> 
> 
>> [WAJ] What I want to express is the overall time from the failures occur to 
>> the ABR notice it via only IGP procedures. Shouldn’t it be within 
>> millisecond within one area? 
> 
> No. Not at all. 
> 
> OSPF hello def timer is 10 sec in some implementations I just checked. 
> 
> So unless you can quickly detect the failure, all works discussed are 
> pointless. That's why your statement that no BFD is needed is just not 
> correct. 
> 
> And if BFD is there as a prerequisite it can equally bring IGP adj down or 
> BGP session down. 
> 
[WAJ] we do not care the liveness of OSPF instance. What we want to know is the 
reachable or unreachable status of some host routes. Such results can be 
deducted from active LSA updates.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Chris:

For BFD configuration, I think central control has less help for the work. 
Let’s consider the SRv6 tunnel, would you configure on every intermediate node 
to detect the liveness of destination via BFD?

Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:44, Christian Hopps  wrote:
> 
> 
> Aijun Wang  writes:
> 
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>> 
>> 
>>On Nov 23, 2021, at 20:00, Robert Raszuk 
>>wrote:
>> 
>> 
>>Dear Aijun,
>> 
>> 
>>[WAJ] Once there is a link/node failure, upon receiving the
>>updated LSA, the ABR 
>> 
>> 
>>That node failure will need to be detected fast.
>> 
>>The entire discussion here is to do it reasonably fast or as fast
>>as possible.
>> 
>> [WAJ] And also as less configuration as possible. We have invested
>> several tools to increase the speed of LSA flooding.
> 
> You keep mentioning less configuration or less configuration complexity when 
> people mention BFD. This isn't any sort of justification for not using BFD.
> 
> Operators use central management systems now a days, that generate a routers 
> configuration, they aren't hand typing configuration into routers anymore. 
> There's no problem at all with enabling BFD through configuration, and it's 
> use is absolutely not predicated based on how one has to configure it.
> 
> Saying BFD is hard to configure is not valid to me. If you are advocating for 
> something that would replace BFD, I hope you have a stronger argument against 
> using BFD.
> 
> Thanks,
> Chris.
> [WG member hat - for previous emails on this thread too -- forgot to include]
> 
>> 
>>That is why such detection must happen quickly via LOS or BFD or
>>CFM etc That is way before ABR will receive any LSA/LSP from
>>the adjacent nodes informing it of the failed adj. And in fact
>>all such adj nodes MUST do it fast as ABR will not react till it
>>hears bad news from every node previously connected to such PE.
>> 
>> [WAJ] The reaction time depend on the IGP convergence time after one
>> node is detached from the network. It should be in milliseconds
>> within one area? Right?
>> 
>> 
>>In every solution we work on we must see a full picture, not just
>>single pieces of the puzzle.
>> 
>>Thx,
>>R.
>> 
>> 
>> 
>> 
>>___
>>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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> [WAJ] What I want to express is the overall time from the failures occur
> to the ABR notice it via only IGP procedures. Shouldn’t it be within
> millisecond within one area?
>

No. Not at all.

OSPF hello def timer is 10 sec in some implementations I just checked.

So unless you can quickly detect the failure, all works discussed are
pointless. That's why your statement that no BFD is needed is just not
correct.

And if BFD is there as a prerequisite it can equally bring IGP adj down or
BGP session down.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:


Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:41, Robert Raszuk  wrote:
> 
> 
> Aijun,
> 
> You are mixing flooding speed with area convergence and with failure 
> detection. Those are completely orthogonal elements. 
[WAJ] What I want to express is the overall time from the failures occur to the 
ABR notice it via only IGP procedures. Shouldn’t it be within millisecond 
within one area? 
> 
> You questioned use of BFD - all I am stating that there is no easy way to 
> detect failure of the neighbour when LOS trigger is not an option. 
> 
> Thx,
> R.
> 
>> On Tue, Nov 23, 2021 at 1:26 PM Aijun Wang  wrote:
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>> 
 On Nov 23, 2021, at 20:00, Robert Raszuk  wrote:
 
>>> 
>>> Dear Aijun,
>>>  
 [WAJ] Once there is a link/node failure, upon receiving the updated LSA, 
 the ABR 
>>> 
>>> That node failure will need to be detected fast. 
>>> 
>>> The entire discussion here is to do it reasonably fast or as fast as 
>>> possible.
>> [WAJ] And also as less configuration as possible. We have invested several 
>> tools to increase the speed of LSA flooding. 
>>> That is why such detection must happen quickly via LOS or BFD or CFM 
>>> etc That is way before ABR will receive any LSA/LSP from the adjacent 
>>> nodes informing it of the failed adj. And in fact all such adj nodes MUST 
>>> do it fast as ABR will not react till it hears bad news from every node 
>>> previously connected to such PE.
>> [WAJ] The reaction time depend on the IGP convergence time after one node is 
>> detached from the network. It should be in milliseconds within one area? 
>> Right?
>>> 
>>> In every solution we work on we must see a full picture, not just single 
>>> pieces of the puzzle. 
>>> 
>>> Thx,
>>> R.
>>> 
>>> 
>>> 
>>>  
>>> ___
>>> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Christian Hopps]

Aijun Wang  writes:


Hi, Robert:

Aijun Wang
China Telecom


On Nov 23, 2021, at 20:00, Robert Raszuk 
wrote:


Dear Aijun,


[WAJ] Once there is a link/node failure, upon receiving the
updated LSA, the ABR 


That node failure will need to be detected fast.

The entire discussion here is to do it reasonably fast or as fast
as possible.

[WAJ] And also as less configuration as possible. We have invested
several tools to increase the speed of LSA flooding.


You keep mentioning less configuration or less configuration complexity when 
people mention BFD. This isn't any sort of justification for not using BFD.

Operators use central management systems now a days, that generate a routers 
configuration, they aren't hand typing configuration into routers anymore. 
There's no problem at all with enabling BFD through configuration, and it's use 
is absolutely not predicated based on how one has to configure it.

Saying BFD is hard to configure is not valid to me. If you are advocating for 
something that would replace BFD, I hope you have a stronger argument against 
using BFD.

Thanks,
Chris.
[WG member hat - for previous emails on this thread too -- forgot to include]



That is why such detection must happen quickly via LOS or BFD or
CFM etc That is way before ABR will receive any LSA/LSP from
the adjacent nodes informing it of the failed adj. And in fact
all such adj nodes MUST do it fast as ABR will not react till it
hears bad news from every node previously connected to such PE.

[WAJ] The reaction time depend on the IGP convergence time after one
node is detached from the network. It should be in milliseconds
within one area? Right?


In every solution we work on we must see a full picture, not just
single pieces of the puzzle.

Thx,
R.




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




signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Aijun,

You are mixing flooding speed with area convergence and with failure
detection. Those are completely orthogonal elements.

You questioned use of BFD - all I am stating that there is no easy way to
detect failure of the neighbour when LOS trigger is not an option.

Thx,
R.

On Tue, Nov 23, 2021 at 1:26 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 20:00, Robert Raszuk  wrote:
>
> 
> Dear Aijun,
>
>
>> [WAJ] Once there is a link/node failure, upon receiving the updated LSA,
>> the ABR 
>>
>
> That node failure will need to be detected fast.
>
> The entire discussion here is to do it reasonably fast or as fast as
> possible.
>
> [WAJ] And also as less configuration as possible. We have invested several
> tools to increase the speed of LSA flooding.
>
> That is why such detection must happen quickly via LOS or BFD or CFM
> etc That is way before ABR will receive any LSA/LSP from the adjacent
> nodes informing it of the failed adj. And in fact all such adj nodes MUST
> do it fast as ABR will not react till it hears bad news from every node
> previously connected to such PE.
>
> [WAJ] The reaction time depend on the IGP convergence time after one node
> is detached from the network. It should be in milliseconds within one area?
> Right?
>
>
> In every solution we work on we must see a full picture, not just single
> pieces of the puzzle.
>
> Thx,
> R.
>
>
>
>
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 20:00, Robert Raszuk  wrote:
> 
> 
> Dear Aijun,
>  
>> [WAJ] Once there is a link/node failure, upon receiving the updated LSA, the 
>> ABR 
> 
> That node failure will need to be detected fast. 
> 
> The entire discussion here is to do it reasonably fast or as fast as possible.
[WAJ] And also as less configuration as possible. We have invested several 
tools to increase the speed of LSA flooding. 
> That is why such detection must happen quickly via LOS or BFD or CFM etc 
> That is way before ABR will receive any LSA/LSP from the adjacent nodes 
> informing it of the failed adj. And in fact all such adj nodes MUST do it 
> fast as ABR will not react till it hears bad news from every node previously 
> connected to such PE.
[WAJ] The reaction time depend on the IGP convergence time after one node is 
detached from the network. It should be in milliseconds within one area? Right?
> 
> In every solution we work on we must see a full picture, not just single 
> pieces of the puzzle. 
> 
> Thx,
> R.
> 
> 
> 
>  
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Dear Aijun,


> [WAJ] Once there is a link/node failure, upon receiving the updated LSA,
> the ABR 
>

That node failure will need to be detected fast.

The entire discussion here is to do it reasonably fast or as fast as
possible. That is why such detection must happen quickly via LOS or BFD or
CFM etc That is way before ABR will receive any LSA/LSP from the
adjacent nodes informing it of the failed adj. And in fact all such adj
nodes MUST do it fast as ABR will not react till it hears bad news from
every node previously connected to such PE.

In every solution we work on we must see a full picture, not just single
pieces of the puzzle.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 19:42, Robert Raszuk  wrote:
> 
> 
> 
> > For IGP solution, the BFD is not required. 
> 
> Excuse me ? 
> 
> BFD is used on vast majority of the WAN links today as those links are not 
> always dark fiber such that you can detect LOS. Those WAN links are 
> (unfortunately) emulated circuits which require BFD to detect failure in a 
> reasonable time. 
> 
> I hope you are not talking about IGP hellos or BGP keepalives here. 
> 
> We are talking PE-P or PE-RR. 

[WAJ] Once there is a link/node failure, upon receiving the updated LSA, the 
ABR can calculate the missed prefixes within its attached area, as described in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-4

> 
> Thx,
> R.
> 
> 
> 
>> On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang  
>> wrote:
>> Hi, Robert:
>> 
>> Aijun Wang
>> China Telecom
>> 
>>>> On Nov 23, 2021, at 18:04, Robert Raszuk  wrote:
>>>> 
>>> 
>>> 
>>> > When the node is failed, or is detached from the network, it can’t send 
>>> > the BGP update to other peers already.
>>> 
>>> LOL ... that's given. Same for IGP too. 
>>> 
>>> The UPDATE will be generated by the BGP peer of such node - typically RR. 
>>> And if you run BFD on that session it can be as fast as loosing IGP adj to 
>>> an IGP neighbour of the failing node. 
>> [WAJ] Then you depend again the BFD session which there is configuration 
>> overhead. For IGP solution, the BFD is not required. 
>> And, for tunnels situations, where you configure the monitor peer?
>> 
>> Aijun Wang
>> China Telecom
>> 
>>> 
>>> Cheers,
>>> R.
>>> 
>>> 
>>> 
>>> 
>>>> On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang  
>>>> wrote:
>>>> Hi, Robert:
>>>> 
>>>>  
>>>> 
>>>> When the node is failed, or is detached from the network, it can’t send 
>>>> the BGP update to other peers already.
>>>> 
>>>> And, as we have discussed, the potential usage of such information is not 
>>>> only BGP, but may be tunnel endpoints.
>>>> 
>>>> Yes, I agree, the light speed is the same.
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>> Best Regards
>>>> 
>>>>  
>>>> 
>>>> Aijun Wang
>>>> 
>>>> China Telecom
>>>> 
>>>>  
>>>> 
>>>> From: lsr-boun...@ietf.org  On Behalf Of Robert 
>>>> Raszuk
>>>> Sent: Tuesday, November 23, 2021 4:40 PM
>>>> To: Aijun Wang 
>>>> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
>>>> ; Christian Hopps ; Tony Li 
>>>> ; lsr ; Acee Lindem (acee) 
>>>> ; Tony Przygienda 
>>>> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
>>>> Meeting Minutes
>>>> 
>>>>  
>>>> 
>>>> Aijun,
>>>> 
>>>>  
>>>> 
>>>> > or lose the fast convergences
>>>> 
>>>>  
>>>> 
>>>> Putting aside all the drawbacks already discussed, what makes you think 
>>>> that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 
>>>> areas would be any faster then sending BGP UPDATE message(s) across 2-3 
>>>> RRs ? 
>>>> 
>>>>  
>>>> 
>>>> Assume you need to detect the failure and react to it in your RP/RE 
>>>> regardless how it is signalled. If triggered by ABRs you not only need to 
>>>> detect the failure of a node, but also flood it locally within the local 
>>>> area. 
>>>> 
>>>>  
>>>> 
>>>> Light propagation speed last time I checked does not seems to be different 
>>>> for BGP vs OSPF/ISIS packets. 
>>>> 
>>>>  
>>>> 
>>>> Thx,
>>>> 
>>>> R.
>>>> 
>>>>  
>>>> 
>>> ___
>>> 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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> For IGP solution, the BFD is not required.

Excuse me ?

BFD is used on vast majority of the WAN links today as those links are not
always dark fiber such that you can detect LOS. Those WAN links are
(unfortunately) emulated circuits which require BFD to detect failure in a
reasonable time.

I hope you are not talking about IGP hellos or BGP keepalives here.

We are talking PE-P or PE-RR.

Thx,
R.



On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang 
wrote:

> Hi, Robert:
>
> Aijun Wang
> China Telecom
>
> On Nov 23, 2021, at 18:04, Robert Raszuk  wrote:
>
> 
>
> > When the node is failed, or is detached from the network, it can’t send
> the BGP update to other peers already.
>
> LOL ... that's given. Same for IGP too.
>
> The UPDATE will be generated by the BGP peer of such node - typically RR.
> And if you run BFD on that session it can be as fast as loosing IGP adj to
> an IGP neighbour of the failing node.
>
> [WAJ] Then you depend again the BFD session which there is configuration
> overhead. For IGP solution, the BFD is not required.
> And, for tunnels situations, where you configure the monitor peer?
>
> Aijun Wang
> China Telecom
>
>
> Cheers,
> R.
>
>
>
>
> On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang 
> wrote:
>
>> Hi, Robert:
>>
>>
>>
>> When the node is failed, or is detached from the network, it can’t send
>> the BGP update to other peers already.
>>
>> And, as we have discussed, the potential usage of such information is not
>> only BGP, but may be tunnel endpoints.
>>
>> Yes, I agree, the light speed is the same.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* lsr-boun...@ietf.org  *On Behalf Of *Robert
>> Raszuk
>> *Sent:* Tuesday, November 23, 2021 4:40 PM
>> *To:* Aijun Wang 
>> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
>> hayabusa...@gmail.com>; Christian Hopps ; Tony Li <
>> tony...@tony.li>; lsr ; Acee Lindem (acee) ;
>> Tony Przygienda 
>> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
>> LSR Meeting Minutes
>>
>>
>>
>> Aijun,
>>
>>
>>
>> *> or lose the fast convergences*
>>
>>
>>
>> Putting aside all the drawbacks already discussed, what makes you think
>> that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
>> would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?
>>
>>
>>
>> Assume you need to detect the failure and react to it in your RP/RE
>> regardless how it is signalled. If triggered by ABRs you not only need to
>> detect the failure of a node, but also flood it locally within the local
>> area.
>>
>>
>>
>> Light propagation speed last time I checked does not seems to be
>> different for BGP vs OSPF/ISIS packets.
>>
>>
>>
>> Thx,
>>
>> R.
>>
>>
>>
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 23, 2021, at 18:04, Robert Raszuk  wrote:
> 
> 
> 
> > When the node is failed, or is detached from the network, it can’t send the 
> > BGP update to other peers already.
> 
> LOL ... that's given. Same for IGP too. 
> 
> The UPDATE will be generated by the BGP peer of such node - typically RR. And 
> if you run BFD on that session it can be as fast as loosing IGP adj to an IGP 
> neighbour of the failing node. 
[WAJ] Then you depend again the BFD session which there is configuration 
overhead. For IGP solution, the BFD is not required. 
And, for tunnels situations, where you configure the monitor peer?

Aijun Wang
China Telecom

> 
> Cheers,
> R.
> 
> 
> 
> 
>> On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang  
>> wrote:
>> Hi, Robert:
>> 
>>  
>> 
>> When the node is failed, or is detached from the network, it can’t send the 
>> BGP update to other peers already.
>> 
>> And, as we have discussed, the potential usage of such information is not 
>> only BGP, but may be tunnel endpoints.
>> 
>> Yes, I agree, the light speed is the same.
>> 
>>  
>> 
>>  
>> 
>> Best Regards
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>>  
>> 
>> From: lsr-boun...@ietf.org  On Behalf Of Robert Raszuk
>> Sent: Tuesday, November 23, 2021 4:40 PM
>> To: Aijun Wang 
>> Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
>> ; Christian Hopps ; Tony Li 
>> ; lsr ; Acee Lindem (acee) ; 
>> Tony Przygienda 
>> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
>> Meeting Minutes
>> 
>>  
>> 
>> Aijun,
>> 
>>  
>> 
>> > or lose the fast convergences
>> 
>>  
>> 
>> Putting aside all the drawbacks already discussed, what makes you think that 
>> flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas would 
>> be any faster then sending BGP UPDATE message(s) across 2-3 RRs ? 
>> 
>>  
>> 
>> Assume you need to detect the failure and react to it in your RP/RE 
>> regardless how it is signalled. If triggered by ABRs you not only need to 
>> detect the failure of a node, but also flood it locally within the local 
>> area. 
>> 
>>  
>> 
>> Light propagation speed last time I checked does not seems to be different 
>> for BGP vs OSPF/ISIS packets. 
>> 
>>  
>> 
>> Thx,
>> 
>> R.
>> 
>>  
>> 
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
drastically different,

It is not.

You can deliver all of your services using MPLS (as service demux only)
over UDP and IPv4 summarized endpoints for a long long time. Contrail
was/is doing just that :)

Best,
R.


On Tue, Nov 23, 2021 at 11:14 AM Tony Przygienda 
wrote:

>
>
> On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak  wrote:
>
>> Hi Chris,
>>
>> On 22/11/2021 22:29, Christian Hopps wrote:
>> >
>> > Gyan Mishra  writes:
>> >
>> >> +1
>> >>
>> >> As I mentioned the requirements for E2E LSP with seamless MPLS or
>> >> SR-MPLS requires domain wide flooding of host routes.
>> >>
>> >> For large operators with a thousands of routes per area you can image
>> >> if you total that all up can equate to hundreds of thousands of host
>> >> routes.  That is what we live with today real world scenario.
>> >>
>> >> Summarization is a tremendous optimization for operators.
>> >
>> > I'm having a hard time imagining 300,000 or 500,000 PEs that need this
>> "liveness as a host route" notification for. Where are these hundreds of
>> thousands of hosts coming from that ever need to be in the IGP?
>>
>> It's more like tens of thousands from what I have seen.
>>
>
> I don't know the specific network talked about here by Guayn where he
> claims to see 100s of Ks of host routes on a router  either. Though IME
> seeing igp RIB is excess of few 10Ks routes (in a single instance/topology)
> is quiet exceptional for a lot of practical reasons in real deployments.
>
> As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
> drastically different, novel way of addressing tunnel endpoints. Nothing
> prevents you from summarizing (v6) loopback addresses on PEs AFAIS in any
> other tunneling technology (that preconditions having an addressing
> discipline of course but it seems the same is true for SRv6). I stand
> enlightened but AFAIS a tunnel is a tunnel is a tunnel, what we talk about
> here is adding something that provides a partial (since it does not verify
> the data path needed for the control or transport tunnels) SSAP liveliness
> indication to IGP on whatever endpoint (which happens in IP being roughly
> :port whereas we imply by a loss of address the loss of all
> services which in itself is an assumption which is probably fair enough as
> long BGP has all services on the same routing instance, not a given thing
> in the future AFAIS ;-) Where I agree with TLi again that it's not
> something that should be in IGP scope (or at minimum not shared with the
> instance responsible to do the IP reachability computation).
>
> -- tony
>
>
>>
>> thanks,
>> Peter
>>
>> >
>> > Large operators may have prefixes for each of their internal links or
>> each of their router loopback addresss, so this can lead to 1000s of
>> routes; however, it does not imply 100 times that many host routes being
>> present at all.
>> >
>> > Perhaps this is just a hole in my knowledge though.
>> >
>> > Thanks,
>> > Chris.
>> >
>> >
>> >>
>> >> With RFC 5283 the issue why it was never deployed is that it fixes
>> >> half the problem.  If fixed the IGP for with the LDP inter area
>> >> extension can now support LPM IGP match summarization so the RIB/FIB
>> >> is optimized, however the LFIB still has to maintain all the host
>> >> routes FEC binding RFC 5036.
>> >>
>> >> With the RFC 5283 solution we still have to track the liveliness of
>> >> the egress LSR which states can be done by advertising reachability
>> >> via IGP and then you are back to domain wide flooding even in the
>> >> IGP.
>> >>
>> >> Section 7.2
>> >>
>> >>
>> >> - Advertise LER reachability in the IGP for the purpose of the
>> >>   control plane in a way that does not create IP FIB entries in the
>> >>   forwarding plane.
>> >>
>> >>
>> >>
>> >> Here stated the LFIB remains not optimized
>> >>
>> >>
>> >> - The solution documented in this document reduces te link state
>> database size in the control plane and the number of FIB
>> >> entries in the forwarding plane.  As such, it solves the scaling of
>> >>
>> >> pure IP routers sharing the IGP with MPLS routers.  However, it
>> does
>> >> not decrease the number of LFIB entries so is not sufficient to
>> solve
>> >> the scaling of MPLS routers.  For this, an additional mechanism is
>> >> required (e.g., introducing some MPLS hierarchy in LDP).  This is
>> out
>> >> of scope for this document.
>> >>
>> >>
>> >> So this is quite unfortunate for RFC 5283 and why it was never
>> deployed by operators.
>> >>
>> >>
>> >> SRv6 is an answer but majority of all SPs are not there yet and we
>> >> need to be able support MPLS for a long time to come beyond our
>> >> lifetime.
>> >>
>> >> Kind Regards
>> >>
>> >> Gyan
>> >>
>> >> On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
>> >> wrote:
>> >>
>> >>  Robert,
>> >>
>> >>  On 22/11/2021 15:26, Robert Raszuk wrote:
>> >>  >
>> >>  > Peter - the spec does not present 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Przygienda]

On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak  wrote:

> Hi Chris,
>
> On 22/11/2021 22:29, Christian Hopps wrote:
> >
> > Gyan Mishra  writes:
> >
> >> +1
> >>
> >> As I mentioned the requirements for E2E LSP with seamless MPLS or
> >> SR-MPLS requires domain wide flooding of host routes.
> >>
> >> For large operators with a thousands of routes per area you can image
> >> if you total that all up can equate to hundreds of thousands of host
> >> routes.  That is what we live with today real world scenario.
> >>
> >> Summarization is a tremendous optimization for operators.
> >
> > I'm having a hard time imagining 300,000 or 500,000 PEs that need this
> "liveness as a host route" notification for. Where are these hundreds of
> thousands of hosts coming from that ever need to be in the IGP?
>
> It's more like tens of thousands from what I have seen.
>

I don't know the specific network talked about here by Guayn where he
claims to see 100s of Ks of host routes on a router  either. Though IME
seeing igp RIB is excess of few 10Ks routes (in a single instance/topology)
is quiet exceptional for a lot of practical reasons in real deployments.

As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a
drastically different, novel way of addressing tunnel endpoints. Nothing
prevents you from summarizing (v6) loopback addresses on PEs AFAIS in any
other tunneling technology (that preconditions having an addressing
discipline of course but it seems the same is true for SRv6). I stand
enlightened but AFAIS a tunnel is a tunnel is a tunnel, what we talk about
here is adding something that provides a partial (since it does not verify
the data path needed for the control or transport tunnels) SSAP liveliness
indication to IGP on whatever endpoint (which happens in IP being roughly
:port whereas we imply by a loss of address the loss of all
services which in itself is an assumption which is probably fair enough as
long BGP has all services on the same routing instance, not a given thing
in the future AFAIS ;-) Where I agree with TLi again that it's not
something that should be in IGP scope (or at minimum not shared with the
instance responsible to do the IP reachability computation).

-- tony


>
> thanks,
> Peter
>
> >
> > Large operators may have prefixes for each of their internal links or
> each of their router loopback addresss, so this can lead to 1000s of
> routes; however, it does not imply 100 times that many host routes being
> present at all.
> >
> > Perhaps this is just a hole in my knowledge though.
> >
> > Thanks,
> > Chris.
> >
> >
> >>
> >> With RFC 5283 the issue why it was never deployed is that it fixes
> >> half the problem.  If fixed the IGP for with the LDP inter area
> >> extension can now support LPM IGP match summarization so the RIB/FIB
> >> is optimized, however the LFIB still has to maintain all the host
> >> routes FEC binding RFC 5036.
> >>
> >> With the RFC 5283 solution we still have to track the liveliness of
> >> the egress LSR which states can be done by advertising reachability
> >> via IGP and then you are back to domain wide flooding even in the
> >> IGP.
> >>
> >> Section 7.2
> >>
> >>
> >> - Advertise LER reachability in the IGP for the purpose of the
> >>   control plane in a way that does not create IP FIB entries in the
> >>   forwarding plane.
> >>
> >>
> >>
> >> Here stated the LFIB remains not optimized
> >>
> >>
> >> - The solution documented in this document reduces te link state
> database size in the control plane and the number of FIB
> >> entries in the forwarding plane.  As such, it solves the scaling of
> >>
> >> pure IP routers sharing the IGP with MPLS routers.  However, it does
> >> not decrease the number of LFIB entries so is not sufficient to
> solve
> >> the scaling of MPLS routers.  For this, an additional mechanism is
> >> required (e.g., introducing some MPLS hierarchy in LDP).  This is
> out
> >> of scope for this document.
> >>
> >>
> >> So this is quite unfortunate for RFC 5283 and why it was never deployed
> by operators.
> >>
> >>
> >> SRv6 is an answer but majority of all SPs are not there yet and we
> >> need to be able support MPLS for a long time to come beyond our
> >> lifetime.
> >>
> >> Kind Regards
> >>
> >> Gyan
> >>
> >> On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
> >> wrote:
> >>
> >>  Robert,
> >>
> >>  On 22/11/2021 15:26, Robert Raszuk wrote:
> >>  >
> >>  > Peter - the spec does not present full story. Hardly no RFC
> >>  > presents full A--Z on how to run a network or even a
> >>  given feature. It
> >>  > provides mechanism which can still permit for building LDP LSPs
> >>  > without host routes.
> >>  >
> >>  > So anyone claiming it is impossible by architecture of MPLS is
> >>  simply
> >>  > incorrect.
> >>  >
> >>  > As example - some vendors support ordered LDP mode some do not.
> >>  Some
> >>  > support BGP recursion some 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> When the node is failed, or is detached from the network, it can’t send
the BGP update to other peers already.

LOL ... that's given. Same for IGP too.

The UPDATE will be generated by the BGP peer of such node - typically RR.
And if you run BFD on that session it can be as fast as loosing IGP adj to
an IGP neighbour of the failing node.

Cheers,
R.




On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang 
wrote:

> Hi, Robert:
>
>
>
> When the node is failed, or is detached from the network, it can’t send
> the BGP update to other peers already.
>
> And, as we have discussed, the potential usage of such information is not
> only BGP, but may be tunnel endpoints.
>
> Yes, I agree, the light speed is the same.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org  *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, November 23, 2021 4:40 PM
> *To:* Aijun Wang 
> *Cc:* Les Ginsberg (ginsberg) ; Gyan Mishra <
> hayabusa...@gmail.com>; Christian Hopps ; Tony Li <
> tony...@tony.li>; lsr ; Acee Lindem (acee) ;
> Tony Przygienda 
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> Aijun,
>
>
>
> *> or lose the fast convergences*
>
>
>
> Putting aside all the drawbacks already discussed, what makes you think
> that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
> would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?
>
>
>
> Assume you need to detect the failure and react to it in your RP/RE
> regardless how it is signalled. If triggered by ABRs you not only need to
> detect the failure of a node, but also flood it locally within the local
> area.
>
>
>
> Light propagation speed last time I checked does not seems to be different
> for BGP vs OSPF/ISIS packets.
>
>
>
> Thx,
>
> R.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:

 

When the node is failed, or is detached from the network, it can’t send the BGP 
update to other peers already.

And, as we have discussed, the potential usage of such information is not only 
BGP, but may be tunnel endpoints.

Yes, I agree, the light speed is the same.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Robert Raszuk
Sent: Tuesday, November 23, 2021 4:40 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; Tony Li 
; lsr ; Acee Lindem (acee) ; 
Tony Przygienda 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

 

Aijun,

 

> or lose the fast convergences

 

Putting aside all the drawbacks already discussed, what makes you think that 
flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas would be 
any faster then sending BGP UPDATE message(s) across 2-3 RRs ? 

 

Assume you need to detect the failure and react to it in your RP/RE regardless 
how it is signalled. If triggered by ABRs you not only need to detect the 
failure of a node, but also flood it locally within the local area. 

 

Light propagation speed last time I checked does not seems to be different for 
BGP vs OSPF/ISIS packets. 

 

Thx,

R.

 

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Aijun,

*> or lose the fast convergences*

Putting aside all the drawbacks already discussed, what makes you think
that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 areas
would be any faster then sending BGP UPDATE message(s) across 2-3 RRs ?

Assume you need to detect the failure and react to it in your RP/RE
regardless how it is signalled. If triggered by ABRs you not only need to
detect the failure of a node, but also flood it locally within the local
area.

Light propagation speed last time I checked does not seems to be different
for BGP vs OSPF/ISIS packets.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Hi Chris,

On 22/11/2021 22:29, Christian Hopps wrote:


Gyan Mishra  writes:


+1

As I mentioned the requirements for E2E LSP with seamless MPLS or
SR-MPLS requires domain wide flooding of host routes.

For large operators with a thousands of routes per area you can image
if you total that all up can equate to hundreds of thousands of host
routes.  That is what we live with today real world scenario.

Summarization is a tremendous optimization for operators.


I'm having a hard time imagining 300,000 or 500,000 PEs that need this "liveness as 
a host route" notification for. Where are these hundreds of thousands of hosts 
coming from that ever need to be in the IGP?


It's more like tens of thousands from what I have seen.

thanks,
Peter



Large operators may have prefixes for each of their internal links or each of 
their router loopback addresss, so this can lead to 1000s of routes; however, 
it does not imply 100 times that many host routes being present at all.

Perhaps this is just a hole in my knowledge though.

Thanks,
Chris.




With RFC 5283 the issue why it was never deployed is that it fixes
half the problem.  If fixed the IGP for with the LDP inter area
extension can now support LPM IGP match summarization so the RIB/FIB
is optimized, however the LFIB still has to maintain all the host
routes FEC binding RFC 5036.

With the RFC 5283 solution we still have to track the liveliness of
the egress LSR which states can be done by advertising reachability
via IGP and then you are back to domain wide flooding even in the
IGP.

Section 7.2


- Advertise LER reachability in the IGP for the purpose of the
  control plane in a way that does not create IP FIB entries in the
  forwarding plane.



Here stated the LFIB remains not optimized


- The solution documented in this document reduces te link state database size 
in the control plane and the number of FIB
entries in the forwarding plane.  As such, it solves the scaling of

pure IP routers sharing the IGP with MPLS routers.  However, it does
not decrease the number of LFIB entries so is not sufficient to solve
the scaling of MPLS routers.  For this, an additional mechanism is
required (e.g., introducing some MPLS hierarchy in LDP).  This is out
of scope for this document.


So this is quite unfortunate for RFC 5283 and why it was never deployed by 
operators.


SRv6 is an answer but majority of all SPs are not there yet and we
need to be able support MPLS for a long time to come beyond our
lifetime.

Kind Regards

Gyan

On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
wrote:

 Robert,

 On 22/11/2021 15:26, Robert Raszuk wrote:
 >
 > Peter - the spec does not present full story. Hardly no RFC
 > presents full A--Z on how to run a network or even a
 given feature. It
 > provides mechanism which can still permit for building LDP LSPs
 > without host routes.
 >
 > So anyone claiming it is impossible by architecture of MPLS is
 simply
 > incorrect.
 >
 > As example - some vendors support ordered LDP mode some do not.
 Some
 > support BGP recursion some do not. And the story goes on.
 >
 > But I am not sure what point are you insisting on arguing ...
 If it is
 > ok to run host routes across areas we have no problem to start
 with so
 > why to propose anything new there.

 all I'm trying to say is that IGPs do advertise host routes
 across areas
 today. Yes, it is sub-optimal, but hardly architecturally
 incorrect
 IMHO. We want to improve and allow effective use of aggregation,
 while
 keeping the fast notification about egress PE reachability loss
 in place
 to help overlay protocols converge fast. The situation would be
 much
 improved compared to what we have today.

 thanks,
 Peter


 >
 > Moreover as you very well know tons of opaque stuff is attached
 today to
 > leaked host routes and this curve is going up. So when you
 summarise you
 > stop propagating all of this. Is this really ok ?
 >
 > Do not get me wrong I love summarization but it seems as
 discussed off
 > line - we would be much better to leak host routes with opaque
 stuff
 > when needed rather then then leak blindly everything
 everywhere.
 >
 > Cheers,
 > R.
 >
 >
 >
 >
 > On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak  > wrote:
 >
 >     On 22/11/2021 15:00, Robert Raszuk wrote:
 >      >
 >      >     it's not a choice, that is an MPLS architectural
 requirement
 >     and it
 >      >     happens in every single SP network that offers
 services on
 >     top of MPLS.
 >      >     If that is considered architecturally incorrect,
 then the
 >     whole MPLS
 >      >     would be. But regardless of that, it has been used
 very
 >     

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

 

From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Tuesday, November 23, 2021 12:52 AM
To: Les Ginsberg (ginsberg) 
Cc: Gyan Mishra ; Christian Hopps ; 
Aijun Wang ; lsr ; Acee Lindem (acee) 
; Tony Przygienda 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

 

 

 

Les,

 

It is not clear to me why having the IGP advertise information that it already 
knows is considered an “architectural violation”. It is even less clear to me 
since it would not be considered a violation if an operator didn’t configure a 
summary and the IGP advertised all the individual prefixes it knew about all 
the time. (Whether that is a wise choice in a given deployment is another 
matter.)

 

 

The IGP knows many things. I object to adding things to the LSDB that aren’t 
already there.

[WAJ] Then, how to explain the newly defined “Dynamic Flooding LSA” in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-09, which 
is not already in LSDB before?

 

If people want to leak things outside of the area, I object to that. I know 
that people do it already. Yes, there are valid cases where it’s necessary and 
there are tools to do it. People abuse the privilege and then wonder why their 
IGP has indigestion. Go figure.

 

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?

 

As to scale, you are making the assumption that a solution cannot be provided 
without introducing significant scale issues – but I don’t think that is the 
case.

I don’t want to use this thread to advocate for one candidate solution over 
another – I think that is best addressed in some subsequent thread. Just want 
to point out that the solution does not have to have the same scale 
characteristics as having no summaries.

 

 

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?

 

Tony

 

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

On Mon, Nov 22, 2021 at 4:35 PM Christian Hopps  wrote:

>
> Gyan Mishra  writes:
>
> > +1
> >
> > As I mentioned the requirements for E2E LSP with seamless MPLS or
> > SR-MPLS requires domain wide flooding of host routes.
> >
> > For large operators with a thousands of routes per area you can image
> > if you total that all up can equate to hundreds of thousands of host
> > routes.  That is what we live with today real world scenario.
> >
> > Summarization is a tremendous optimization for operators.
>
> I'm having a hard time imagining 300,000 or 500,000 PEs that need this
> "liveness as a host route" notification for. Where are these hundreds of
> thousands of hosts coming from that ever need to be in the IGP?
>
> Large operators may have prefixes for each of their internal links or each
> of their router loopback addresss, so this can lead to 1000s of routes;
> however, it does not imply 100 times that many host routes being present at
> all.
>
> Perhaps this is just a hole in my knowledge though.
>

Gyan> For large operators running MPLS in order to support seamless Unified
/ Seamless MPLS the requirements for domain wide flooding from Core to
Aggregation layers made up of many areas.  A typical large operator would
easily have 10k nodes in each aggregation domain with a 100 aggregation
domains plus the backbone Level 2 nodes over 1000+  with multiple  large
Level 1 areas tie to aggregation layer.

The loopbacks are flooded but are carried in BGP-LU labeled unicast RIB
inter domain, also hierarchical MPLS CSC is utilized as well so that does
reduce the impact of flooding.

So only within an aggregation domain would you have all the loopbacks
flooded in the IGP but going between aggregation domains to access layer
connectivity it would be all BGP-LU RIB with  hierarchical MPLS between
core and aggregation layers.

>
> Thanks,
> Chris.
>
>
> >
> > With RFC 5283 the issue why it was never deployed is that it fixes
> > half the problem.  If fixed the IGP for with the LDP inter area
> > extension can now support LPM IGP match summarization so the RIB/FIB
> > is optimized, however the LFIB still has to maintain all the host
> > routes FEC binding RFC 5036.
> >
> > With the RFC 5283 solution we still have to track the liveliness of
> > the egress LSR which states can be done by advertising reachability
> > via IGP and then you are back to domain wide flooding even in the
> > IGP.
> >
> > Section 7.2
> >
> >
> >- Advertise LER reachability in the IGP for the purpose of the
> >  control plane in a way that does not create IP FIB entries in the
> >  forwarding plane.
> >
> >
> >
> > Here stated the LFIB remains not optimized
> >
> >
> > - The solution documented in this document reduces te link state
> database size in the control plane and the number of FIB
> >entries in the forwarding plane.  As such, it solves the scaling of
> >
> >pure IP routers sharing the IGP with MPLS routers.  However, it does
> >not decrease the number of LFIB entries so is not sufficient to solve
> >the scaling of MPLS routers.  For this, an additional mechanism is
> >required (e.g., introducing some MPLS hierarchy in LDP).  This is out
> >of scope for this document.
> >
> >
> > So this is quite unfortunate for RFC 5283 and why it was never deployed
> by operators.
> >
> >
> > SRv6 is an answer but majority of all SPs are not there yet and we
> > need to be able support MPLS for a long time to come beyond our
> > lifetime.
> >
> > Kind Regards
> >
> > Gyan
> >
> > On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
> > wrote:
> >
> > Robert,
> >
> > On 22/11/2021 15:26, Robert Raszuk wrote:
> > >
> > > Peter - the spec does not present full story. Hardly no RFC
> > > presents full A--Z on how to run a network or even a
> > given feature. It
> > > provides mechanism which can still permit for building LDP LSPs
> > > without host routes.
> > >
> > > So anyone claiming it is impossible by architecture of MPLS is
> > simply
> > > incorrect.
> > >
> > > As example - some vendors support ordered LDP mode some do not.
> > Some
> > > support BGP recursion some do not. And the story goes on.
> > >
> > > But I am not sure what point are you insisting on arguing ...
> > If it is
> > > ok to run host routes across areas we have no problem to start
> > with so
> > > why to propose anything new there.
> >
> > all I'm trying to say is that IGPs do advertise host routes
> > across areas
> > today. Yes, it is sub-optimal, but hardly architecturally
> > incorrect
> > IMHO. We want to improve and allow effective use of aggregation,
> > while
> > keeping the fast notification about egress PE reachability loss
> > in place
> > to help overlay protocols converge fast. The situation would be
> > much
> > improved compared to what we have today.
> >
> > thanks,
> > Peter
> >
> >
> > >
> 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Christian Hopps]

Gyan Mishra  writes:


+1 

As I mentioned the requirements for E2E LSP with seamless MPLS or
SR-MPLS requires domain wide flooding of host routes.

For large operators with a thousands of routes per area you can image
if you total that all up can equate to hundreds of thousands of host
routes.  That is what we live with today real world scenario.

Summarization is a tremendous optimization for operators.


I'm having a hard time imagining 300,000 or 500,000 PEs that need this "liveness as 
a host route" notification for. Where are these hundreds of thousands of hosts 
coming from that ever need to be in the IGP?

Large operators may have prefixes for each of their internal links or each of 
their router loopback addresss, so this can lead to 1000s of routes; however, 
it does not imply 100 times that many host routes being present at all.

Perhaps this is just a hole in my knowledge though.

Thanks,
Chris.




With RFC 5283 the issue why it was never deployed is that it fixes
half the problem.  If fixed the IGP for with the LDP inter area
extension can now support LPM IGP match summarization so the RIB/FIB
is optimized, however the LFIB still has to maintain all the host
routes FEC binding RFC 5036.  

With the RFC 5283 solution we still have to track the liveliness of
the egress LSR which states can be done by advertising reachability
via IGP and then you are back to domain wide flooding even in the
IGP.

Section 7.2


   - Advertise LER reachability in the IGP for the purpose of the
 control plane in a way that does not create IP FIB entries in the
 forwarding plane.



Here stated the LFIB remains not optimized


- The solution documented in this document reduces te link state database size 
in the control plane and the number of FIB
   entries in the forwarding plane.  As such, it solves the scaling of

   pure IP routers sharing the IGP with MPLS routers.  However, it does
   not decrease the number of LFIB entries so is not sufficient to solve
   the scaling of MPLS routers.  For this, an additional mechanism is
   required (e.g., introducing some MPLS hierarchy in LDP).  This is out
   of scope for this document.


So this is quite unfortunate for RFC 5283 and why it was never deployed by 
operators.


SRv6 is an answer but majority of all SPs are not there yet and we
need to be able support MPLS for a long time to come beyond our
lifetime. 

Kind Regards 

Gyan

On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak 
wrote:

Robert,

On 22/11/2021 15:26, Robert Raszuk wrote:
>
> Peter - the spec does not present full story. Hardly no RFC
> presents full A--Z on how to run a network or even a
given feature. It
> provides mechanism which can still permit for building LDP LSPs
> without host routes.
>
> So anyone claiming it is impossible by architecture of MPLS is
simply
> incorrect.
>
> As example - some vendors support ordered LDP mode some do not.
Some
> support BGP recursion some do not. And the story goes on.
>
> But I am not sure what point are you insisting on arguing ...
If it is
> ok to run host routes across areas we have no problem to start
with so
> why to propose anything new there.

all I'm trying to say is that IGPs do advertise host routes
across areas
today. Yes, it is sub-optimal, but hardly architecturally
incorrect
IMHO. We want to improve and allow effective use of aggregation,
while
keeping the fast notification about egress PE reachability loss
in place
to help overlay protocols converge fast. The situation would be
much
improved compared to what we have today.

thanks,
Peter


>
> Moreover as you very well know tons of opaque stuff is attached
today to
> leaked host routes and this curve is going up. So when you
summarise you
> stop propagating all of this. Is this really ok ?
>
> Do not get me wrong I love summarization but it seems as
discussed off
> line - we would be much better to leak host routes with opaque
stuff
> when needed rather then then leak blindly everything
everywhere.
>
> Cheers,
> R.
>
>
>
>
> On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak  > wrote:
>
>     On 22/11/2021 15:00, Robert Raszuk wrote:
>      >
>      >     it's not a choice, that is an MPLS architectural
requirement
>     and it
>      >     happens in every single SP network that offers
services on
>     top of MPLS.
>      >     If that is considered architecturally incorrect,
then the
>     whole MPLS
>      >     would be. But regardless of that, it has been used
very
>     successfully
>      >     for
>      >     last 30 years.
>      >
>      >
>      > No. Please read RFC5283.
>
>     and how many SPs have deployed it?
>
>     Hardly any, and 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Les,

> It is not clear to me why having the IGP advertise information that it 
> already knows is considered an “architectural violation”. It is even less 
> clear to me since it would not be considered a violation if an operator 
> didn’t configure a summary and the IGP advertised all the individual prefixes 
> it knew about all the time. (Whether that is a wise choice in a given 
> deployment is another matter.)


The IGP knows many things. I object to adding things to the LSDB that aren’t 
already there. If people want to leak things outside of the area, I object to 
that. I know that people do it already. Yes, there are valid cases where it’s 
necessary and there are tools to do it. People abuse the privilege and then 
wonder why their IGP has indigestion. Go figure.

I object to adding negative liveness to the LSDB because of the scale and 
because it adds scale during failures.


> As to scale, you are making the assumption that a solution cannot be provided 
> without introducing significant scale issues – but I don’t think that is the 
> case.
> I don’t want to use this thread to advocate for one candidate solution over 
> another – I think that is best addressed in some subsequent thread. Just want 
> to point out that the solution does not have to have the same scale 
> characteristics as having no summaries.


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.

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

No.  Summarization and LPM routing inherent to IP based routing and is
native to SRv6 and that discussion is completely orthogonal to the
requirement for SRv6 IGP extension for IPv6 data plane.

One of the major benefits of SRv6 over MPLS is that it does not rely on
MPLS exact match and E2E LSP and can use LPM match  as the SRv6 locators
can be LPM summary routes in steering between areas with way point SR-TE
 BSID policies on ABRs or ASBRs to stitch the E2E path.

SRv6-BE BGP service overlay the egress PE  signals the L2 L3 VPN service
SID for BGP overlay route to SR source node or for SRv6-TE egress PE colors
overlay route using RFC 9012 Color extended community for the E2E path
instantiation.

As the signaling is egress to ingress for the path instantiation,   the
seamless MPLS style domain wide flooding for E2E LSP stateful path is not
required.

However summarization is still valuable in an SRv6 domain for summarization
of SIDs flooded via SRv6 IGP extension domain wide.

Kind Regards

Gyan

On Mon, Nov 22, 2021 at 8:59 AM Robert Raszuk  wrote:

>
> Are you saying this draft is useless ?
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/
>
> Thx,
> R.
>
>
> On Mon, Nov 22, 2021 at 2:54 PM Gyan Mishra  wrote:
>
>>
>> Correction related to SRv6 as if uses the native IPv6 data plane it does
>> out of the box support summarization.
>>
>> A gap still exists for MPLS and SR-MPLS.
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Mon, Nov 22, 2021 at 7:18 AM Aijun Wang 
>> wrote:
>>
>>>
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> On Nov 22, 2021, at 18:44, Tony Przygienda  wrote:
>>>
>>> 
>>> Just to prop a voice of support to Tony Li's arguments which I have
>>> nothing further to add really. He basically elucidated ;-) with flourishes
>>> what I wrote in my short, terse email I think.
>>>
>>> As he says "you either make easy choices and get an operationally
>>> unstable environment at scale/large disturbances or you make hard
>>> architectural choices & scale much better over time".
>>>
>>>
>>> [WAJ] Easy choices doesn’t definitely get operationally unstable
>>> environment(we have explained in previous mails). And would you give some
>>> examples to illustrate “hard architecture but scale much better over time?”
>>>
>>> Examples of that are abound in systems design but it's unfortunately
>>> often RFC1295 (4). As a sidenote: IETF has no intention or mechanism to
>>> stop people doing unscalable, poorly designed things with their specs
>>>
>>>
>>> [WAJ] like RIFT or flood reflector solutions in IGP?
>>>
>>> and that was ok as long people did not try to push them onto the whole
>>> world without listening to folks who took the scar tissue to get us the
>>> IETF working specs we have today which seems to have become fashionable in
>>> last couple of years.
>>>
>>>
>>> And fast flooding is a red herring here IMO, it does nothing but
>>> accelerate the control loop, if the control loop is positively stable, it's
>>> good, if the control loops are oscillating or start to negatively amplify
>>> accelerating things just melts everything faster.
>>>
>>>
>>> [WAJ] There is no control loop oscillation. We track only the down event.
>>>
>>>
>>> Ultimately, having followed this "discussion" my opinion is still that
>>> if authors would like to abuse IGP as "domain wide broadcast" for
>>> liveliness notification the "events" draft is far less fragile and
>>> convoluted but should be kept in a service instance as basically "event
>>> based BFD substitute" to not start to cause head-blocking on IGP resources.
>>>
>>>
>>> [WAJ] Seems you are not listening other person’s discussion. Please
>>> refer to Acee’s comments at
>>> https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/
>>>
>>> And AFAIR Robert observed it's still not a very good indication compared
>>> to BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD
>>> PMSI (assuming UDP healthy = TCP healthy which is however far less an
>>> assumption than "flooding feels transport is OK").
>>>
>>>
>>> [WAJ] Current solutions are not aimed only the BGP overlay service, but
>>> also the tunnel services. For tunnel services how you build MP2MP PMSI?
>>>
>>>
>>> -- tony
>>>
>>> On Mon, Nov 22, 2021 at 7:55 AM Tony Li  wrote:
>>>

 Les,


 The problem is that restricting the prefix length does nothing to limit
 the number of advertisements that get flooded.  In a high-scale situation,
 when there is a mass failure, it would lead to a flooding spike. That’s
 exactly not the time to stress the system.

 *[LES:] As I have stated previously, I share your concern about the
 behavior during massive events – and some care has to be taken to prevent
 making a bad situation worse.*
 *That said, the WG (including you and I)  is taking on enhancements to
 support much faster flooding – on the order of hundreds (perhaps thousands)
 of LSPs/second. We believe this can be done 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Robert,

On 22/11/2021 16:14, Robert Raszuk wrote:

All,

If you want to know real world scenarios lot's of networks uses separate 
IGP domains not areas or levels. And yes I do know that 1000s of host 
routes are present everywhere. MPLS networks build in early 2000s are 
still running as is.


That means that your unreachable propagation of host routes from one 
area/ASN would need to be magically transponded between ASBRs (all under 
same administration). We know how to do that with host routes using say 
RFC3107 safi 4.


depends on how domains are interconnected.

If it is done without BGP, using IGP redistribution, that can be done 
for pulses as well. No standardization required.


If there is BGP in between these IGP domains inside the SP network, you 
typically are carrying the PE loopbacks inside BGP itself. If not and 
you want to benefit from the pulses, you would have to define something 
in BGP to carry them between ASs.


thanks,
Peter



How would one propagate those pulses ? New BGP SAFI ?

Put it back to BGP sounds like a problem on its own as some folks here 
just do not get the concept of BGP recursion and that BGP can signal 
next hops going down in milliseconds (+detection time + light 
propagation time) across your network.


Thx,
R.






On Mon, Nov 22, 2021 at 3:56 PM Gyan Mishra > wrote:



+1

As I mentioned the requirements for E2E LSP with seamless MPLS or
SR-MPLS requires domain wide flooding of host routes.

For large operators with a thousands of routes per area you can
image if you total that all up can equate to hundreds of thousands
of host routes.  That is what we live with today real world scenario.

Summarization is a tremendous optimization for operators.

With RFC 5283 the issue why it was never deployed is that it fixes
half the problem.  If fixed the IGP for with the LDP inter area
extension can now support LPM IGP match summarization so the RIB/FIB
is optimized, however the LFIB still has to maintain all the host
routes FEC binding RFC 5036.

With the RFC 5283 solution we still have to track the liveliness of
the egress LSR which states can be done by advertising reachability
via IGP and then you are back to domain wide flooding even in the IGP.

Section 7.2

- Advertise LER reachability in the IGP for the purpose of the
  control plane in a way that does not create IP FIB entries in the
  forwarding plane.



Here stated the LFIB remains not optimized


- The solution documented in this document reduces te link state database 
size in the control plane and the number of FIB
entries in the forwarding plane.  As such, it solves the scaling of

pure IP routers sharing the IGP with MPLS routers.  However, it does
not decrease the number of LFIB entries so is not sufficient to solve
the scaling of MPLS routers.  For this, an additional mechanism is
required (e.g., introducing some MPLS hierarchy in LDP).  This is out
of scope for this document.


So this is quite unfortunate for RFC 5283 and why it was never deployed by 
operators.


SRv6 is an answer but majority of all SPs are not there yet and we
need to be able support MPLS for a long time to come beyond our
lifetime.

Kind Regards

Gyan

On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak mailto:ppse...@cisco.com>> wrote:

Robert,

On 22/11/2021 15:26, Robert Raszuk wrote:
 >
 > Peter - the spec does not present full story. Hardly no RFC
 > presents full A--Z on how to run a network or even a
given feature. It
 > provides mechanism which can still permit for building LDP LSPs
 > without host routes.
 >
 > So anyone claiming it is impossible by architecture of MPLS
is simply
 > incorrect.
 >
 > As example - some vendors support ordered LDP mode some do
not. Some
 > support BGP recursion some do not. And the story goes on.
 >
 > But I am not sure what point are you insisting on arguing ...
If it is
 > ok to run host routes across areas we have no problem to
start with so
 > why to propose anything new there.

all I'm trying to say is that IGPs do advertise host routes
across areas
today. Yes, it is sub-optimal, but hardly architecturally incorrect
IMHO. We want to improve and allow effective use of aggregation,
while
keeping the fast notification about egress PE reachability loss
in place
to help overlay protocols converge fast. The situation would be
much
improved compared to what we have today.

thanks,
Peter


 >
 > Moreover as you very well know tons of opaque stuff is
attached today to
 > leaked host routes and this 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

All,

If you want to know real world scenarios lot's of networks uses separate
IGP domains not areas or levels. And yes I do know that 1000s of host
routes are present everywhere. MPLS networks build in early 2000s are still
running as is.

That means that your unreachable propagation of host routes from one
area/ASN would need to be magically transponded between ASBRs (all under
same administration). We know how to do that with host routes using say
RFC3107 safi 4.

How would one propagate those pulses ? New BGP SAFI ?

Put it back to BGP sounds like a problem on its own as some folks here just
do not get the concept of BGP recursion and that BGP can signal next hops
going down in milliseconds (+detection time + light propagation time)
across your network.

Thx,
R.






On Mon, Nov 22, 2021 at 3:56 PM Gyan Mishra  wrote:

>
> +1
>
> As I mentioned the requirements for E2E LSP with seamless MPLS or SR-MPLS
> requires domain wide flooding of host routes.
>
> For large operators with a thousands of routes per area you can image if
> you total that all up can equate to hundreds of thousands of host routes.
> That is what we live with today real world scenario.
>
> Summarization is a tremendous optimization for operators.
>
> With RFC 5283 the issue why it was never deployed is that it fixes half
> the problem.  If fixed the IGP for with the LDP inter area extension can
> now support LPM IGP match summarization so the RIB/FIB is optimized,
> however the LFIB still has to maintain all the host routes FEC binding RFC
> 5036.
>
> With the RFC 5283 solution we still have to track the liveliness of the
> egress LSR which states can be done by advertising reachability via IGP and
> then you are back to domain wide flooding even in the IGP.
>
> Section 7.2
>
>- Advertise LER reachability in the IGP for the purpose of the
>  control plane in a way that does not create IP FIB entries in the
>  forwarding plane.
>
>
>
> Here stated the LFIB remains not optimized
>
>
> - The solution documented in this document reduces te link state database 
> size in the control plane and the number of FIB
>entries in the forwarding plane.  As such, it solves the scaling of
>
>pure IP routers sharing the IGP with MPLS routers.  However, it does
>not decrease the number of LFIB entries so is not sufficient to solve
>the scaling of MPLS routers.  For this, an additional mechanism is
>required (e.g., introducing some MPLS hierarchy in LDP).  This is out
>of scope for this document.
>
>
> So this is quite unfortunate for RFC 5283 and why it was never deployed by 
> operators.
>
>
> SRv6 is an answer but majority of all SPs are not there yet and we need to
> be able support MPLS for a long time to come beyond our lifetime.
>
> Kind Regards
>
> Gyan
>
> On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak  wrote:
>
>> Robert,
>>
>> On 22/11/2021 15:26, Robert Raszuk wrote:
>> >
>> > Peter - the spec does not present full story. Hardly no RFC
>> > presents full A--Z on how to run a network or even a given feature. It
>> > provides mechanism which can still permit for building LDP LSPs
>> > without host routes.
>> >
>> > So anyone claiming it is impossible by architecture of MPLS is simply
>> > incorrect.
>> >
>> > As example - some vendors support ordered LDP mode some do not. Some
>> > support BGP recursion some do not. And the story goes on.
>> >
>> > But I am not sure what point are you insisting on arguing ... If it is
>> > ok to run host routes across areas we have no problem to start with so
>> > why to propose anything new there.
>>
>> all I'm trying to say is that IGPs do advertise host routes across areas
>> today. Yes, it is sub-optimal, but hardly architecturally incorrect
>> IMHO. We want to improve and allow effective use of aggregation, while
>> keeping the fast notification about egress PE reachability loss in place
>> to help overlay protocols converge fast. The situation would be much
>> improved compared to what we have today.
>>
>> thanks,
>> Peter
>>
>>
>> >
>> > Moreover as you very well know tons of opaque stuff is attached today
>> to
>> > leaked host routes and this curve is going up. So when you summarise
>> you
>> > stop propagating all of this. Is this really ok ?
>> >
>> > Do not get me wrong I love summarization but it seems as discussed off
>> > line - we would be much better to leak host routes with opaque stuff
>> > when needed rather then then leak blindly everything everywhere.
>> >
>> > Cheers,
>> > R.
>> >
>> >
>> >
>> >
>> > On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak > > > wrote:
>> >
>> > On 22/11/2021 15:00, Robert Raszuk wrote:
>> >  >
>> >  > it's not a choice, that is an MPLS architectural requirement
>> > and it
>> >  > happens in every single SP network that offers services on
>> > top of MPLS.
>> >  > If that is considered architecturally incorrect, then the
>> > whole MPLS
>> >  > would 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

+1

As I mentioned the requirements for E2E LSP with seamless MPLS or SR-MPLS
requires domain wide flooding of host routes.

For large operators with a thousands of routes per area you can image if
you total that all up can equate to hundreds of thousands of host routes.
That is what we live with today real world scenario.

Summarization is a tremendous optimization for operators.

With RFC 5283 the issue why it was never deployed is that it fixes half the
problem.  If fixed the IGP for with the LDP inter area extension can now
support LPM IGP match summarization so the RIB/FIB is optimized, however
the LFIB still has to maintain all the host routes FEC binding RFC 5036.

With the RFC 5283 solution we still have to track the liveliness of the
egress LSR which states can be done by advertising reachability via IGP and
then you are back to domain wide flooding even in the IGP.

Section 7.2

   - Advertise LER reachability in the IGP for the purpose of the
 control plane in a way that does not create IP FIB entries in the
 forwarding plane.



Here stated the LFIB remains not optimized


- The solution documented in this document reduces te link state
database size in the control plane and the number of FIB
   entries in the forwarding plane.  As such, it solves the scaling of

   pure IP routers sharing the IGP with MPLS routers.  However, it does
   not decrease the number of LFIB entries so is not sufficient to solve
   the scaling of MPLS routers.  For this, an additional mechanism is
   required (e.g., introducing some MPLS hierarchy in LDP).  This is out
   of scope for this document.


So this is quite unfortunate for RFC 5283 and why it was never
deployed by operators.


SRv6 is an answer but majority of all SPs are not there yet and we need to
be able support MPLS for a long time to come beyond our lifetime.

Kind Regards

Gyan

On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak  wrote:

> Robert,
>
> On 22/11/2021 15:26, Robert Raszuk wrote:
> >
> > Peter - the spec does not present full story. Hardly no RFC
> > presents full A--Z on how to run a network or even a given feature. It
> > provides mechanism which can still permit for building LDP LSPs
> > without host routes.
> >
> > So anyone claiming it is impossible by architecture of MPLS is simply
> > incorrect.
> >
> > As example - some vendors support ordered LDP mode some do not. Some
> > support BGP recursion some do not. And the story goes on.
> >
> > But I am not sure what point are you insisting on arguing ... If it is
> > ok to run host routes across areas we have no problem to start with so
> > why to propose anything new there.
>
> all I'm trying to say is that IGPs do advertise host routes across areas
> today. Yes, it is sub-optimal, but hardly architecturally incorrect
> IMHO. We want to improve and allow effective use of aggregation, while
> keeping the fast notification about egress PE reachability loss in place
> to help overlay protocols converge fast. The situation would be much
> improved compared to what we have today.
>
> thanks,
> Peter
>
>
> >
> > Moreover as you very well know tons of opaque stuff is attached today to
> > leaked host routes and this curve is going up. So when you summarise you
> > stop propagating all of this. Is this really ok ?
> >
> > Do not get me wrong I love summarization but it seems as discussed off
> > line - we would be much better to leak host routes with opaque stuff
> > when needed rather then then leak blindly everything everywhere.
> >
> > Cheers,
> > R.
> >
> >
> >
> >
> > On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak  > > wrote:
> >
> > On 22/11/2021 15:00, Robert Raszuk wrote:
> >  >
> >  > it's not a choice, that is an MPLS architectural requirement
> > and it
> >  > happens in every single SP network that offers services on
> > top of MPLS.
> >  > If that is considered architecturally incorrect, then the
> > whole MPLS
> >  > would be. But regardless of that, it has been used very
> > successfully
> >  > for
> >  > last 30 years.
> >  >
> >  >
> >  > No. Please read RFC5283.
> >
> > and how many SPs have deployed it?
> >
> > Hardly any, and maybe because of what is described in section-7.2
> >
> > "For LER failure, given that the IGP
> >aggregates IP routes on ABRs and no longer advertises specific
> >prefixes, the control plane and more specifically the routing
> >convergence behavior of protocols (e.g., [MP-BGP]) or applications
> >(e.g., [L3-VPN]) may be changed in case of failure of the egress
> LER
> >node."
> >
> >
> > And what RFC5283 suggests in the same section is:
> >
> >   "Advertise LER reachability in the IGP for the purpose of the
> >control plane in a way that does not create IP FIB entries in
> the
> >forwarding plane."
> >
> > Above defeats the prefix aggregation.
> >
> 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Robert,

On 22/11/2021 15:26, Robert Raszuk wrote:


Peter - the spec does not present full story. Hardly no RFC 
presents full A--Z on how to run a network or even a given feature. It 
provides mechanism which can still permit for building LDP LSPs 
without host routes.


So anyone claiming it is impossible by architecture of MPLS is simply 
incorrect.


As example - some vendors support ordered LDP mode some do not. Some 
support BGP recursion some do not. And the story goes on.


But I am not sure what point are you insisting on arguing ... If it is 
ok to run host routes across areas we have no problem to start with so 
why to propose anything new there.


all I'm trying to say is that IGPs do advertise host routes across areas 
today. Yes, it is sub-optimal, but hardly architecturally incorrect 
IMHO. We want to improve and allow effective use of aggregation, while 
keeping the fast notification about egress PE reachability loss in place 
to help overlay protocols converge fast. The situation would be much 
improved compared to what we have today.


thanks,
Peter




Moreover as you very well know tons of opaque stuff is attached today to 
leaked host routes and this curve is going up. So when you summarise you 
stop propagating all of this. Is this really ok ?


Do not get me wrong I love summarization but it seems as discussed off 
line - we would be much better to leak host routes with opaque stuff 
when needed rather then then leak blindly everything everywhere.


Cheers,
R.




On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak > wrote:


On 22/11/2021 15:00, Robert Raszuk wrote:
 >
 >     it's not a choice, that is an MPLS architectural requirement
and it
 >     happens in every single SP network that offers services on
top of MPLS.
 >     If that is considered architecturally incorrect, then the
whole MPLS
 >     would be. But regardless of that, it has been used very
successfully
 >     for
 >     last 30 years.
 >
 >
 > No. Please read RFC5283.

and how many SPs have deployed it?

Hardly any, and maybe because of what is described in section-7.2

"For LER failure, given that the IGP
   aggregates IP routes on ABRs and no longer advertises specific
   prefixes, the control plane and more specifically the routing
   convergence behavior of protocols (e.g., [MP-BGP]) or applications
   (e.g., [L3-VPN]) may be changed in case of failure of the egress LER
   node."


And what RFC5283 suggests in the same section is:

      "Advertise LER reachability in the IGP for the purpose of the
       control plane in a way that does not create IP FIB entries in the
       forwarding plane."

Above defeats the prefix aggregation.


Peter


 >
 > Thx,
 > R.



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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Peter - the spec does not present full story. Hardly no RFC presents full
A--Z on how to run a network or even a given feature. It provides
mechanism which can still permit for building LDP LSPs without host routes.

So anyone claiming it is impossible by architecture of MPLS is simply
incorrect.

As example - some vendors support ordered LDP mode some do not. Some
support BGP recursion some do not. And the story goes on.

But I am not sure what point are you insisting on arguing ... If it is ok
to run host routes across areas we have no problem to start with so why to
propose anything new there.

Moreover as you very well know tons of opaque stuff is attached today to
leaked host routes and this curve is going up. So when you summarise you
stop propagating all of this. Is this really ok ?

Do not get me wrong I love summarization but it seems as discussed off line
- we would be much better to leak host routes with opaque stuff when needed
rather then then leak blindly everything everywhere.

Cheers,
R.




On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak  wrote:

> On 22/11/2021 15:00, Robert Raszuk wrote:
> >
> > it's not a choice, that is an MPLS architectural requirement and it
> > happens in every single SP network that offers services on top of
> MPLS.
> > If that is considered architecturally incorrect, then the whole MPLS
> > would be. But regardless of that, it has been used very successfully
> > for
> > last 30 years.
> >
> >
> > No. Please read RFC5283.
>
> and how many SPs have deployed it?
>
> Hardly any, and maybe because of what is described in section-7.2
>
> "For LER failure, given that the IGP
>   aggregates IP routes on ABRs and no longer advertises specific
>   prefixes, the control plane and more specifically the routing
>   convergence behavior of protocols (e.g., [MP-BGP]) or applications
>   (e.g., [L3-VPN]) may be changed in case of failure of the egress LER
>   node."
>
>
> And what RFC5283 suggests in the same section is:
>
>  "Advertise LER reachability in the IGP for the purpose of the
>   control plane in a way that does not create IP FIB entries in the
>   forwarding plane."
>
> Above defeats the prefix aggregation.
>
>
> Peter
>
>
> >
> > Thx,
> > R.
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

On 22/11/2021 15:00, Robert Raszuk wrote:


it's not a choice, that is an MPLS architectural requirement and it
happens in every single SP network that offers services on top of MPLS.
If that is considered architecturally incorrect, then the whole MPLS
would be. But regardless of that, it has been used very successfully
for
last 30 years.


No. Please read RFC5283.


and how many SPs have deployed it?

Hardly any, and maybe because of what is described in section-7.2

"For LER failure, given that the IGP
 aggregates IP routes on ABRs and no longer advertises specific
 prefixes, the control plane and more specifically the routing
 convergence behavior of protocols (e.g., [MP-BGP]) or applications
 (e.g., [L3-VPN]) may be changed in case of failure of the egress LER
 node."


And what RFC5283 suggests in the same section is:

"Advertise LER reachability in the IGP for the purpose of the
 control plane in a way that does not create IP FIB entries in the
 forwarding plane."

Above defeats the prefix aggregation.


Peter




Thx,
R.


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Are you saying this draft is useless ?

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

Thx,
R.


On Mon, Nov 22, 2021 at 2:54 PM Gyan Mishra  wrote:

>
> Correction related to SRv6 as if uses the native IPv6 data plane it does
> out of the box support summarization.
>
> A gap still exists for MPLS and SR-MPLS.
>
> Kind Regards
>
> Gyan
>
> On Mon, Nov 22, 2021 at 7:18 AM Aijun Wang 
> wrote:
>
>>
>>
>> Aijun Wang
>> China Telecom
>>
>> On Nov 22, 2021, at 18:44, Tony Przygienda  wrote:
>>
>> 
>> Just to prop a voice of support to Tony Li's arguments which I have
>> nothing further to add really. He basically elucidated ;-) with flourishes
>> what I wrote in my short, terse email I think.
>>
>> As he says "you either make easy choices and get an operationally
>> unstable environment at scale/large disturbances or you make hard
>> architectural choices & scale much better over time".
>>
>>
>> [WAJ] Easy choices doesn’t definitely get operationally unstable
>> environment(we have explained in previous mails). And would you give some
>> examples to illustrate “hard architecture but scale much better over time?”
>>
>> Examples of that are abound in systems design but it's unfortunately
>> often RFC1295 (4). As a sidenote: IETF has no intention or mechanism to
>> stop people doing unscalable, poorly designed things with their specs
>>
>>
>> [WAJ] like RIFT or flood reflector solutions in IGP?
>>
>> and that was ok as long people did not try to push them onto the whole
>> world without listening to folks who took the scar tissue to get us the
>> IETF working specs we have today which seems to have become fashionable in
>> last couple of years.
>>
>>
>> And fast flooding is a red herring here IMO, it does nothing but
>> accelerate the control loop, if the control loop is positively stable, it's
>> good, if the control loops are oscillating or start to negatively amplify
>> accelerating things just melts everything faster.
>>
>>
>> [WAJ] There is no control loop oscillation. We track only the down event.
>>
>>
>> Ultimately, having followed this "discussion" my opinion is still that if
>> authors would like to abuse IGP as "domain wide broadcast" for liveliness
>> notification the "events" draft is far less fragile and convoluted but
>> should be kept in a service instance as basically "event based BFD
>> substitute" to not start to cause head-blocking on IGP resources.
>>
>>
>> [WAJ] Seems you are not listening other person’s discussion. Please refer
>> to Acee’s comments at
>> https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/
>>
>> And AFAIR Robert observed it's still not a very good indication compared
>> to BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD
>> PMSI (assuming UDP healthy = TCP healthy which is however far less an
>> assumption than "flooding feels transport is OK").
>>
>>
>> [WAJ] Current solutions are not aimed only the BGP overlay service, but
>> also the tunnel services. For tunnel services how you build MP2MP PMSI?
>>
>>
>> -- tony
>>
>> On Mon, Nov 22, 2021 at 7:55 AM Tony Li  wrote:
>>
>>>
>>> Les,
>>>
>>>
>>> The problem is that restricting the prefix length does nothing to limit
>>> the number of advertisements that get flooded.  In a high-scale situation,
>>> when there is a mass failure, it would lead to a flooding spike. That’s
>>> exactly not the time to stress the system.
>>>
>>> *[LES:] As I have stated previously, I share your concern about the
>>> behavior during massive events – and some care has to be taken to prevent
>>> making a bad situation worse.*
>>> *That said, the WG (including you and I)  is taking on enhancements to
>>> support much faster flooding – on the order of hundreds (perhaps thousands)
>>> of LSPs/second. We believe this can be done safely (though proof has not
>>> yet been established).*
>>>
>>>
>>>
>>> And the point of doing that was to help improve IGP convergence time…
>>>
>>>
>>> *So, if you believe (as your active participation suggests) that IGPs
>>> can support faster flooding – why do you believe they cannot support
>>> liveness notification at a similar scale?*
>>>
>>>
>>>
>>> … not waste our time by inflating the LSDB by the same amount that we
>>> sped up flooding.
>>>
>>> Also, I don’t see how faster flooding has ANYTHING to do with it. Adding
>>> negative liveness information is primary a scale issue.
>>>
>>>
>>>
>>> *I get that you consider such notifications as architecturally
>>> undesirable – we can agree to disagree on that point.*
>>> *But I don’t get why you think the IGP’s ability to handle large scale
>>> events is a showstopper in this case.*
>>>
>>>
>>>
>>> I am opposed to anything that adds to the scale of the LSDB. Doubly so
>>> if it does so during failures, when the IGP is already under stress. As you
>>> well know, making an IGP stable during normal operations is one thing.
>>> Ensuring that it is stable during worst case topological changes is quite
>>> 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Correction related to SRv6 as if uses the native IPv6 data plane it does
out of the box support summarization.

A gap still exists for MPLS and SR-MPLS.

Kind Regards

Gyan

On Mon, Nov 22, 2021 at 7:18 AM Aijun Wang 
wrote:

>
>
> Aijun Wang
> China Telecom
>
> On Nov 22, 2021, at 18:44, Tony Przygienda  wrote:
>
> 
> Just to prop a voice of support to Tony Li's arguments which I have
> nothing further to add really. He basically elucidated ;-) with flourishes
> what I wrote in my short, terse email I think.
>
> As he says "you either make easy choices and get an operationally unstable
> environment at scale/large disturbances or you make hard architectural
> choices & scale much better over time".
>
>
> [WAJ] Easy choices doesn’t definitely get operationally unstable
> environment(we have explained in previous mails). And would you give some
> examples to illustrate “hard architecture but scale much better over time?”
>
> Examples of that are abound in systems design but it's unfortunately often
> RFC1295 (4). As a sidenote: IETF has no intention or mechanism to stop
> people doing unscalable, poorly designed things with their specs
>
>
> [WAJ] like RIFT or flood reflector solutions in IGP?
>
> and that was ok as long people did not try to push them onto the whole
> world without listening to folks who took the scar tissue to get us the
> IETF working specs we have today which seems to have become fashionable in
> last couple of years.
>
>
> And fast flooding is a red herring here IMO, it does nothing but
> accelerate the control loop, if the control loop is positively stable, it's
> good, if the control loops are oscillating or start to negatively amplify
> accelerating things just melts everything faster.
>
>
> [WAJ] There is no control loop oscillation. We track only the down event.
>
>
> Ultimately, having followed this "discussion" my opinion is still that if
> authors would like to abuse IGP as "domain wide broadcast" for liveliness
> notification the "events" draft is far less fragile and convoluted but
> should be kept in a service instance as basically "event based BFD
> substitute" to not start to cause head-blocking on IGP resources.
>
>
> [WAJ] Seems you are not listening other person’s discussion. Please refer
> to Acee’s comments at
> https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/
>
> And AFAIR Robert observed it's still not a very good indication compared
> to BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD
> PMSI (assuming UDP healthy = TCP healthy which is however far less an
> assumption than "flooding feels transport is OK").
>
>
> [WAJ] Current solutions are not aimed only the BGP overlay service, but
> also the tunnel services. For tunnel services how you build MP2MP PMSI?
>
>
> -- tony
>
> On Mon, Nov 22, 2021 at 7:55 AM Tony Li  wrote:
>
>>
>> Les,
>>
>>
>> The problem is that restricting the prefix length does nothing to limit
>> the number of advertisements that get flooded.  In a high-scale situation,
>> when there is a mass failure, it would lead to a flooding spike. That’s
>> exactly not the time to stress the system.
>>
>> *[LES:] As I have stated previously, I share your concern about the
>> behavior during massive events – and some care has to be taken to prevent
>> making a bad situation worse.*
>> *That said, the WG (including you and I)  is taking on enhancements to
>> support much faster flooding – on the order of hundreds (perhaps thousands)
>> of LSPs/second. We believe this can be done safely (though proof has not
>> yet been established).*
>>
>>
>>
>> And the point of doing that was to help improve IGP convergence time…
>>
>>
>> *So, if you believe (as your active participation suggests) that IGPs can
>> support faster flooding – why do you believe they cannot support liveness
>> notification at a similar scale?*
>>
>>
>>
>> … not waste our time by inflating the LSDB by the same amount that we
>> sped up flooding.
>>
>> Also, I don’t see how faster flooding has ANYTHING to do with it. Adding
>> negative liveness information is primary a scale issue.
>>
>>
>>
>> *I get that you consider such notifications as architecturally
>> undesirable – we can agree to disagree on that point.*
>> *But I don’t get why you think the IGP’s ability to handle large scale
>> events is a showstopper in this case.*
>>
>>
>>
>> I am opposed to anything that adds to the scale of the LSDB. Doubly so if
>> it does so during failures, when the IGP is already under stress. As you
>> well know, making an IGP stable during normal operations is one thing.
>> Ensuring that it is stable during worst case topological changes is quite
>> another. Adding scale during a mass failure is pessimal timing.
>>
>> T
>>
>>
>> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Aijun Wang
China Telecom

> On Nov 22, 2021, at 18:44, Tony Przygienda  wrote:
> 
> 
> Just to prop a voice of support to Tony Li's arguments which I have nothing 
> further to add really. He basically elucidated ;-) with flourishes what I 
> wrote in my short, terse email I think. 
> 
> As he says "you either make easy choices and get an operationally unstable 
> environment at scale/large disturbances or you make hard architectural 
> choices & scale much better over time".

[WAJ] Easy choices doesn’t definitely get operationally unstable environment(we 
have explained in previous mails). And would you give some examples to 
illustrate “hard architecture but scale much better over time?”

> Examples of that are abound in systems design but it's unfortunately often 
> RFC1295 (4). As a sidenote: IETF has no intention or mechanism to stop people 
> doing unscalable, poorly designed things with their specs

[WAJ] like RIFT or flood reflector solutions in IGP?

> and that was ok as long people did not try to push them onto the whole world 
> without listening to folks who took the scar tissue to get us the IETF 
> working specs we have today which seems to have become fashionable in last 
> couple of years. 
> 
> And fast flooding is a red herring here IMO, it does nothing but accelerate 
> the control loop, if the control loop is positively stable, it's good, if the 
> control loops are oscillating or start to negatively amplify accelerating 
> things just melts everything faster. 

[WAJ] There is no control loop oscillation. We track only the down event.
> 
> Ultimately, having followed this "discussion" my opinion is still that if 
> authors would like to abuse IGP as "domain wide broadcast" for liveliness 
> notification the "events" draft is far less fragile and convoluted but should 
> be kept in a service instance as basically "event based BFD substitute" to 
> not start to cause head-blocking on IGP resources.

[WAJ] Seems you are not listening other person’s discussion. Please refer to 
Acee’s comments at 
https://mailarchive.ietf.org/arch/msg/lsr/zzaPetGzjHsu49KcyBrixQlo5G8/

> And AFAIR Robert observed it's still not a very good indication compared to 
> BFD, a good solution would be e.g. in PE case a (hierarchical) MP2MP BFD PMSI 
> (assuming UDP healthy = TCP healthy which is however far less an assumption 
> than "flooding feels transport is OK"). 

[WAJ] Current solutions are not aimed only the BGP overlay service, but also 
the tunnel services. For tunnel services how you build MP2MP PMSI?

> 
> -- tony 
> 
>> On Mon, Nov 22, 2021 at 7:55 AM Tony Li  wrote:
>> 
>> Les,
>> 
>> 
>>> The problem is that restricting the prefix length does nothing to limit the 
>>> number of advertisements that get flooded.  In a high-scale situation, when 
>>> there is a mass failure, it would lead to a flooding spike. That’s exactly 
>>> not the time to stress the system.
>>>  
>>> [LES:] As I have stated previously, I share your concern about the behavior 
>>> during massive events – and some care has to be taken to prevent making a 
>>> bad situation worse.
>>> That said, the WG (including you and I)  is taking on enhancements to 
>>> support much faster flooding – on the order of hundreds (perhaps thousands) 
>>> of LSPs/second. We believe this can be done safely (though proof has not 
>>> yet been established).
>> 
>> 
>> And the point of doing that was to help improve IGP convergence time…
>> 
>> 
>>> So, if you believe (as your active participation suggests) that IGPs can 
>>> support faster flooding – why do you believe they cannot support liveness 
>>> notification at a similar scale?
>> 
>> 
>> … not waste our time by inflating the LSDB by the same amount that we sped 
>> up flooding.
>> 
>> Also, I don’t see how faster flooding has ANYTHING to do with it. Adding 
>> negative liveness information is primary a scale issue.
>> 
>>  
>>> I get that you consider such notifications as architecturally undesirable – 
>>> we can agree to disagree on that point.
>>> But I don’t get why you think the IGP’s ability to handle large scale 
>>> events is a showstopper in this case.
>> 
>> 
>> I am opposed to anything that adds to the scale of the LSDB. Doubly so if it 
>> does so during failures, when the IGP is already under stress. As you well 
>> know, making an IGP stable during normal operations is one thing. Ensuring 
>> that it is stable during worst case topological changes is quite another. 
>> Adding scale during a mass failure is pessimal timing.
>> 
>> T
>> 
>> 
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Przygienda]

Just to prop a voice of support to Tony Li's arguments which I have nothing
further to add really. He basically elucidated ;-) with flourishes what I
wrote in my short, terse email I think.

As he says "you either make easy choices and get an operationally unstable
environment at scale/large disturbances or you make hard architectural
choices & scale much better over time". Examples of that are abound in
systems design but it's unfortunately often RFC1295 (4). As a sidenote:
IETF has no intention or mechanism to stop people doing unscalable, poorly
designed things with their specs and that was ok as long people did not try
to push them onto the whole world without listening to folks who took the
scar tissue to get us the IETF working specs we have today which seems to
have become fashionable in last couple of years.

And fast flooding is a red herring here IMO, it does nothing but accelerate
the control loop, if the control loop is positively stable, it's good, if
the control loops are oscillating or start to negatively amplify
accelerating things just melts everything faster.

Ultimately, having followed this "discussion" my opinion is still that if
authors would like to abuse IGP as "domain wide broadcast" for liveliness
notification the "events" draft is far less fragile and convoluted but
should be kept in a service instance as basically "event based BFD
substitute" to not start to cause head-blocking on IGP resources. And AFAIR
Robert observed it's still not a very good indication compared to BFD, a
good solution would be e.g. in PE case a (hierarchical) MP2MP BFD PMSI
(assuming UDP healthy = TCP healthy which is however far less an assumption
than "flooding feels transport is OK").

-- tony

On Mon, Nov 22, 2021 at 7:55 AM Tony Li  wrote:

>
> Les,
>
>
> The problem is that restricting the prefix length does nothing to limit
> the number of advertisements that get flooded.  In a high-scale situation,
> when there is a mass failure, it would lead to a flooding spike. That’s
> exactly not the time to stress the system.
>
> *[LES:] As I have stated previously, I share your concern about the
> behavior during massive events – and some care has to be taken to prevent
> making a bad situation worse.*
> *That said, the WG (including you and I)  is taking on enhancements to
> support much faster flooding – on the order of hundreds (perhaps thousands)
> of LSPs/second. We believe this can be done safely (though proof has not
> yet been established).*
>
>
>
> And the point of doing that was to help improve IGP convergence time…
>
>
> *So, if you believe (as your active participation suggests) that IGPs can
> support faster flooding – why do you believe they cannot support liveness
> notification at a similar scale?*
>
>
>
> … not waste our time by inflating the LSDB by the same amount that we sped
> up flooding.
>
> Also, I don’t see how faster flooding has ANYTHING to do with it. Adding
> negative liveness information is primary a scale issue.
>
>
>
> *I get that you consider such notifications as architecturally undesirable
> – we can agree to disagree on that point.*
> *But I don’t get why you think the IGP’s ability to handle large scale
> events is a showstopper in this case.*
>
>
>
> I am opposed to anything that adds to the scale of the LSDB. Doubly so if
> it does so during failures, when the IGP is already under stress. As you
> well know, making an IGP stable during normal operations is one thing.
> Ensuring that it is stable during worst case topological changes is quite
> another. Adding scale during a mass failure is pessimal timing.
>
> T
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

On 22/11/2021 08:45, Les Ginsberg (ginsberg) wrote:

Tony –

I have been trying to gain a better understanding of your thinking – 
thanx for your responses which have helped in that regard.


I am not trying to convince you of anything – just want to add a few 
comments:


It is not clear to me why having the IGP advertise information that it 
already knows is considered an “architectural violation”. It is even 
less clear to me since it would not be considered a violation if an 
operator didn’t configure a summary and the IGP advertised all the 
individual prefixes it knew about all the time. (Whether that is a wise 
choice in a given deployment is another matter.)


it's not a choice, that is an MPLS architectural requirement and it 
happens in every single SP network that offers services on top of MPLS. 
If that is considered architecturally incorrect, then the whole MPLS 
would be. But regardless of that, it has been used very successfully for 
last 30 years.


thanks,
Peter





As to scale, you are making the assumption that a solution cannot be 
provided without introducing significant scale issues – but I don’t 
think that is the case.


I don’t want to use this thread to advocate for one candidate solution 
over another – I think that is best addressed in some subsequent thread. 
Just want to point out that the solution does not have to have the same 
scale characteristics as having no summaries.


Thanx for the discussion.

     Les

*From:* Tony Li  *On Behalf Of *Tony Li
*Sent:* Sunday, November 21, 2021 10:56 PM
*To:* Les Ginsberg (ginsberg) 
*Cc:* Aijun Wang ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

*Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 
112 LSR Meeting Minutes


Les,

The problem is that restricting the prefix length does nothing to
limit the number of advertisements that get flooded.  In a
high-scale situation, when there is a mass failure, it would lead to
a flooding spike. That’s exactly not the time to stress the system.

*/[LES:] As I have stated previously, I share your concern about the
behavior during massive events – and some care has to be taken to
prevent making a bad situation worse./*

*/That said, the WG (including you and I)  is taking on enhancements
to support much faster flooding – on the order of hundreds (perhaps
thousands) of LSPs/second. We believe this can be done safely
(though proof has not yet been established)./*

And the point of doing that was to help improve IGP convergence time…



*/So, if you believe (as your active participation suggests) that
IGPs can support faster flooding – why do you believe they cannot
support liveness notification at a similar scale?/*

… not waste our time by inflating the LSDB by the same amount that we 
sped up flooding.


Also, I don’t see how faster flooding has ANYTHING to do with it. Adding 
negative liveness information is primary a scale issue.


*/

/*

*//*

*/I get that you consider such notifications as architecturally
undesirable – we can agree to disagree on that point./*

*/But I don’t get why you think the IGP’s ability to handle large
scale events is a showstopper in this case./*

I am opposed to anything that adds to the scale of the LSDB. Doubly so 
if it does so during failures, when the IGP is already under stress. As 
you well know, making an IGP stable during normal operations is one 
thing. Ensuring that it is stable during worst case topological changes 
is quite another. Adding scale during a mass failure is pessimal timing.


T



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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Les Ginsberg (ginsberg)]

Tony –

I have been trying to gain a better understanding of your thinking – thanx for 
your responses which have helped in that regard.

I am not trying to convince you of anything – just want to add a few comments:

It is not clear to me why having the IGP advertise information that it already 
knows is considered an “architectural violation”. It is even less clear to me 
since it would not be considered a violation if an operator didn’t configure a 
summary and the IGP advertised all the individual prefixes it knew about all 
the time. (Whether that is a wise choice in a given deployment is another 
matter.)

As to scale, you are making the assumption that a solution cannot be provided 
without introducing significant scale issues – but I don’t think that is the 
case.
I don’t want to use this thread to advocate for one candidate solution over 
another – I think that is best addressed in some subsequent thread. Just want 
to point out that the solution does not have to have the same scale 
characteristics as having no summaries.

Thanx for the discussion.

Les


From: Tony Li  On Behalf Of Tony Li
Sent: Sunday, November 21, 2021 10:56 PM
To: Les Ginsberg (ginsberg) 
Cc: Aijun Wang ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


Les,


The problem is that restricting the prefix length does nothing to limit the 
number of advertisements that get flooded.  In a high-scale situation, when 
there is a mass failure, it would lead to a flooding spike. That’s exactly not 
the time to stress the system.

[LES:] As I have stated previously, I share your concern about the behavior 
during massive events – and some care has to be taken to prevent making a bad 
situation worse.
That said, the WG (including you and I)  is taking on enhancements to support 
much faster flooding – on the order of hundreds (perhaps thousands) of 
LSPs/second. We believe this can be done safely (though proof has not yet been 
established).


And the point of doing that was to help improve IGP convergence time…



So, if you believe (as your active participation suggests) that IGPs can 
support faster flooding – why do you believe they cannot support liveness 
notification at a similar scale?


… not waste our time by inflating the LSDB by the same amount that we sped up 
flooding.

Also, I don’t see how faster flooding has ANYTHING to do with it. Adding 
negative liveness information is primary a scale issue.



I get that you consider such notifications as architecturally undesirable – we 
can agree to disagree on that point.
But I don’t get why you think the IGP’s ability to handle large scale events is 
a showstopper in this case.


I am opposed to anything that adds to the scale of the LSDB. Doubly so if it 
does so during failures, when the IGP is already under stress. As you well 
know, making an IGP stable during normal operations is one thing. Ensuring that 
it is stable during worst case topological changes is quite another. Adding 
scale during a mass failure is pessimal timing.

T


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Les,


> The problem is that restricting the prefix length does nothing to limit the 
> number of advertisements that get flooded.  In a high-scale situation, when 
> there is a mass failure, it would lead to a flooding spike. That’s exactly 
> not the time to stress the system.
>  
> [LES:] As I have stated previously, I share your concern about the behavior 
> during massive events – and some care has to be taken to prevent making a bad 
> situation worse.
> That said, the WG (including you and I)  is taking on enhancements to support 
> much faster flooding – on the order of hundreds (perhaps thousands) of 
> LSPs/second. We believe this can be done safely (though proof has not yet 
> been established).


And the point of doing that was to help improve IGP convergence time…


> So, if you believe (as your active participation suggests) that IGPs can 
> support faster flooding – why do you believe they cannot support liveness 
> notification at a similar scale?


… not waste our time by inflating the LSDB by the same amount that we sped up 
flooding.

Also, I don’t see how faster flooding has ANYTHING to do with it. Adding 
negative liveness information is primary a scale issue.

 
> I get that you consider such notifications as architecturally undesirable – 
> we can agree to disagree on that point.
> But I don’t get why you think the IGP’s ability to handle large scale events 
> is a showstopper in this case.


I am opposed to anything that adds to the scale of the LSDB. Doubly so if it 
does so during failures, when the IGP is already under stress. As you well 
know, making an IGP stable during normal operations is one thing. Ensuring that 
it is stable during worst case topological changes is quite another. Adding 
scale during a mass failure is pessimal timing.

T


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Les Ginsberg (ginsberg)]

Tony -

The problem is that restricting the prefix length does nothing to limit the 
number of advertisements that get flooded.  In a high-scale situation, when 
there is a mass failure, it would lead to a flooding spike. That’s exactly not 
the time to stress the system.

[LES:] As I have stated previously, I share your concern about the behavior 
during massive events – and some care has to be taken to prevent making a bad 
situation worse.
That said, the WG (including you and I)  is taking on enhancements to support 
much faster flooding – on the order of hundreds (perhaps thousands) of 
LSPs/second. We believe this can be done safely (though proof has not yet been 
established).
So, if you believe (as your active participation suggests) that IGPs can 
support faster flooding – why do you believe they cannot support liveness 
notification at a similar scale?

I get that you consider such notifications as architecturally undesirable – we 
can agree to disagree on that point.
But I don’t get why you think the IGP’s ability to handle large scale events is 
a showstopper in this case.

Les

Yes, it is more complex and harder than simply flooding things. It’s also much 
more likely to actually work well at scale and under stress.

It’s pretty common that you can either do things the right way or you can do 
things the easy way.

Tony


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

> [WAJ] I have explained to Chris the differences between the usage of IGP 
> unreachable and BGP unreachable at 
> https://mailarchive.ietf.org/arch/msg/lsr/HBUDX5lcbcrKuPK1R7MbNC-mcGA/ 
> 
> BGP、Tunnel etc. overlay services are depending on the IGP, then knowing the 
> unreachable information can certainly accelerate their convergence and 
> switchover to the backup endpoints.


Yes, but you missed the point that BGP should carry the reachability in the 
first place and then the BGP withdraw would give you what you want.

Yes, I certainly understand that you want to change the IGP behavior to 
accomodate tunnel convergence. That part is quite clear.
We do not want to flood the negative liveness information in the IGP. That’s 
not its job, architecturally.


> What I would like is if there was a centralized service, such as Google Maps, 
> that simply did the path computation for me and updated it in real time. :)
> Interestingly, that information isn’t flooded. It’s built with a scalable 
> back end service and then unicast to the end user.
>   
>
> [WAJ] As I explained below, PUAM information is needed not only the PEs(for 
> BGP scenario), but may be used by P router within the network(for Tunnel 
> scenario). As also I explained previously, the implementation/operator can 
> limit the PUAM only for /32 or /128 loopback address, which will not 
> sacrifice the scalability of IGP, and at the same time, accelerate the 
> convergence of the overlay services that depends on it.
> Comparing with utilizing the existing procedures, Introducing another 
> mechanism, such as centralize service, PUB/SUB mechanism as you proposed, 
> isn't it more complex and less efficient? All the procedures that we 
> considered will not omitted, the difference is only how to transfer the 
> message.


The problem is that restricting the prefix length does nothing to limit the 
number of advertisements that get flooded.  In a high-scale situation, when 
there is a mass failure, it would lead to a flooding spike. That’s exactly not 
the time to stress the system.

Yes, it is more complex and harder than simply flooding things. It’s also much 
more likely to actually work well at scale and under stress.

It’s pretty common that you can either do things the right way or you can do 
things the easy way.

Tony


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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

 

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Tony Li
Sent: Monday, November 22, 2021 1:11 AM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Gyan Mishra 
; Christian Hopps ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

 

 

Hi Aijun,

 

>> No. ABRs advertised statically configured prefixes for the area. Anything 
>> else would cause flap. And it’s purely reachability, not liveness. There can 
>> be zero live nodes within an area and the ABR should still advertise its 
>> summary.

> 

> [WAJ] What the usage of the summary advertisement in such conditions excepts 
> it misleads the nodes within the area it attached?

 

 

I think Chris answered this adequately.

[WAJ] I have explained to Chris the differences between the usage of IGP 
unreachable and BGP unreachable at 
https://mailarchive.ietf.org/arch/msg/lsr/HBUDX5lcbcrKuPK1R7MbNC-mcGA/

BGP、Tunnel etc. overlay services are depending on the IGP, then knowing the 
unreachable information can certainly accelerate their convergence and 
switchover to the backup endpoints.

 

>>> Pub/Sub style notification seems promising, but it will require the ABR 
>>> store the subscription state which will certainly degrade its performance. 

>> 

>> 

>> Baloney. A notification list address post-SPF is wholly outside of the 
>> performance path.

> 

> [WAJ] Is there any existing mechanism to accomplish your proposal among the 
> PEs?

No, there is no existing mechanism.  PUAM is one new mechanism. I’m suggesting 
another one that’s architecturally cleaner.

 

> [WAJ] Within the network, the number of PEs often surpasses the number of P 
> nodes. Even with P nodes, such information can also help them reroute/switch 
> to other endpoints along the SRv6 tunnel backup path.

> I think you could imagine the signal just as the alert information that often 
> seen on the highway. It can certainly save the driver’s time. Wouldn’t you 
> like to know such information immediately? Or you just drive as planned until 
> near the target to know the road is broken?

 

What I would like is if there was a centralized service, such as Google Maps, 
that simply did the path computation for me and updated it in real time. :)

Interestingly, that information isn’t flooded. It’s built with a scalable back 
end service and then unicast to the end user.   

  

[WAJ] As I explained below, PUAM information is needed not only the PEs(for BGP 
scenario), but may be used by P router within the network(for Tunnel scenario). 
As also I explained previously, the implementation/operator can limit the PUAM 
only for /32 or /128 loopback address, which will not sacrifice the scalability 
of IGP, and at the same time, accelerate the convergence of the overlay 
services that depends on it.

Comparing with utilizing the existing procedures, Introducing another 
mechanism, such as centralize service, PUB/SUB mechanism as you proposed, isn't 
it more complex and less efficient? All the procedures that we considered will 
not omitted, the difference is only how to transfer the message.

 

T

 

___

Lsr mailing list

 <mailto:Lsr@ietf.org> Lsr@ietf.org

 <https://www.ietf.org/mailman/listinfo/lsr> 
https://www.ietf.org/mailman/listinfo/lsr

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Robert

Very good point!

As for summarization and SR framework my thoughts are that inter-as or
inter-area for both SR-MPLS and SRv6 you could have SR-TE BSID bind
candidate path to forwarding plane at each area border hop or AS hop
steering source routing E2E engineered path but you would still need to
domain wide flood the loopbacks for SR-MPLS for prefix and node SID for
steering and for SRv6 as well would have to flood locators, prefix and node
SID as well as for seamless MPLS style building of E2E path as it does
apply to SR framework.

So I agree we would need IGP extension for both SR-MPLS and SRV6 for ABR &
ASBR summarization to avoid domain wide flooding seamless MPLS E2E path
instantiation.

Kind Regards

Gyan

On Sun, Nov 21, 2021 at 11:56 AM Robert Raszuk  wrote:

> Gyan,
>
> You are missing IGP extensions required for Segment Routing (both SR-MPLS
> and SRv6). If you summarize  router information at the area boundary
> nothing get's propagate outside of area and no one can build SR paths to
> your area nodes. Game's over.
>
> And if you do not summarize you already have what is required.
>
> Thx,
> R.
>
>
>
>
> On Sun, Nov 21, 2021 at 5:19 PM Gyan Mishra  wrote:
>
>>
>>
>> On Sun, Nov 21, 2021 at 6:50 AM Robert Raszuk  wrote:
>>
>>>
>>> > So we desperately need a viable IGP summarization
>>>
>>> And could you elaborate on how summarization is going to work with
>>> Segment Routing ? Not that I am pushing anyone to go there, but looking
>>> through the window this seems to be the current trend.
>>>
>>
>> Gyan> SR-MPLS as it reuses the MPLS data plane but relies on IGP
>> extension to flood SID label instead of LDP for prefix and node SID it’s
>> still exact match host route so the solution we come up with for MPLS would
>> apply to SR-MPLS.  As for SRv6 it’s standard IP routing LPM based not FEC
>> so summarization natively works.  My thoughts for SRv6 is that the same
>> component host route tracking can be used as well with SRv6 or IPv4 or IPv6
>> forwarding plane.
>>
>>>
>>> We rely on leaking as additional information is attached to host routes.
>>> Stopping that breaks the game.
>>>
>>
>> Gyan> Agreed the flooding of host routes for seamless MPLS is a
>> requirement also for exact match FEC has to be a host route.
>>
>>>
>>> And btw LDP FECs where always host routes + label so unlike you say -
>>> nothing new needed there. As I recall even TDP was carrying host addresses
>>> with tags.
>>>
>>
>> Gyan> Understood that LDP LIB and LFIB label mapping message FEC TLV has
>> to contain the exact match host route for the MPLS forwarding plane so
>> basically we are back in the same boat with RFC 5283 as it’s not a complete
>> solution as it just fixes the IGP RIB/FIB making summarization possible but
>> does not fix summarization with LDP as LDP still has to maintain all the
>> host routes.
>>
>> I will try to work on MPLS based update to fix RFC 5283 so LDP can use
>> summarization LPM match.
>>
>> Thx,
>>> R.
>>>
>>> On Sun, Nov 21, 2021 at 3:46 AM Gyan Mishra 
>>> wrote:
>>>

 Most all operators have not deployed RFC 5283 LDP inter area extension
 due to the fact that it shifts the seamless MPLS flooding requirement and
 scalability problem from the RIB/FIB to the LFIB.

 So we desperately need a viable IGP summarization solution mitigate
 domain wide flooding of host routes.

 Gyan

 On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra 
 wrote:

>
> Robert
>
> RFC 5283 provides LDP extension for inter area for LPM summary FEC
> however in this specification the component prefixes are probated via LDP
> which is  how the LDP inter-area extension is able to support
> summarization.
>
> The problem here is you make IGP scalable with this LDP inter-area
> extension but then you pass the buck to MPLS which now is not scalable as
> all the flooded prefixes are summarized in the IGP but now the LFIB has to
> suffer from the domain wide flooding.
>
> This issue with domain wide flooding gets much worse with seamless
> MPLS with E2E LSP requirements from core to aggregation layer so now all
> the area and levels within the entire domain had all host routes.  This 
> can
> be pretty tremendous for large operator networks and a huge scalability
> issue that needs a solution.
>
> See section 7.2
>
> The solution documented in this document reduces the link state database 
> size in the control plane and the number of FIB
>entries in the forwarding plane.  As such, it solves the scaling of
>
>pure IP routers sharing the IGP with MPLS routers.  However, it does
>not decrease the number of LFIB entries so is not sufficient to solve
>the scaling of MPLS routers.  For this, an additional mechanism is
>required (e.g., introducing some MPLS hierarchy in LDP).  This is out
>of scope for this document.
>
>

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

>> No. ABRs advertised statically configured prefixes for the area. Anything 
>> else would cause flap. And it’s purely reachability, not liveness. There can 
>> be zero live nodes within an area and the ABR should still advertise its 
>> summary.
> 
> [WAJ] What the usage of the summary advertisement in such conditions excepts 
> it misleads the nodes within the area it attached?


I think Chris answered this adequately.


>>> Pub/Sub style notification seems promising, but it will require the ABR 
>>> store the subscription state which will certainly degrade its performance. 
>> 
>> 
>> Baloney. A notification list address post-SPF is wholly outside of the 
>> performance path.
> 
> [WAJ] Is there any existing mechanism to accomplish your proposal among the 
> PEs?


No, there is no existing mechanism.  PUAM is one new mechanism. I’m suggesting 
another one that’s architecturally cleaner.


> [WAJ] Within the network, the number of PEs often surpasses the number of P 
> nodes. Even with P nodes, such information can also help them reroute/switch 
> to other endpoints along the SRv6 tunnel backup path.
> I think you could imagine the signal just as the alert information that often 
> seen on the highway. It can certainly save the driver’s time. Wouldn’t you 
> like to know such information immediately? Or you just drive as planned until 
> near the target to know the road is broken?


What I would like is if there was a centralized service, such as Google Maps, 
that simply did the path computation for me and updated it in real time. :)

Interestingly, that information isn’t flooded. It’s built with a scalable back 
end service and then unicast to the end user.

T

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Gyan,

You are missing IGP extensions required for Segment Routing (both SR-MPLS
and SRv6). If you summarize  router information at the area boundary
nothing get's propagate outside of area and no one can build SR paths to
your area nodes. Game's over.

And if you do not summarize you already have what is required.

Thx,
R.




On Sun, Nov 21, 2021 at 5:19 PM Gyan Mishra  wrote:

>
>
> On Sun, Nov 21, 2021 at 6:50 AM Robert Raszuk  wrote:
>
>>
>> > So we desperately need a viable IGP summarization
>>
>> And could you elaborate on how summarization is going to work with
>> Segment Routing ? Not that I am pushing anyone to go there, but looking
>> through the window this seems to be the current trend.
>>
>
> Gyan> SR-MPLS as it reuses the MPLS data plane but relies on IGP extension
> to flood SID label instead of LDP for prefix and node SID it’s still exact
> match host route so the solution we come up with for MPLS would apply to
> SR-MPLS.  As for SRv6 it’s standard IP routing LPM based not FEC so
> summarization natively works.  My thoughts for SRv6 is that the same
> component host route tracking can be used as well with SRv6 or IPv4 or IPv6
> forwarding plane.
>
>>
>> We rely on leaking as additional information is attached to host routes.
>> Stopping that breaks the game.
>>
>
> Gyan> Agreed the flooding of host routes for seamless MPLS is a
> requirement also for exact match FEC has to be a host route.
>
>>
>> And btw LDP FECs where always host routes + label so unlike you say -
>> nothing new needed there. As I recall even TDP was carrying host addresses
>> with tags.
>>
>
> Gyan> Understood that LDP LIB and LFIB label mapping message FEC TLV has
> to contain the exact match host route for the MPLS forwarding plane so
> basically we are back in the same boat with RFC 5283 as it’s not a complete
> solution as it just fixes the IGP RIB/FIB making summarization possible but
> does not fix summarization with LDP as LDP still has to maintain all the
> host routes.
>
> I will try to work on MPLS based update to fix RFC 5283 so LDP can use
> summarization LPM match.
>
> Thx,
>> R.
>>
>> On Sun, Nov 21, 2021 at 3:46 AM Gyan Mishra 
>> wrote:
>>
>>>
>>> Most all operators have not deployed RFC 5283 LDP inter area extension
>>> due to the fact that it shifts the seamless MPLS flooding requirement and
>>> scalability problem from the RIB/FIB to the LFIB.
>>>
>>> So we desperately need a viable IGP summarization solution mitigate
>>> domain wide flooding of host routes.
>>>
>>> Gyan
>>>
>>> On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra 
>>> wrote:
>>>

 Robert

 RFC 5283 provides LDP extension for inter area for LPM summary FEC
 however in this specification the component prefixes are probated via LDP
 which is  how the LDP inter-area extension is able to support
 summarization.

 The problem here is you make IGP scalable with this LDP inter-area
 extension but then you pass the buck to MPLS which now is not scalable as
 all the flooded prefixes are summarized in the IGP but now the LFIB has to
 suffer from the domain wide flooding.

 This issue with domain wide flooding gets much worse with seamless MPLS
 with E2E LSP requirements from core to aggregation layer so now all the
 area and levels within the entire domain had all host routes.  This can be
 pretty tremendous for large operator networks and a huge scalability issue
 that needs a solution.

 See section 7.2

 The solution documented in this document reduces the link state database 
 size in the control plane and the number of FIB
entries in the forwarding plane.  As such, it solves the scaling of

pure IP routers sharing the IGP with MPLS routers.  However, it does
not decrease the number of LFIB entries so is not sufficient to solve
the scaling of MPLS routers.  For this, an additional mechanism is
required (e.g., introducing some MPLS hierarchy in LDP).  This is out
of scope for this document.


 Bottom of section 7.2


 For protocols and applications which need to track egress LER
availability, several solutions can be used, for example:

- Rely on the LDP ordered label distribution control mode -- as
  defined in [LDP 
 ] -- to know the 
 av.ailability of the LSP toward the

  egress LER.  The egress to ingress propagation time of that
  unreachability information is expected to be comparable to the IGP
  (but this may be implementation dependent).

- Advertise LER reachability in the IGP for the purpose of the
  control plane in a way that does not create IP FIB entries in the
  forwarding plane.


 Gyan> So for this to work for egress convergence availability tracking you 
 either are back to flooding the routes in the 

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

On Sun, Nov 21, 2021 at 6:50 AM Robert Raszuk  wrote:

>
> > So we desperately need a viable IGP summarization
>
> And could you elaborate on how summarization is going to work with
> Segment Routing ? Not that I am pushing anyone to go there, but looking
> through the window this seems to be the current trend.
>

Gyan> SR-MPLS as it reuses the MPLS data plane but relies on IGP extension
to flood SID label instead of LDP for prefix and node SID it’s still exact
match host route so the solution we come up with for MPLS would apply to
SR-MPLS.  As for SRv6 it’s standard IP routing LPM based not FEC so
summarization natively works.  My thoughts for SRv6 is that the same
component host route tracking can be used as well with SRv6 or IPv4 or IPv6
forwarding plane.

>
> We rely on leaking as additional information is attached to host routes.
> Stopping that breaks the game.
>

Gyan> Agreed the flooding of host routes for seamless MPLS is a
requirement also for exact match FEC has to be a host route.

>
> And btw LDP FECs where always host routes + label so unlike you say -
> nothing new needed there. As I recall even TDP was carrying host addresses
> with tags.
>

Gyan> Understood that LDP LIB and LFIB label mapping message FEC TLV has to
contain the exact match host route for the MPLS forwarding plane so
basically we are back in the same boat with RFC 5283 as it’s not a complete
solution as it just fixes the IGP RIB/FIB making summarization possible but
does not fix summarization with LDP as LDP still has to maintain all the
host routes.

I will try to work on MPLS based update to fix RFC 5283 so LDP can use
summarization LPM match.

Thx,
> R.
>
> On Sun, Nov 21, 2021 at 3:46 AM Gyan Mishra  wrote:
>
>>
>> Most all operators have not deployed RFC 5283 LDP inter area extension
>> due to the fact that it shifts the seamless MPLS flooding requirement and
>> scalability problem from the RIB/FIB to the LFIB.
>>
>> So we desperately need a viable IGP summarization solution mitigate
>> domain wide flooding of host routes.
>>
>> Gyan
>>
>> On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra 
>> wrote:
>>
>>>
>>> Robert
>>>
>>> RFC 5283 provides LDP extension for inter area for LPM summary FEC
>>> however in this specification the component prefixes are probated via LDP
>>> which is  how the LDP inter-area extension is able to support
>>> summarization.
>>>
>>> The problem here is you make IGP scalable with this LDP inter-area
>>> extension but then you pass the buck to MPLS which now is not scalable as
>>> all the flooded prefixes are summarized in the IGP but now the LFIB has to
>>> suffer from the domain wide flooding.
>>>
>>> This issue with domain wide flooding gets much worse with seamless MPLS
>>> with E2E LSP requirements from core to aggregation layer so now all the
>>> area and levels within the entire domain had all host routes.  This can be
>>> pretty tremendous for large operator networks and a huge scalability issue
>>> that needs a solution.
>>>
>>> See section 7.2
>>>
>>> The solution documented in this document reduces the link state database 
>>> size in the control plane and the number of FIB
>>>entries in the forwarding plane.  As such, it solves the scaling of
>>>
>>>pure IP routers sharing the IGP with MPLS routers.  However, it does
>>>not decrease the number of LFIB entries so is not sufficient to solve
>>>the scaling of MPLS routers.  For this, an additional mechanism is
>>>required (e.g., introducing some MPLS hierarchy in LDP).  This is out
>>>of scope for this document.
>>>
>>>
>>> Bottom of section 7.2
>>>
>>>
>>> For protocols and applications which need to track egress LER
>>>availability, several solutions can be used, for example:
>>>
>>>- Rely on the LDP ordered label distribution control mode -- as
>>>  defined in [LDP 
>>> ] -- to know the 
>>> av.ailability of the LSP toward the
>>>
>>>  egress LER.  The egress to ingress propagation time of that
>>>  unreachability information is expected to be comparable to the IGP
>>>  (but this may be implementation dependent).
>>>
>>>- Advertise LER reachability in the IGP for the purpose of the
>>>  control plane in a way that does not create IP FIB entries in the
>>>  forwarding plane.
>>>
>>>
>>> Gyan> So for this to work for egress convergence availability tracking you 
>>> either are back to flooding the routes in the IGP or use LDP ordered label 
>>> distribution.
>>>
>>>
>>> Even if you used LDP ordered label distribution is still does not solve the 
>>> problem of robbing Peter to pay Paul now dumping the flooding of host 
>>> routes on MPLS LFIB making it not scalable.
>>>
>>>
>>> Most vendors by default use LDP ordered label distribution defined in RFC 
>>> 3036.
>>>
>>>
>>> However, net-net the problem is not solved.
>>>
>>>
>>>
>>>
>>> Kind Regards
>>>
>>> Gyan
>>>
>>> On Fri, Nov 19, 2021 at 3:25 PM Robert Raszuk  wrote:

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Hi Aditya,


> Meanwhile, if you have the ABR as the inline RR changing the BGP NH to
> itself and hiding the egress PE, even in that case ingress PE doesn’t need
> to worry about the egress PE as long as BGP service route is available with
> ABR as NH and let ABR figure out the available egress PE.
>

Clever idea - unfortunately does not work :(

PEs along with next hop advertise service information (for example VPN
label demux) which is unfortunately not easy to synchronize across
multihomed site PEs.

So ABR can not set nhs and hide this complexity as it would have to swap
the VPN labels in the packets. If you want to make ABR acting as Option B
where they are full VPN gateways to the areas sure - that is deployed today
- but where most of the needs are for unreachable is when you use option C
or construct end to end path in one way or the other with no bottlenecks on
the way.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> So we desperately need a viable IGP summarization

And could you elaborate on how summarization is going to work with
Segment Routing ? Not that I am pushing anyone to go there, but looking
through the window this seems to be the current trend.

We rely on leaking as additional information is attached to host routes.
Stopping that breaks the game.

And btw LDP FECs where always host routes + label so unlike you say -
nothing new needed there. As I recall even TDP was carrying host addresses
with tags.

Thx,
R.

On Sun, Nov 21, 2021 at 3:46 AM Gyan Mishra  wrote:

>
> Most all operators have not deployed RFC 5283 LDP inter area extension due
> to the fact that it shifts the seamless MPLS flooding requirement and
> scalability problem from the RIB/FIB to the LFIB.
>
> So we desperately need a viable IGP summarization solution mitigate domain
> wide flooding of host routes.
>
> Gyan
>
> On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra  wrote:
>
>>
>> Robert
>>
>> RFC 5283 provides LDP extension for inter area for LPM summary FEC
>> however in this specification the component prefixes are probated via LDP
>> which is  how the LDP inter-area extension is able to support
>> summarization.
>>
>> The problem here is you make IGP scalable with this LDP inter-area
>> extension but then you pass the buck to MPLS which now is not scalable as
>> all the flooded prefixes are summarized in the IGP but now the LFIB has to
>> suffer from the domain wide flooding.
>>
>> This issue with domain wide flooding gets much worse with seamless MPLS
>> with E2E LSP requirements from core to aggregation layer so now all the
>> area and levels within the entire domain had all host routes.  This can be
>> pretty tremendous for large operator networks and a huge scalability issue
>> that needs a solution.
>>
>> See section 7.2
>>
>> The solution documented in this document reduces the link state database 
>> size in the control plane and the number of FIB
>>entries in the forwarding plane.  As such, it solves the scaling of
>>
>>pure IP routers sharing the IGP with MPLS routers.  However, it does
>>not decrease the number of LFIB entries so is not sufficient to solve
>>the scaling of MPLS routers.  For this, an additional mechanism is
>>required (e.g., introducing some MPLS hierarchy in LDP).  This is out
>>of scope for this document.
>>
>>
>> Bottom of section 7.2
>>
>>
>> For protocols and applications which need to track egress LER
>>availability, several solutions can be used, for example:
>>
>>- Rely on the LDP ordered label distribution control mode -- as
>>  defined in [LDP 
>> ] -- to know the 
>> av.ailability of the LSP toward the
>>
>>  egress LER.  The egress to ingress propagation time of that
>>  unreachability information is expected to be comparable to the IGP
>>  (but this may be implementation dependent).
>>
>>- Advertise LER reachability in the IGP for the purpose of the
>>  control plane in a way that does not create IP FIB entries in the
>>  forwarding plane.
>>
>>
>> Gyan> So for this to work for egress convergence availability tracking you 
>> either are back to flooding the routes in the IGP or use LDP ordered label 
>> distribution.
>>
>>
>> Even if you used LDP ordered label distribution is still does not solve the 
>> problem of robbing Peter to pay Paul now dumping the flooding of host routes 
>> on MPLS LFIB making it not scalable.
>>
>>
>> Most vendors by default use LDP ordered label distribution defined in RFC 
>> 3036.
>>
>>
>> However, net-net the problem is not solved.
>>
>>
>>
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Fri, Nov 19, 2021 at 3:25 PM Robert Raszuk  wrote:
>>
>>> Peter,
>>>
>>>
 yes, but it's not specific to flat areas. Even in multi-area
 deployments
 the host routing is mandated by MPLS.
>>>
>>>
>>> In the early days of MPLS yes that was the case.
>>>
>>> But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)
>>>
>>> https://datatracker.ietf.org/doc/html/rfc5283
>>>
>>> In these multi-area deployments
 the host routes are sent everywhere, updates are triggered regardless
 of
 the failure type. IGPs are effectively providing liveness service
 between PEs in any MPLS network.

>>>
>>> That is true too - as folks just do not know how to configure BGP
>>> properly (if BGP is used for services).
>>>
>>> That leaves us the space what to do where there is no BGP carrying
>>> services. Or BGP implementation is broken and can not do the right thing.
>>>
>>> For the pulse proposal - no one answered the question posted what is a
>>> definition of mass failure. But maybe that will be the secret sauce of a
>>> vendor :) ?
>>>
>>> The fact that we are all in agreement that some network events will not
>>> work that well with the proposed solution seems to be a sufficient reason
>>> for me to consider different solution(s).
>>>
>>> Thx,
>>> R.
>>>

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Chris:

We have considered let BGP send the unreachable information in some 
situations(Robert is also trying to propose this?) But the key difference is 
that the host knows the reachability of sever via default route, not via BGP, 
then leak such information within is not helpful to the mentioned service.
But BGP NH or Tunnel Endpoint is relying on the IGP, knowing such unreachable 
information can certainly help the converge or switch of the overlay service on 
top of them, for example BGP PIC performance.

Aijun Wang
China Telecom

> On Nov 21, 2021, at 16:26, Christian Hopps  wrote:
> 
> 
> 
>>> On Nov 21, 2021, at 3:09 AM, Aijun Wang  wrote:
>>> 
>>> Hi, Tony:
>>> 
>>> Aijun Wang
>>> China Telecom
>>> 
 On Nov 21, 2021, at 15:17, Tony Li  wrote:
 
 
 Hi Aijun,
 
> The ABR should do the summary work based on the liveness, right?
 
 
 No. ABRs advertised statically configured prefixes for the area. Anything 
 else would cause flap. And it’s purely reachability, not liveness. There 
 can be zero live nodes within an area and the ABR should still advertise 
 its summary.
>>> 
>>> [WAJ] What the usage of the summary advertisement in such conditions 
>>> excepts it misleads the nodes within the area it attached?
>> 
>> Perhaps it would help to consider another example of reachability vs 
>> liveness. Summaries are just one form of the more general concept of 
>> aggregation. Consider the Internet and aggregation done at the AS level. 
>> Would you have BGP flapping routes in the entire Internet based on hosts 
>> going up and down at the originating AS? No, we do not expect it. When you 
>> try to connect to a server in azure or aws etc you don’t expect routing to 
>> let you know that a server is down through an unreachable routing message, 
>> you expect TCP to tell you it can’t connect to it.
>> 
>> Thanks,
>> Chris.
>> 
>> 
 
 
 Pub/Sub style notification seems promising, but it will require the ABR 
 store the subscription state which will certainly degrade its performance. 
>>> 
>>> 
>>> Baloney. A notification list address post-SPF is wholly outside of the 
>>> performance path.
>> 
>> [WAJ] Is there any existing mechanism to accomplish your proposal among the 
>> PEs?
>> 
>>> 
>>> 
 On the other hand, let the receiver decides whether to utilize such 
 information is distributed design and more robust? There is no much work 
 to be done when they receive the PUAM message. Just to judge the 
 originator of the prefix is valid or not.
>>> 
>>> 
>>> Correct, you just flood information throughout the network that most of the 
>>> nodes don’t care about, burdening others with additional flooding and 
>>> database scale issues, just when there are failures.
>> 
>> [WAJ] Within the network, the number of PEs often surpasses the number of P 
>> nodes. Even with P nodes, such information can also help them reroute/switch 
>> to other endpoints along the SRv6 tunnel backup path.
>> I think you could imagine the signal just as the alert information that 
>> often seen on the highway. It can certainly save the driver’s time. Wouldn’t 
>> you like to know such information immediately? Or you just drive as planned 
>> until near the target to know the road is broken?
>> 
>>> 
>>> Tony
> 
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Christian Hopps]

> On Nov 21, 2021, at 3:09 AM, Aijun Wang  wrote:
> 
> Hi, Tony:
> 
> Aijun Wang
> China Telecom
> 
>> On Nov 21, 2021, at 15:17, Tony Li  wrote:
>> 
>> 
>> Hi Aijun,
>> 
>>> The ABR should do the summary work based on the liveness, right?
>> 
>> 
>> No. ABRs advertised statically configured prefixes for the area. Anything 
>> else would cause flap. And it’s purely reachability, not liveness. There can 
>> be zero live nodes within an area and the ABR should still advertise its 
>> summary.
> 
> [WAJ] What the usage of the summary advertisement in such conditions excepts 
> it misleads the nodes within the area it attached?

Perhaps it would help to consider another example of reachability vs liveness. 
Summaries are just one form of the more general concept of aggregation. 
Consider the Internet and aggregation done at the AS level. Would you have BGP 
flapping routes in the entire Internet based on hosts going up and down at the 
originating AS? No, we do not expect it. When you try to connect to a server in 
azure or aws etc you don’t expect routing to let you know that a server is down 
through an unreachable routing message, you expect TCP to tell you it can’t 
connect to it.

Thanks,
Chris.


>> 
>> 
>>> Pub/Sub style notification seems promising, but it will require the ABR 
>>> store the subscription state which will certainly degrade its performance. 
>> 
>> 
>> Baloney. A notification list address post-SPF is wholly outside of the 
>> performance path.
> 
> [WAJ] Is there any existing mechanism to accomplish your proposal among the 
> PEs?
> 
>> 
>> 
>>> On the other hand, let the receiver decides whether to utilize such 
>>> information is distributed design and more robust? There is no much work to 
>>> be done when they receive the PUAM message. Just to judge the originator of 
>>> the prefix is valid or not.
>> 
>> 
>> Correct, you just flood information throughout the network that most of the 
>> nodes don’t care about, burdening others with additional flooding and 
>> database scale issues, just when there are failures.
> 
> [WAJ] Within the network, the number of PEs often surpasses the number of P 
> nodes. Even with P nodes, such information can also help them reroute/switch 
> to other endpoints along the SRv6 tunnel backup path.
> I think you could imagine the signal just as the alert information that often 
> seen on the highway. It can certainly save the driver’s time. Wouldn’t you 
> like to know such information immediately? Or you just drive as planned until 
> near the target to know the road is broken?
> 
>> 
>> Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 21, 2021, at 15:17, Tony Li  wrote:
> 
> 
> Hi Aijun,
> 
>> The ABR should do the summary work based on the liveness, right?
> 
> 
> No. ABRs advertised statically configured prefixes for the area. Anything 
> else would cause flap. And it’s purely reachability, not liveness. There can 
> be zero live nodes within an area and the ABR should still advertise its 
> summary.

[WAJ] What the usage of the summary advertisement in such conditions excepts it 
misleads the nodes within the area it attached?
> 
> 
>> Pub/Sub style notification seems promising, but it will require the ABR 
>> store the subscription state which will certainly degrade its performance. 
> 
> 
> Baloney. A notification list address post-SPF is wholly outside of the 
> performance path.

[WAJ] Is there any existing mechanism to accomplish your proposal among the PEs?

> 
> 
>> On the other hand, let the receiver decides whether to utilize such 
>> information is distributed design and more robust? There is no much work to 
>> be done when they receive the PUAM message. Just to judge the originator of 
>> the prefix is valid or not.
> 
> 
> Correct, you just flood information throughout the network that most of the 
> nodes don’t care about, burdening others with additional flooding and 
> database scale issues, just when there are failures.

[WAJ] Within the network, the number of PEs often surpasses the number of P 
nodes. Even with P nodes, such information can also help them reroute/switch to 
other endpoints along the SRv6 tunnel backup path.
I think you could imagine the signal just as the alert information that often 
seen on the highway. It can certainly save the driver’s time. Wouldn’t you like 
to know such information immediately? Or you just drive as planned until near 
the target to know the road is broken?

> 
> Tony
> 

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

> The ABR should do the summary work based on the liveness, right?


No. ABRs advertised statically configured prefixes for the area. Anything else 
would cause flap. And it’s purely reachability, not liveness. There can be zero 
live nodes within an area and the ABR should still advertise its summary.


> Pub/Sub style notification seems promising, but it will require the ABR store 
> the subscription state which will certainly degrade its performance. 


Baloney. A notification list address post-SPF is wholly outside of the 
performance path.


> On the other hand, let the receiver decides whether to utilize such 
> information is distributed design and more robust? There is no much work to 
> be done when they receive the PUAM message. Just to judge the originator of 
> the prefix is valid or not.


Correct, you just flood information throughout the network that most of the 
nodes don’t care about, burdening others with additional flooding and database 
scale issues, just when there are failures.

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Aditya:

Aijun Wang
China Telecom

> On Nov 21, 2021, at 12:56, Aditya Kaul  wrote:
> 
> 
> IMHO BGP(overlay service) should ideally be responsible for dishing out your 
> cuisine at the particular restaurant, so if your dish isn’t available you 
> shouldn’t head there in the first place.

[WAJ] The IGP just to assure the road to the node or the node itself is 
available. If these are not available, even the BGP can dish out the cuisine, 
it is not available to the driver.

> 
> Meanwhile, if you have the ABR as the inline RR changing the BGP NH to itself 
> and hiding the egress PE, even in that case ingress PE doesn’t need to worry 
> about the egress PE as long as BGP service route is available with ABR as NH 
> and let ABR figure out the available egress PE.

[WAJ] Normally, the RR does not sit inline the forwarding path among PEs, but 
ABR does. If the PEs span multiple areas, your design requires several pairs of 
RR, but indeed we need only one pair of them to accomplish the BGP sessions 
across different areas.

> I guess your other assumption might relate to BGP service convergence being 
> slower than the IGP but then that's a different discussion.
> 
> Hopefully I am not misconstruing the thread's intent.
> 
> Regards,
> Aditya
>> On Nov 21, 2021, at 11:30 AM, Aijun Wang  wrote:
>> 
>> Hi, Robert:
>> If the ABR know the restaurant are closing now, it can certainly let the 
>> driver change to the backup restaurant immediately and avoid the driver 
>> waste the miles. Wouldn’t this mechanism give the driver better experiences?
>> 
>> Anyway, the unreachable information is rare, controllable. The 
>> implementation/operator can open it only to the loop back address of the PE 
>> or Tunnel Ends.
>> 
>> Aijun Wang
>> China Telecom
>> 
>>> On Nov 21, 2021, at 09:03, Robert Raszuk  wrote:
>>> 
>>> 
>>> 
 The ABR should do the summary work based on the liveness, right?
>>> 
>>> Really ???
>>> 
>>> It seems we are as the WG in a form of a disconnect on that one .. rather 
>>> fundamental to what IGPs are or are supposed to be.  
>>> 
>>> One way to look at them is an analogy to road signs which first tell you 
>>> the direction to state/country, then city, then district/province, then 
>>> street. They do not blast you with pulses or stars that there is no one at 
>>> home or that restaurant is closed. 
>>> 
>>> On the other hand some folks here state that while road signs are great 
>>> (summary analogy) we do need to know by road signs if the restaurant is 
>>> open before we head there. Hmm just imagine how would that work in 
>>> practice. Just imagine blasting this all over US when no one except few 
>>> folks is even interested in this information. Leave alone that their 
>>> infrastructure just is not designed to keep up with it. 
>>> 
>>> Removing summary just because x % of restaurants are closed would be like 
>>> putting duct tape on traffic signs. Yes with the e-signs it is technically 
>>> possible but is this the right thing to do ? 
>>> 
>>> If the restaurant is open you either use google service overlay (think BGP) 
>>> to tell you that with some amount of probability or you call them directly 
>>> and check before you jump into the car to drive (think directed in data 
>>> plane probe). 
>>> 
>>> Last even if the restaurant is open there is no assurance they will take 
>>> your order when you arrive as they may experience power outage or run out 
>>> of rice for your favourite meal. So liveness of the PE does not really mean 
>>> that your service will be delivered. 
>>> 
>>> Kind regards,
>>> R.
>>> 
>> 
>> ___
>> 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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aditya Kaul]

IMHO BGP(overlay service) should ideally be responsible for dishing out
your cuisine at the particular restaurant, so if your dish isn’t available
you shouldn’t head there in the first place.

Meanwhile, if you have the ABR as the inline RR changing the BGP NH to
itself and hiding the egress PE, even in that case ingress PE doesn’t need
to worry about the egress PE as long as BGP service route is available with
ABR as NH and let ABR figure out the available egress PE.I guess your other
assumption might relate to BGP service convergence being slower than the
IGP but then that's a different discussion.

Hopefully I am not misconstruing the thread's intent.

Regards,
Aditya

On Nov 21, 2021, at 11:30 AM, Aijun Wang  wrote:

Hi, Robert:
If the ABR know the restaurant are closing now, it can certainly let the
driver change to the backup restaurant immediately and avoid the driver
waste the miles. Wouldn’t this mechanism give the driver better experiences?

Anyway, the unreachable information is rare, controllable. The
implementation/operator can open it only to the loop back address of the PE
or Tunnel Ends.

Aijun Wang
China Telecom

On Nov 21, 2021, at 09:03, Robert Raszuk  wrote:



The ABR should do the summary work based on the liveness, right?


Really ???

It seems we are as the WG in a form of a disconnect on that one .. rather
fundamental to what IGPs are or are supposed to be.

One way to look at them is an analogy to road signs which first tell you
the direction to state/country, then city, then district/province, then
street. They do not blast you with pulses or stars that there is no one at
home or that restaurant is closed.

On the other hand some folks here state that while road signs are great
(summary analogy) we do need to know by road signs if the restaurant is
open before we head there. Hmm just imagine how would that work in
practice. Just imagine blasting this all over US when no one except few
folks is even interested in this information. Leave alone that their
infrastructure just is not designed to keep up with it.

Removing summary just because x % of restaurants are closed would be like
putting duct tape on traffic signs. Yes with the e-signs it is technically
possible but is this the right thing to do ?

If the restaurant is open you either use google service overlay (think BGP)
to tell you that with some amount of probability or you call them directly
and check before you jump into the car to drive (think directed in data
plane probe).

Last even if the restaurant is open there is no assurance they will take
your order when you arrive as they may experience power outage or run out
of rice for your favourite meal. So liveness of the PE does not really mean
that your service will be delivered.

Kind regards,
R.


___
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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Robert:
If the ABR know the restaurant are closing now, it can certainly let the driver 
change to the backup restaurant immediately and avoid the driver waste the 
miles. Wouldn’t this mechanism give the driver better experiences?

Anyway, the unreachable information is rare, controllable. The 
implementation/operator can open it only to the loop back address of the PE or 
Tunnel Ends.

Aijun Wang
China Telecom

> On Nov 21, 2021, at 09:03, Robert Raszuk  wrote:
> 
> 
> 
> > The ABR should do the summary work based on the liveness, right?
> 
> Really ???
> 
> It seems we are as the WG in a form of a disconnect on that one .. rather 
> fundamental to what IGPs are or are supposed to be.  
> 
> One way to look at them is an analogy to road signs which first tell you the 
> direction to state/country, then city, then district/province, then street. 
> They do not blast you with pulses or stars that there is no one at home or 
> that restaurant is closed. 
> 
> On the other hand some folks here state that while road signs are great 
> (summary analogy) we do need to know by road signs if the restaurant is open 
> before we head there. Hmm just imagine how would that work in practice. Just 
> imagine blasting this all over US when no one except few folks is even 
> interested in this information. Leave alone that their infrastructure just is 
> not designed to keep up with it. 
> 
> Removing summary just because x % of restaurants are closed would be like 
> putting duct tape on traffic signs. Yes with the e-signs it is technically 
> possible but is this the right thing to do ? 
> 
> If the restaurant is open you either use google service overlay (think BGP) 
> to tell you that with some amount of probability or you call them directly 
> and check before you jump into the car to drive (think directed in data plane 
> probe). 
> 
> Last even if the restaurant is open there is no assurance they will take your 
> order when you arrive as they may experience power outage or run out of rice 
> for your favourite meal. So liveness of the PE does not really mean that your 
> service will be delivered. 
> 
> Kind regards,
> R.
> 

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Tony

I agree with Peter that the job of the IGP is to provide reachability of
all prefixes within the routing domain independent of mask.

So the optimization we are looking for is simply trying to make
summarization LPM match instead of exact match possible with MPLS within an
AS flooding of all host routes is done for LSP to build within an AS,
however the domain wide flooding issue gets exacerbated with seamless MPLS
for E2E LSP  Core end Aggregation layers for Access layer E2E LSP.

RFC 5283 provides a LDP inter area extension however the specification
shifts the problem from the IGP RIB/FIB to  the MPLS LFIB.

So we don’t have a solution to be able to track component prefix host
routes that are part of a summary route to make summarization a viable
solution for MPLS.  This would allow us to use the RFC 5283 inter area LDP
extension and not have to flood the host routes into MPLS LFIB so can be
suppressed with LDP filter once we are able to track the component prefixes
that are part of the LPM summary FEC.

This solution would also help speed up convergence for LPM summarization
for IP based networks as well as  SRv6.

Kind Regards

Gyan

On Fri, Nov 19, 2021 at 12:03 PM Peter Psenak  wrote:

> Hi Tony,
>
> On 19/11/2021 17:55, Tony Li wrote:
> >
> > Hi Peter,
> >
> >> yes, but it's not specific to flat areas. Even in multi-area
> >> deployments the host routing is mandated by MPLS. In these multi-area
> >> deployments the host routes are sent everywhere, updates are triggered
> >> regardless of the failure type. IGPs are effectively providing
> >> liveness service between PEs in any MPLS network.
> >
> >
> > Please re-read what you just wrote. The fact that someone decided to
> > leak host routes is NOT something that the IGP was designed to do.
> > Leaking negative updates is also wrong. Two wrongs don’t make a right.
>
> host routes are just routes, like any other routes, for which IGP
> provide reachability. What's the length of the mask does not really
> matter. The fact that they are used for liveness by some application is
> also transparent to IGP.
>
>
> >
> > The fact that it is effectively providing liveness is wholly irrelevant.
> > It’s still the wrong thing to do.
>
> well, then I guess we just agree to disagree.
>
> thanks,
> Peter
>
> >
> >
> >> If IGPs can provide full liveness service between PEs today, why doing
> >> 'optimized negative liveness service' would be architecturally wrong?
> >
> >
> > IGPs could also deliver web pages. Capability doesn’t imply that it’s
> > architecturally appropriate. The IGP is supposed to provide reachability
> > and path computation at local scale and with stability.  That’s it. One
> > might well argue that we’re not doing that very well yet. Maybe we
> > should stick to our knitting.
> >
> > T
> >
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Most all operators have not deployed RFC 5283 LDP inter area extension due
to the fact that it shifts the seamless MPLS flooding requirement and
scalability problem from the RIB/FIB to the LFIB.

So we desperately need a viable IGP summarization solution mitigate domain
wide flooding of host routes.

Gyan

On Sat, Nov 20, 2021 at 9:17 PM Gyan Mishra  wrote:

>
> Robert
>
> RFC 5283 provides LDP extension for inter area for LPM summary FEC however
> in this specification the component prefixes are probated via LDP which is
>  how the LDP inter-area extension is able to support summarization.
>
> The problem here is you make IGP scalable with this LDP inter-area
> extension but then you pass the buck to MPLS which now is not scalable as
> all the flooded prefixes are summarized in the IGP but now the LFIB has to
> suffer from the domain wide flooding.
>
> This issue with domain wide flooding gets much worse with seamless MPLS
> with E2E LSP requirements from core to aggregation layer so now all the
> area and levels within the entire domain had all host routes.  This can be
> pretty tremendous for large operator networks and a huge scalability issue
> that needs a solution.
>
> See section 7.2
>
> The solution documented in this document reduces the link state database size 
> in the control plane and the number of FIB
>entries in the forwarding plane.  As such, it solves the scaling of
>
>pure IP routers sharing the IGP with MPLS routers.  However, it does
>not decrease the number of LFIB entries so is not sufficient to solve
>the scaling of MPLS routers.  For this, an additional mechanism is
>required (e.g., introducing some MPLS hierarchy in LDP).  This is out
>of scope for this document.
>
>
> Bottom of section 7.2
>
>
> For protocols and applications which need to track egress LER
>availability, several solutions can be used, for example:
>
>- Rely on the LDP ordered label distribution control mode -- as
>  defined in [LDP ] 
> -- to know the av.ailability of the LSP toward the
>
>  egress LER.  The egress to ingress propagation time of that
>  unreachability information is expected to be comparable to the IGP
>  (but this may be implementation dependent).
>
>- Advertise LER reachability in the IGP for the purpose of the
>  control plane in a way that does not create IP FIB entries in the
>  forwarding plane.
>
>
> Gyan> So for this to work for egress convergence availability tracking you 
> either are back to flooding the routes in the IGP or use LDP ordered label 
> distribution.
>
>
> Even if you used LDP ordered label distribution is still does not solve the 
> problem of robbing Peter to pay Paul now dumping the flooding of host routes 
> on MPLS LFIB making it not scalable.
>
>
> Most vendors by default use LDP ordered label distribution defined in RFC 
> 3036.
>
>
> However, net-net the problem is not solved.
>
>
>
>
> Kind Regards
>
> Gyan
>
> On Fri, Nov 19, 2021 at 3:25 PM Robert Raszuk  wrote:
>
>> Peter,
>>
>>
>>> yes, but it's not specific to flat areas. Even in multi-area deployments
>>> the host routing is mandated by MPLS.
>>
>>
>> In the early days of MPLS yes that was the case.
>>
>> But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)
>>
>> https://datatracker.ietf.org/doc/html/rfc5283
>>
>> In these multi-area deployments
>>> the host routes are sent everywhere, updates are triggered regardless of
>>> the failure type. IGPs are effectively providing liveness service
>>> between PEs in any MPLS network.
>>>
>>
>> That is true too - as folks just do not know how to configure BGP
>> properly (if BGP is used for services).
>>
>> That leaves us the space what to do where there is no BGP carrying
>> services. Or BGP implementation is broken and can not do the right thing.
>>
>> For the pulse proposal - no one answered the question posted what is a
>> definition of mass failure. But maybe that will be the secret sauce of a
>> vendor :) ?
>>
>> The fact that we are all in agreement that some network events will not
>> work that well with the proposed solution seems to be a sufficient reason
>> for me to consider different solution(s).
>>
>> Thx,
>> R.
>>
> --
>
> 
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mis...@verizon.com *
>
>
>
> *M 301 502-1347*
>
> --



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Gyan Mishra]

Robert

RFC 5283 provides LDP extension for inter area for LPM summary FEC however
in this specification the component prefixes are probated via LDP which is
 how the LDP inter-area extension is able to support summarization.

The problem here is you make IGP scalable with this LDP inter-area
extension but then you pass the buck to MPLS which now is not scalable as
all the flooded prefixes are summarized in the IGP but now the LFIB has to
suffer from the domain wide flooding.

This issue with domain wide flooding gets much worse with seamless MPLS
with E2E LSP requirements from core to aggregation layer so now all the
area and levels within the entire domain had all host routes.  This can be
pretty tremendous for large operator networks and a huge scalability issue
that needs a solution.

See section 7.2

The solution documented in this document reduces the link state
database size in the control plane and the number of FIB
   entries in the forwarding plane.  As such, it solves the scaling of

   pure IP routers sharing the IGP with MPLS routers.  However, it does
   not decrease the number of LFIB entries so is not sufficient to solve
   the scaling of MPLS routers.  For this, an additional mechanism is
   required (e.g., introducing some MPLS hierarchy in LDP).  This is out
   of scope for this document.


Bottom of section 7.2


For protocols and applications which need to track egress LER
   availability, several solutions can be used, for example:

   - Rely on the LDP ordered label distribution control mode -- as
 defined in [LDP
] -- to know
the av.ailability of the LSP toward the

 egress LER.  The egress to ingress propagation time of that
 unreachability information is expected to be comparable to the IGP
 (but this may be implementation dependent).

   - Advertise LER reachability in the IGP for the purpose of the
 control plane in a way that does not create IP FIB entries in the
 forwarding plane.


Gyan> So for this to work for egress convergence availability tracking
you either are back to flooding the routes in the IGP or use LDP
ordered label distribution.


Even if you used LDP ordered label distribution is still does not
solve the problem of robbing Peter to pay Paul now dumping the
flooding of host routes on MPLS LFIB making it not scalable.


Most vendors by default use LDP ordered label distribution defined in RFC 3036.


However, net-net the problem is not solved.




Kind Regards

Gyan
On Fri, Nov 19, 2021 at 3:25 PM Robert Raszuk  wrote:

> Peter,
>
>
>> yes, but it's not specific to flat areas. Even in multi-area deployments
>> the host routing is mandated by MPLS.
>
>
> In the early days of MPLS yes that was the case.
>
> But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)
>
> https://datatracker.ietf.org/doc/html/rfc5283
>
> In these multi-area deployments
>> the host routes are sent everywhere, updates are triggered regardless of
>> the failure type. IGPs are effectively providing liveness service
>> between PEs in any MPLS network.
>>
>
> That is true too - as folks just do not know how to configure BGP properly
> (if BGP is used for services).
>
> That leaves us the space what to do where there is no BGP carrying
> services. Or BGP implementation is broken and can not do the right thing.
>
> For the pulse proposal - no one answered the question posted what is a
> definition of mass failure. But maybe that will be the secret sauce of a
> vendor :) ?
>
> The fact that we are all in agreement that some network events will not
> work that well with the proposed solution seems to be a sufficient reason
> for me to consider different solution(s).
>
> Thx,
> R.
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> The ABR should do the summary work based on the liveness, right?

Really ???

It seems we are as the WG in a form of a disconnect on that one .. rather
fundamental to what IGPs are or are supposed to be.

One way to look at them is an analogy to road signs which first tell you
the direction to state/country, then city, then district/province, then
street. They do not blast you with pulses or stars that there is no one at
home or that restaurant is closed.

On the other hand some folks here state that while road signs are great
(summary analogy) we do need to know by road signs if the restaurant is
open before we head there. Hmm just imagine how would that work in
practice. Just imagine blasting this all over US when no one except few
folks is even interested in this information. Leave alone that their
infrastructure just is not designed to keep up with it.

Removing summary just because x % of restaurants are closed would be like
putting duct tape on traffic signs. Yes with the e-signs it is technically
possible but is this the right thing to do ?

If the restaurant is open you either use google service overlay (think BGP)
to tell you that with some amount of probability or you call them directly
and check before you jump into the car to drive (think directed in data
plane probe).

Last even if the restaurant is open there is no assurance they will take
your order when you arrive as they may experience power outage or run out
of rice for your favourite meal. So liveness of the PE does not really mean
that your service will be delivered.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

The ABR should do the summary work based on the liveness, right? If most of 
addresses within the summary are unreachable/dead as it knows, should it 
advertise the detail reachable/liveness instead of the misleading summary 
address?
From this POV, we think the ABR or IGP should advertise as precise as liveness 
information, not the reachable but dead information. 
Pub/Sub style notification seems promising, but it will require the ABR store 
the subscription state which will certainly degrade its performance. 
On the other hand, let the receiver decides whether to utilize such information 
is distributed design and more robust? There is no much work to be done when 
they receive the PUAM message. Just to judge the originator of the prefix is 
valid or not.


Aijun Wang
China Telecom

> On Nov 21, 2021, at 01:40, Tony Li  wrote:
> 
> 
> 
> Hi Aijun,
> 
>>> Again, you’re confusing reachability with liveness. A summary address does 
>>> NOT imply liveness.  If you have a prefix 1/8, that does not mean that 
>>> 1.1.1.1 is up and will accept a TCP connection or reply to a ping.
>> 
>> [WAJ] Reachability is not equal to liveness, but the dead is equal to 
>> unreachability.  
> 
> 
> Sorry, no.  Dead is a lack of liveness.  You still have reachability.  You 
> send packets and they still make it to the system. Ok, no one’s home and the 
> packets fall on the floor, but they were delivered.
> 
> 
>> What we want is to alert other peer that some prefixes within the summary is 
>> unreachable and they should do some thing, for example, fast reroute to 
>> other nodes etc.
>> It is unreasonable that the ABR knows such unreachability but still claims 
>> that it can reach all the prefixes the summary address covered.
> 
> 
> Again, the ABR is claiming (and providing) reachability. You’re asking for 
> negative liveness. That’s not something that routing protocols do, and can’t 
> do without surrendering abstraction and scalability.
> 
> 
>>> Our job is to not design in mechanisms that lead to these bad outcomes.
>> 
>> [WAJ] I agree with you on this point. But how about your comments for such 
>> considerations in 
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7.
>>  We have considered how to reaction to the mass outrage at the beginning.
> 
> 
> Those seem somewhat destructive. Not advertising the summary breaks all other 
> services.  Instant network disaster. Having a threshold for the number of 
> negative advertisements indicates that you don’t have a general, scalable 
> solution.
> 
> 
 There’s a reason that we’ve never gone down the path of hole punching 
 before.  And yes, it’s been discussed before, decades ago.
 [WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, 
 such solutions will be needed more and more. I think it is different from 
 the situation existing decades ago.
>>> 
>>> 
>>> Nothing has changed except the encoding. We’ve been tunneling for decades. 
>>> We’ve been summarizing for decades. We’ve been rejecting hole punching for 
>>> decades. We’ve even been tunneling using source routing and other high 
>>> overhead mechanisms for decades. That ended up rejected too.
>> 
>>> If you really want the service, please change the architecture to a 
>>> registration mechanism as I outlined. This can and should be done outside 
>>> of the IGP.  You’re asking for a proxy liveness service and that’s entirely 
>>> doable.
>> 
>> [WAJ] The registration mechanism, like BFD? requires the configuration 
>> overhead, is difficult to deploy in the large scale network. That the reason 
>> we prefer to the automatic mechanism.
> 
> 
> No. You don’t need BFD.  You want a notification from the ABR.  This can be 
> done automatically.  The ABR advertises that it provides a liveness 
> notitification service as part of router capabilities. Interested parties 
> open a connection to the ABR and indicate the hosts/prefixes that it is 
> interested in. When there’s a failure, the ABR provides that indication. It 
> can also provide a positive indication when the system is back up. True 
> liveness!
> 
> Tony
> 
> ___
> 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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

>> Again, you’re confusing reachability with liveness. A summary address does 
>> NOT imply liveness.  If you have a prefix 1/8, that does not mean that 
>> 1.1.1.1 is up and will accept a TCP connection or reply to a ping.
> 
> [WAJ] Reachability is not equal to liveness, but the dead is equal to 
> unreachability.  


Sorry, no.  Dead is a lack of liveness.  You still have reachability.  You send 
packets and they still make it to the system. Ok, no one’s home and the packets 
fall on the floor, but they were delivered.


> What we want is to alert other peer that some prefixes within the summary is 
> unreachable and they should do some thing, for example, fast reroute to other 
> nodes etc.
> It is unreasonable that the ABR knows such unreachability but still claims 
> that it can reach all the prefixes the summary address covered.


Again, the ABR is claiming (and providing) reachability. You’re asking for 
negative liveness. That’s not something that routing protocols do, and can’t do 
without surrendering abstraction and scalability.


>> Our job is to not design in mechanisms that lead to these bad outcomes.
> 
> [WAJ] I agree with you on this point. But how about your comments for such 
> considerations in 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7
>  
> .
>  We have considered how to reaction to the mass outrage at the beginning.


Those seem somewhat destructive. Not advertising the summary breaks all other 
services.  Instant network disaster. Having a threshold for the number of 
negative advertisements indicates that you don’t have a general, scalable 
solution.


>>> There’s a reason that we’ve never gone down the path of hole punching 
>>> before.  And yes, it’s been discussed before, decades ago.
>>> [WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such 
>>> solutions will be needed more and more. I think it is different from the 
>>> situation existing decades ago.
>> 
>> 
>> Nothing has changed except the encoding. We’ve been tunneling for decades. 
>> We’ve been summarizing for decades. We’ve been rejecting hole punching for 
>> decades. We’ve even been tunneling using source routing and other high 
>> overhead mechanisms for decades. That ended up rejected too.
> 
>> If you really want the service, please change the architecture to a 
>> registration mechanism as I outlined. This can and should be done outside of 
>> the IGP.  You’re asking for a proxy liveness service and that’s entirely 
>> doable.
> 
> [WAJ] The registration mechanism, like BFD? requires the configuration 
> overhead, is difficult to deploy in the large scale network. That the reason 
> we prefer to the automatic mechanism.


No. You don’t need BFD.  You want a notification from the ABR.  This can be 
done automatically.  The ABR advertises that it provides a liveness 
notitification service as part of router capabilities. Interested parties open 
a connection to the ABR and indicate the hosts/prefixes that it is interested 
in. When there’s a failure, the ABR provides that indication. It can also 
provide a positive indication when the system is back up. True liveness!

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Aijun,


> [WAJ] I agree with you on this point. But how about your comments for such
> considerations in
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7.
> We have considered how to reaction to the mass outrage at the beginning.
>

That section does talks about other aspect of this mechanism.

Assume I have hierarchical IGP with 10,000 nodes.

Most PEs send service traffic to the local hubs only. Sporadically they may
send traffic to other PEs in other areas - say to 1% of them. Service
routes and most of remote next hops are dropped by RT filtering.

Tell me why do you propose a mechanism which puts burden on network
elements by blasting them with information they are never interested in ?
Leave alone that such information is completely not needed also on the P
routers in the core area and other areas.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 19, 2021, at 23:51, Tony Li  wrote:
> 
> 
> Hi Aijun,
> 
>> There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. 
>> That’s not a property that it was meant to provide.  
>> [WAJ] The IGP advertises the summary reachability. The overlay service(BGP 
>> or tunnel) established based on this information. But when the endpoint of 
>> these overlay service is unreachable, the IGP still advertises the summary 
>> reachability. IGP should leak the actual information in such situation, 
>> doesn't insist that it can reach these failed address. 
>> And, as we have presented in the IETF meeting, the ABR Need Not advertise 
>> such information once there is prefix unreachable. The operator can 
>> configure the tracked/interested prefixes on the ABR.
> 
> 
> Again, you’re confusing reachability with liveness. A summary address does 
> NOT imply liveness.  If you have a prefix 1/8, that does not mean that 
> 1.1.1.1 is up and will accept a TCP connection or reply to a ping.

[WAJ] Reachability is not equal to liveness, but the dead is equal to 
unreachability.  What we want is to alert other peer that some prefixes within 
the summary is unreachable and they should do some thing, for example, fast 
reroute to other nodes etc.
It is unreasonable that the ABR knows such unreachability but still claims that 
it can reach all the prefixes the summary address covered.

> 
> 
>> We want scalability. That implies abstraction and that means that you can’t 
>> get a full link state database everywhere.
>> [WAJ] Yes. Current solution will not scarify the IGP scalability. As stated 
>> above, Not all link/prefix failures information will be delivered.
> 
> 
> You can’t guarantee that.  What we’ve seen is that when we provide features 
> in protocols, they are (ab)used in the worst ways imaginable. And then the 
> implementers are held responsible for the outcomes. In this case, it’s pretty 
> clear that there could easily be a mass failure resulting in the bulk 
> advertisement of a whole lot of negative information all at once.
> 
> One of the other things that we’ve learned is that step (and spike) responses 
> are problematic. Frequently they are more of an issue than scale because the 
> operator can’t see it coming. We end up with cascade failures (see the recent 
> Facebook failure).
> 
> Our job is to not design in mechanisms that lead to these bad outcomes.

[WAJ] I agree with you on this point. But how about your comments for such 
considerations in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-7.
 We have considered how to reaction to the mass outrage at the beginning.

> 
> 
>> There’s a reason that we’ve never gone down the path of hole punching 
>> before.  And yes, it’s been discussed before, decades ago.
>> [WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such 
>> solutions will be needed more and more. I think it is different from the 
>> situation existing decades ago.
> 
> 
> Nothing has changed except the encoding. We’ve been tunneling for decades. 
> We’ve been summarizing for decades. We’ve been rejecting hole punching for 
> decades. We’ve even been tunneling using source routing and other high 
> overhead mechanisms for decades. That ended up rejected too.

> If you really want the service, please change the architecture to a 
> registration mechanism as I outlined. This can and should be done outside of 
> the IGP.  You’re asking for a proxy liveness service and that’s entirely 
> doable.

[WAJ] The registration mechanism, like BFD? requires the configuration 
overhead, is difficult to deploy in the large scale network. That the reason we 
prefer to the automatic mechanism.

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Yes that was it.

On the part of scalability please observe that operators may
configure summaries of their choice. See even if you scope summaries to be
/24 only for IPv4 you still suppress lot's of /32s flooding. After all not
one mandates that one area must be covered by a single summary.

Nice you brought IPv6 to this discussion :) If you think that one bit for
IPv6 next hop in a summary makes the idea not usable what happens when you
loose a dense POP and you need to pulse all atomic /128s being part of the
POP's TORs or compute if not kubernetes PODs in the computes. Even with
rate limit IGP may get hot pulsing ...

Thx,
R.








On Fri, Nov 19, 2021 at 11:09 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> I believe you are referring to
> https://datatracker.ietf.org/doc/html/draft-swallow-isis-detailed-reach-01
> .
>
>
>
> This doesn’t scale well for shorter summaries – even for IPv4.
>
> And for IPv6 I think this is simply not usable.
>
>
>
> The draft details a potential deployment scheme which depends upon a very
> disciplined assignment of loopbacks by the network operator. You can
> comment on how reasonable an assumption that is better than I.
>
> I also think the scale numbers discussed in the draft have increased
> significantly over the years – which further stresses the use of this
> approach.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Friday, November 19, 2021 1:30 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Peter Psenak ; Tony Li <
> tony...@tony.li>; Gyan Mishra ; Christian Hopps <
> cho...@chopps.org>; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda <
> tonysi...@gmail.com>
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> Hi Les,
>
>
>
> Ok if you say that this is going to be rate limit for pulses rather then
> say drop it does sound promising.
>
>
>
> I think there are two parts to this. One is the definition of reachability
> vs liveness. For some of us it is the same. Clearly dead node can not be
> reachable :)
>
>
>
> The other part is however stability of the solution and deterministic
> nature of it. Pulses are something really new and I guess getting
> experience with it across zoo of vendors will be a significant effort.
>
>
>
> Have you consider a different approach ? I recall we spoke about it long
> time back. At least I recall talking with Stefano about it :) Just to
> advertise bit vector with each summary where each bit covers a summary
> member. 1 would indicate presence of /32 reachability in the area, 0 would
> indicate lack of such atomic  prefix in an area.
>
>
>
> No matter what happens you still advertise the same amount of information.
> It is predictable and while one can argue that it will make IGP more chatty
> clearly it will not be ON by default. And all machinery of pacing LSP/LSA
> generation would apply automagically.
>
>
>
> Further receiving node may act on this info in exactly the same way as it
> would act on pulse.
>
>
>
> Thx,
> R.
>
>
>
>
>
>
>
>
>
> On Fri, Nov 19, 2021 at 9:45 PM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> Robert –
>
>
>
> For me dealing with “mass failure” is important – but is easily doable.
>
> It is basic to IGP flooding that we limit the rate at which new versions
> of LSPs are generated.
>
> Analogous (but not identical) controls can be applied to pulse
> advertisements – and should be. We will address that in the next version of
> the draft.
>
>
>
> The substantive debate in my mind is that some people think it appropriate
> for IGP to advertise loss of reachability to destinations covered by an IGP
> originated summary advertisement and some folks do not.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Friday, November 19, 2021 12:25 PM
> *To:* Peter Psenak 
> *Cc:* Tony Li ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Gyan Mishra ; Christian Hopps
> ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda <
> tonysi...@gmail.com>
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> Peter,
>
>
>
> yes, but it's not specific to flat areas. Even in multi-area deployments
> the host routing is mandated by MPLS.
>
>
>
> In the early days of MPLS yes that was the case.
>
>
>
> But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)
>
>
>
> https://datatracker.ietf.org/doc

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Les Ginsberg (ginsberg)]

Robert –

I believe you are referring to 
https://datatracker.ietf.org/doc/html/draft-swallow-isis-detailed-reach-01 .

This doesn’t scale well for shorter summaries – even for IPv4.
And for IPv6 I think this is simply not usable.

The draft details a potential deployment scheme which depends upon a very 
disciplined assignment of loopbacks by the network operator. You can comment on 
how reasonable an assumption that is better than I.
I also think the scale numbers discussed in the draft have increased 
significantly over the years – which further stresses the use of this approach.

   Les


From: Robert Raszuk 
Sent: Friday, November 19, 2021 1:30 PM
To: Les Ginsberg (ginsberg) 
Cc: Peter Psenak ; Tony Li 
; Gyan Mishra ; Christian Hopps 
; Aijun Wang ; lsr 
; Acee Lindem (acee) ; Tony Przygienda 

Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Hi Les,

Ok if you say that this is going to be rate limit for pulses rather then say 
drop it does sound promising.

I think there are two parts to this. One is the definition of reachability vs 
liveness. For some of us it is the same. Clearly dead node can not be reachable 
:)

The other part is however stability of the solution and deterministic nature of 
it. Pulses are something really new and I guess getting experience with it 
across zoo of vendors will be a significant effort.

Have you consider a different approach ? I recall we spoke about it long time 
back. At least I recall talking with Stefano about it :) Just to advertise bit 
vector with each summary where each bit covers a summary member. 1 would 
indicate presence of /32 reachability in the area, 0 would indicate lack of 
such atomic  prefix in an area.

No matter what happens you still advertise the same amount of information. It 
is predictable and while one can argue that it will make IGP more chatty 
clearly it will not be ON by default. And all machinery of pacing LSP/LSA 
generation would apply automagically.

Further receiving node may act on this info in exactly the same way as it would 
act on pulse.

Thx,
R.




On Fri, Nov 19, 2021 at 9:45 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

For me dealing with “mass failure” is important – but is easily doable.
It is basic to IGP flooding that we limit the rate at which new versions of 
LSPs are generated.
Analogous (but not identical) controls can be applied to pulse advertisements – 
and should be. We will address that in the next version of the draft.

The substantive debate in my mind is that some people think it appropriate for 
IGP to advertise loss of reachability to destinations covered by an IGP 
originated summary advertisement and some folks do not.

Thanx.

   Les

From: Robert Raszuk mailto:rob...@raszuk.net>>
Sent: Friday, November 19, 2021 12:25 PM
To: Peter Psenak 
mailto:40cisco@dmarc.ietf.org>>
Cc: Tony Li mailto:tony...@tony.li>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>; Gyan Mishra 
mailto:hayabusa...@gmail.com>>; Christian Hopps 
mailto:cho...@chopps.org>>; Aijun Wang 
mailto:wangai...@tsinghua.org.cn>>; lsr 
mailto:lsr@ietf.org>>; Acee Lindem (acee) 
mailto:a...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Peter,

yes, but it's not specific to flat areas. Even in multi-area deployments
the host routing is mandated by MPLS.

In the early days of MPLS yes that was the case.

But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)

https://datatracker.ietf.org/doc/html/rfc5283

In these multi-area deployments
the host routes are sent everywhere, updates are triggered regardless of
the failure type. IGPs are effectively providing liveness service
between PEs in any MPLS network.

That is true too - as folks just do not know how to configure BGP properly (if 
BGP is used for services).

That leaves us the space what to do where there is no BGP carrying services. Or 
BGP implementation is broken and can not do the right thing.

For the pulse proposal - no one answered the question posted what is a 
definition of mass failure. But maybe that will be the secret sauce of a vendor 
:) ?

The fact that we are all in agreement that some network events will not work 
that well with the proposed solution seems to be a sufficient reason for me to 
consider different solution(s).

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Hi Les,

Ok if you say that this is going to be rate limit for pulses rather then
say drop it does sound promising.

I think there are two parts to this. One is the definition of reachability
vs liveness. For some of us it is the same. Clearly dead node can not be
reachable :)

The other part is however stability of the solution and deterministic
nature of it. Pulses are something really new and I guess getting
experience with it across zoo of vendors will be a significant effort.

Have you consider a different approach ? I recall we spoke about it long
time back. At least I recall talking with Stefano about it :) Just to
advertise bit vector with each summary where each bit covers a summary
member. 1 would indicate presence of /32 reachability in the area, 0 would
indicate lack of such atomic  prefix in an area.

No matter what happens you still advertise the same amount of information.
It is predictable and while one can argue that it will make IGP more chatty
clearly it will not be ON by default. And all machinery of pacing LSP/LSA
generation would apply automagically.

Further receiving node may act on this info in exactly the same way as it
would act on pulse.

Thx,
R.




On Fri, Nov 19, 2021 at 9:45 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> For me dealing with “mass failure” is important – but is easily doable.
>
> It is basic to IGP flooding that we limit the rate at which new versions
> of LSPs are generated.
>
> Analogous (but not identical) controls can be applied to pulse
> advertisements – and should be. We will address that in the next version of
> the draft.
>
>
>
> The substantive debate in my mind is that some people think it appropriate
> for IGP to advertise loss of reachability to destinations covered by an IGP
> originated summary advertisement and some folks do not.
>
>
>
> Thanx.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Friday, November 19, 2021 12:25 PM
> *To:* Peter Psenak 
> *Cc:* Tony Li ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; Gyan Mishra ; Christian Hopps
> ; Aijun Wang ; lsr <
> lsr@ietf.org>; Acee Lindem (acee) ; Tony Przygienda <
> tonysi...@gmail.com>
> *Subject:* Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112
> LSR Meeting Minutes
>
>
>
> Peter,
>
>
>
> yes, but it's not specific to flat areas. Even in multi-area deployments
> the host routing is mandated by MPLS.
>
>
>
> In the early days of MPLS yes that was the case.
>
>
>
> But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)
>
>
>
> https://datatracker.ietf.org/doc/html/rfc5283
>
>
>
> In these multi-area deployments
> the host routes are sent everywhere, updates are triggered regardless of
> the failure type. IGPs are effectively providing liveness service
> between PEs in any MPLS network.
>
>
>
> That is true too - as folks just do not know how to configure BGP properly
> (if BGP is used for services).
>
>
>
> That leaves us the space what to do where there is no BGP carrying
> services. Or BGP implementation is broken and can not do the right thing.
>
>
>
> For the pulse proposal - no one answered the question posted what is a
> definition of mass failure. But maybe that will be the secret sauce of a
> vendor :) ?
>
>
>
> The fact that we are all in agreement that some network events will not
> work that well with the proposed solution seems to be a sufficient reason
> for me to consider different solution(s).
>
>
>
> Thx,
>
> R.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Les Ginsberg (ginsberg)]

Robert –

For me dealing with “mass failure” is important – but is easily doable.
It is basic to IGP flooding that we limit the rate at which new versions of 
LSPs are generated.
Analogous (but not identical) controls can be applied to pulse advertisements – 
and should be. We will address that in the next version of the draft.

The substantive debate in my mind is that some people think it appropriate for 
IGP to advertise loss of reachability to destinations covered by an IGP 
originated summary advertisement and some folks do not.

Thanx.

   Les

From: Robert Raszuk 
Sent: Friday, November 19, 2021 12:25 PM
To: Peter Psenak 
Cc: Tony Li ; Les Ginsberg (ginsberg) ; 
Gyan Mishra ; Christian Hopps ; Aijun 
Wang ; lsr ; Acee Lindem (acee) 
; Tony Przygienda 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes

Peter,

yes, but it's not specific to flat areas. Even in multi-area deployments
the host routing is mandated by MPLS.

In the early days of MPLS yes that was the case.

But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)

https://datatracker.ietf.org/doc/html/rfc5283

In these multi-area deployments
the host routes are sent everywhere, updates are triggered regardless of
the failure type. IGPs are effectively providing liveness service
between PEs in any MPLS network.

That is true too - as folks just do not know how to configure BGP properly (if 
BGP is used for services).

That leaves us the space what to do where there is no BGP carrying services. Or 
BGP implementation is broken and can not do the right thing.

For the pulse proposal - no one answered the question posted what is a 
definition of mass failure. But maybe that will be the secret sauce of a vendor 
:) ?

The fact that we are all in agreement that some network events will not work 
that well with the proposed solution seems to be a sufficient reason for me to 
consider different solution(s).

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

Peter,


> yes, but it's not specific to flat areas. Even in multi-area deployments
> the host routing is mandated by MPLS.


In the early days of MPLS yes that was the case.

But that "mandate" was fixed by Ina, Bruno and Jean-Louis in 2008 :)

https://datatracker.ietf.org/doc/html/rfc5283

In these multi-area deployments
> the host routes are sent everywhere, updates are triggered regardless of
> the failure type. IGPs are effectively providing liveness service
> between PEs in any MPLS network.
>

That is true too - as folks just do not know how to configure BGP properly
(if BGP is used for services).

That leaves us the space what to do where there is no BGP carrying
services. Or BGP implementation is broken and can not do the right thing.

For the pulse proposal - no one answered the question posted what is a
definition of mass failure. But maybe that will be the secret sauce of a
vendor :) ?

The fact that we are all in agreement that some network events will not
work that well with the proposed solution seems to be a sufficient reason
for me to consider different solution(s).

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Hi Tony,

On 19/11/2021 17:55, Tony Li wrote:


Hi Peter,

yes, but it's not specific to flat areas. Even in multi-area 
deployments the host routing is mandated by MPLS. In these multi-area 
deployments the host routes are sent everywhere, updates are triggered 
regardless of the failure type. IGPs are effectively providing 
liveness service between PEs in any MPLS network.



Please re-read what you just wrote. The fact that someone decided to 
leak host routes is NOT something that the IGP was designed to do. 
Leaking negative updates is also wrong. Two wrongs don’t make a right.


host routes are just routes, like any other routes, for which IGP 
provide reachability. What's the length of the mask does not really 
matter. The fact that they are used for liveness by some application is 
also transparent to IGP.





The fact that it is effectively providing liveness is wholly irrelevant. 
It’s still the wrong thing to do.


well, then I guess we just agree to disagree.

thanks,
Peter




If IGPs can provide full liveness service between PEs today, why doing 
'optimized negative liveness service' would be architecturally wrong?



IGPs could also deliver web pages. Capability doesn’t imply that it’s 
architecturally appropriate. The IGP is supposed to provide reachability 
and path computation at local scale and with stability.  That’s it. One 
might well argue that we’re not doing that very well yet. Maybe we 
should stick to our knitting.


T



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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Peter,

> yes, but it's not specific to flat areas. Even in multi-area deployments the 
> host routing is mandated by MPLS. In these multi-area deployments the host 
> routes are sent everywhere, updates are triggered regardless of the failure 
> type. IGPs are effectively providing liveness service between PEs in any MPLS 
> network.


Please re-read what you just wrote. The fact that someone decided to leak host 
routes is NOT something that the IGP was designed to do. Leaking negative 
updates is also wrong. Two wrongs don’t make a right.

The fact that it is effectively providing liveness is wholly irrelevant. It’s 
still the wrong thing to do.


> If IGPs can provide full liveness service between PEs today, why doing 
> 'optimized negative liveness service' would be architecturally wrong?


IGPs could also deliver web pages. Capability doesn’t imply that it’s 
architecturally appropriate. The IGP is supposed to provide reachability and 
path computation at local scale and with stability.  That’s it. One might well 
argue that we’re not doing that very well yet. Maybe we should stick to our 
knitting.

T

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Hi Tony,

On 19/11/2021 17:02, Tony Li wrote:


Hi Peter,

[WAJ] The problem is arose from the summary action of IGP, why let 
other protocols solve it?
There is no ‘problem’ with the IGP. You seem to want liveness from 
the IGP. That’s not a property that it was meant to provide.


today IGPs provide reachability for the host route of remote PEs. Both 
up and down events are propagated everywhere. If such host route 
becomes unreachable, it is being used by BGP PIC to trigger the reroute.


When summarization is in place, to help IGP to scale, the remote PEs' 
reachability is announced in a form of a summary and host routes are 
suppressed. Providing down notification for the host prefix covered by 
the summary is similar in nature to what happens without the 
summarization. And if that down notification can be done in smart way, 
we are still better off compared to what we do today without a 
summarization.



And if it was done in a smart way, you could do so without ANY impact to 
scalability. I outlined the mechanism for you already.



You can call it liveness or something else, but IGPs are already doing 
so without the summarization. Arguing that it's not a property that 
IGPs were meant to provide is misleading.



This is incorrect.  Liveness is a side-effect in a flat area. It is NOT 
something that the routing layer provides. Consider the case of a host 
that is not participating in the IGP.  You have reachability information 
for it and path computation, as the IGP is designed to provide, but you 
do not have liveness.


yes, but it's not specific to flat areas. Even in multi-area deployments 
the host routing is mandated by MPLS. In these multi-area deployments 
the host routes are sent everywhere, updates are triggered regardless of 
the failure type. IGPs are effectively providing liveness service 
between PEs in any MPLS network.




If you are not willing to have an architectural discussion, then there’s 
not much of a point in having a working group.


don't take me wrong, I'm not trying to avoid the architectural 
discussion, quite the opposite.


If IGPs can provide full liveness service between PEs today, why doing 
'optimized negative liveness service' would be architecturally wrong?


thanks,
Peter



If you’re going to call every argument misleading, there’s also not much 
point in a working group. Les asked me for a clear explanation. I’ve 
done my best to provide that and apparently, I haven’t earned enough 
respect for it to be seriously considered. Ok, so be it. I was not 
looking for the Argument Clinic 
(https://www.dailymotion.com/video/x2hwqn9). Let’s agree to disagree.


Tony



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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Peter,

>>> [WAJ] The problem is arose from the summary action of IGP, why let other 
>>> protocols solve it?
>> There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. 
>> That’s not a property that it was meant to provide.
> 
> today IGPs provide reachability for the host route of remote PEs. Both up and 
> down events are propagated everywhere. If such host route becomes 
> unreachable, it is being used by BGP PIC to trigger the reroute.
> 
> When summarization is in place, to help IGP to scale, the remote PEs' 
> reachability is announced in a form of a summary and host routes are 
> suppressed. Providing down notification for the host prefix covered by the 
> summary is similar in nature to what happens without the summarization. And 
> if that down notification can be done in smart way, we are still better off 
> compared to what we do today without a summarization.


And if it was done in a smart way, you could do so without ANY impact to 
scalability. I outlined the mechanism for you already.


> You can call it liveness or something else, but IGPs are already doing so 
> without the summarization. Arguing that it's not a property that IGPs were 
> meant to provide is misleading.


This is incorrect.  Liveness is a side-effect in a flat area. It is NOT 
something that the routing layer provides. Consider the case of a host that is 
not participating in the IGP.  You have reachability information for it and 
path computation, as the IGP is designed to provide, but you do not have 
liveness.

If you are not willing to have an architectural discussion, then there’s not 
much of a point in having a working group.

If you’re going to call every argument misleading, there’s also not much point 
in a working group. Les asked me for a clear explanation. I’ve done my best to 
provide that and apparently, I haven’t earned enough respect for it to be 
seriously considered. Ok, so be it. I was not looking for the Argument Clinic 
(https://www.dailymotion.com/video/x2hwqn9 
). Let’s agree to disagree.

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Tony Li]

Hi Aijun,

> There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. 
> That’s not a property that it was meant to provide.  
> [WAJ] The IGP advertises the summary reachability. The overlay service(BGP or 
> tunnel) established based on this information. But when the endpoint of these 
> overlay service is unreachable, the IGP still advertises the summary 
> reachability. IGP should leak the actual information in such situation, 
> doesn't insist that it can reach these failed address. 
> And, as we have presented in the IETF meeting, the ABR Need Not advertise 
> such information once there is prefix unreachable. The operator can configure 
> the tracked/interested prefixes on the ABR.


Again, you’re confusing reachability with liveness. A summary address does NOT 
imply liveness.  If you have a prefix 1/8, that does not mean that 1.1.1.1 is 
up and will accept a TCP connection or reply to a ping.


> We want scalability. That implies abstraction and that means that you can’t 
> get a full link state database everywhere.
> [WAJ] Yes. Current solution will not scarify the IGP scalability. As stated 
> above, Not all link/prefix failures information will be delivered.


You can’t guarantee that.  What we’ve seen is that when we provide features in 
protocols, they are (ab)used in the worst ways imaginable. And then the 
implementers are held responsible for the outcomes. In this case, it’s pretty 
clear that there could easily be a mass failure resulting in the bulk 
advertisement of a whole lot of negative information all at once.

One of the other things that we’ve learned is that step (and spike) responses 
are problematic. Frequently they are more of an issue than scale because the 
operator can’t see it coming. We end up with cascade failures (see the recent 
Facebook failure).

Our job is to not design in mechanisms that lead to these bad outcomes.


> There’s a reason that we’ve never gone down the path of hole punching before. 
>  And yes, it’s been discussed before, decades ago.
> [WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such 
> solutions will be needed more and more. I think it is different from the 
> situation existing decades ago.


Nothing has changed except the encoding. We’ve been tunneling for decades. 
We’ve been summarizing for decades. We’ve been rejecting hole punching for 
decades. We’ve even been tunneling using source routing and other high overhead 
mechanisms for decades. That ended up rejected too.

If you really want the service, please change the architecture to a 
registration mechanism as I outlined. This can and should be done outside of 
the IGP.  You’re asking for a proxy liveness service and that’s entirely doable.

Tony

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

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Robert Raszuk]

> I don’t think their is an easy way to solve this in BGP.

Can you briefly elaborate why ? What is difficult using BGP native
recursion ?

Thx,
R.


On Fri, Nov 19, 2021 at 1:14 AM Gyan Mishra  wrote:

>
> Hi Tony
>
> The issue exists related to domain wide flooding to support seamless MPLS
> E2E LSP which you end up with all host routes from all areas flooded domain
> wide from Core and Agg layers.  So a solution to this domain wide flooding
> is area summarization,  however in order to make summarization viable for
> convergence we need a method to track the component prefixes when a failure
> occurs.
>
> So we have the two IGP based solutions but as this is an IGP issue, the
> issue needs to be solved by the IGP.  I don’t think their is an easy way to
> solve this in BGP.
>
> Kind Regards
> Gyan
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Peter Psenak]

Tony,

On 19/11/2021 04:16, Aijun Wang wrote:

Hi, Tony:


-Original Message-
From: tony1ath...@gmail.com  On Behalf Of Tony Li
Sent: Friday, November 19, 2021 9:08 AM
To: Aijun Wang 
Cc: Tony Przygienda ; Les Ginsberg (ginsberg) ; Gyan 
Mishra ; lsr@ietf.org; Christian Hopps ; Acee Lindem 
(acee) 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


Hi Aijun,

At the risk of Tony confusion…
[WAJ] Will not confuse due to the different speaking and wording style.



Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the 
confusion here is that a presence of a /32 route is used as SSAP liveliness 
AFAIS and that's simply not what IGPs are here for if you consider their main 
job to be fastest possible convergence in network _reachability_ only and not 
signalling of service failures.


[WAJ] The problem is arose from the summary action of IGP, why let other 
protocols solve it?



There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. 
That’s not a property that it was meant to provide.


today IGPs provide reachability for the host route of remote PEs. Both 
up and down events are propagated everywhere. If such host route becomes 
unreachable, it is being used by BGP PIC to trigger the reroute.


When summarization is in place, to help IGP to scale, the remote PEs' 
reachability is announced in a form of a summary and host routes are 
suppressed. Providing down notification for the host prefix covered by 
the summary is similar in nature to what happens without the 
summarization. And if that down notification can be done in smart way, 
we are still better off compared to what we do today without a 
summarization.


You can call it liveness or something else, but IGPs are already doing 
so without the summarization. Arguing that it's not a property that IGPs 
were meant to provide is misleading.


thanks,
Peter





[WAJ] The IGP advertises the summary reachability. The overlay service(BGP or 
tunnel) established based on this information. But when the endpoint of these 
overlay service is unreachable, the IGP still advertises the summary 
reachability. IGP should leak the actual information in such situation, doesn't 
insist that it can reach these failed address.
And, as we have presented in the IETF meeting, the ABR Need Not advertise such 
information once there is prefix unreachable. The operator can configure the 
tracked/interested prefixes on the ABR.

We want scalability. That implies abstraction and that means that you can’t get 
a full link state database everywhere.
[WAJ] Yes. Current solution will not scarify the IGP scalability. As stated 
above, Not all link/prefix failures information will be delivered.

If you’re willing to forgo scalability, then do so.  Don’t use areas. Just have 
a flat routing domain.

Hole punching is going to put you in exactly the same place, sooner or later.  
You’re sacrificing scalability and adding another mechanism to do so.  Why 
bother?



Alternately resolving BGP over BGP as Robert suggests (if I read that correctly) and use RR to 
scale out the SSAP nhop availability is possible I think architecturally without garbage-canning 
IGPs as "network-wide fast broadcast mechanism" ... I doubt it will do "couple 
millisecs" convergence ;-) but can be simpler hardware wise than trying to scale up BFD to 
large number of very fast sessions.



[WAJ] The operator doesn’t also want the network is filled with various queer 
designs or solutions.



Then why are you proposing one? [BTW, I realize that you intended no offense, 
that’s probably NOT the best choice of words.]

There’s a reason that we’ve never gone down the path of hole punching before.  
And yes, it’s been discussed before, decades ago.
[WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such 
solutions will be needed more and more. I think it is different from the 
situation existing decades ago.

Tony

___
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] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Aijun Wang]

Hi, Tony:


-Original Message-
From: tony1ath...@gmail.com  On Behalf Of Tony Li
Sent: Friday, November 19, 2021 9:08 AM
To: Aijun Wang 
Cc: Tony Przygienda ; Les Ginsberg (ginsberg) 
; Gyan Mishra ; lsr@ietf.org; 
Christian Hopps ; Acee Lindem (acee) 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


Hi Aijun,

At the risk of Tony confusion…
[WAJ] Will not confuse due to the different speaking and wording style. 


>> Agreeing with T. Li here (i.e. BFD next-hops) and let me add that AFAIS the 
>> confusion here is that a presence of a /32 route is used as SSAP liveliness 
>> AFAIS and that's simply not what IGPs are here for if you consider their 
>> main job to be fastest possible convergence in network _reachability_ only 
>> and not signalling of service failures.
> 
> [WAJ] The problem is arose from the summary action of IGP, why let other 
> protocols solve it? 


There is no ‘problem’ with the IGP. You seem to want liveness from the IGP. 
That’s not a property that it was meant to provide.  
[WAJ] The IGP advertises the summary reachability. The overlay service(BGP or 
tunnel) established based on this information. But when the endpoint of these 
overlay service is unreachable, the IGP still advertises the summary 
reachability. IGP should leak the actual information in such situation, doesn't 
insist that it can reach these failed address. 
And, as we have presented in the IETF meeting, the ABR Need Not advertise such 
information once there is prefix unreachable. The operator can configure the 
tracked/interested prefixes on the ABR.

We want scalability. That implies abstraction and that means that you can’t get 
a full link state database everywhere.
[WAJ] Yes. Current solution will not scarify the IGP scalability. As stated 
above, Not all link/prefix failures information will be delivered.

If you’re willing to forgo scalability, then do so.  Don’t use areas. Just have 
a flat routing domain.

Hole punching is going to put you in exactly the same place, sooner or later.  
You’re sacrificing scalability and adding another mechanism to do so.  Why 
bother?


>> Alternately resolving BGP over BGP as Robert suggests (if I read that 
>> correctly) and use RR to scale out the SSAP nhop availability is possible I 
>> think architecturally without garbage-canning IGPs as "network-wide fast 
>> broadcast mechanism" ... I doubt it will do "couple millisecs" convergence 
>> ;-) but can be simpler hardware wise than trying to scale up BFD to large 
>> number of very fast sessions. 
> 
> 
> [WAJ] The operator doesn’t also want the network is filled with various queer 
> designs or solutions.


Then why are you proposing one? [BTW, I realize that you intended no offense, 
that’s probably NOT the best choice of words.]

There’s a reason that we’ve never gone down the path of hole punching before.  
And yes, it’s been discussed before, decades ago.
[WAJ] With the Tunnel Technologies such as SRv6 are accepted/deployed, such 
solutions will be needed more and more. I think it is different from the 
situation existing decades ago.

Tony

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