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.)
  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>> 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 

[Lsr] Rtgdir last call review of draft-ietf-lsr-isis-flood-reflection-05

[Michael Richardson via Datatracker]

Reviewer: Michael Richardson
Review result: Has Issues

Subject: RtgDir Last Call review: draft-ietf-lsr-isis-flood-reflection-05

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing
ADs. For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through discussion
or by updating the draft.

Document: draft-ietf-lsr-isis-flood-reflection-05
Reviewer: Michael Richardson
Review Date: 2021-11-25
IETF LC End Date: 2021-12-17
Intended Status: Standards Track

Summary:

This document is basically ready for publication but has nits that should be
considered prior to publication.

(As a person with little ISIS knowledge, but BGP experience, I was able to pick
things up. Good Job!)

Comments:

The use of _L1_/_L2_ is an ISIS terminology, which goes back to RFC1195, I
found. Any reader who is not intimate with ISIS won't know this terminology,
which in RFC1195 is "Level 1" and "Level 2", so please add this to the
glossary, and/or reference 1195.

Major Issues:

No major issues found.

Minor Issues:

I prefer to have the Introduction tell me something about the problem space
before the Glossary floods (pun intended) me with terms, but perhaps document
structure is different in LSR.

Please label the diagram better:
  Figure 1: _Example Topology_
  -> _Example Topology of attempt to extend L2 with L1_

or something like that.  I think it's the thing that doesn't work.
Have you tried running goat on this diagram?  Would look nice in SVG.

Figure 3 does nothave an R22, but it is mentioned in the paragraph on page 6.

Section 4: there are only three bytes in the first line. This is surprising.
Same in section 5. Maybe something about ISIS stuff I don't know.
   I would have put sections 4,5,6,7 into a Section "Protocol Extensions", but
   that's just me.

Section 9: what happens if the MUSTs on Cluster ID are violated?
What is the defensive situation?  Does this force flag days?

On the whole, I wonder if this draft hasn't really created an "L3" area, and
calling it that might lead to a clearer situation.

I'm not sure that I agree with _Security Considerations_.
If there are tunnels everywhere in this core, doesn't this present new
opportunities to impersonate devices?

Nits:

I found no obvious nits



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

Re: [Lsr] BGP vs PUA/PULSE

[Robert Raszuk]

Hi Peter,

First BGP MP_UNREACH propagation via RRs is really fast.

Please observe that if your BGP implementation is smart you do not need to
withdraw prefix by prefix in any application which uses VRFs. You can
withdraw RD/64s only when you detect that the PE went down. Furthermore as
you know with auto RD allocation RD format is usually BGP_ROUTER-ID: so
to withdraw all service routes once the PE went down you could just send
RD/32 single NLRI !

There is a lot of options.

In respect to option 2 - you do not need to speed up service BGP withdraws
at all. You are using indirection and you are withdrawing recursive next
hop irrespective on how many service routes are present including Internet.
So it is not "same as above" at all. I am really not sure what is so
difficult in this scenario that folks just do not get it.

Thx a lot,
Robert


On Thu, Nov 25, 2021 at 6:45 PM Peter Psenak  wrote:

> Robert,
>
> On 25/11/2021 18:25, Robert Raszuk wrote:
> > Dear LSR WG,
> >
> > I wanted to visualize the scenario we are so deeply discussing here.
> > Specifically BGP vs IGP flooding as well as applicability of RFC8679.
> >
> > Below are three options comparing what it takes to distribute bad news
> > in BGP vs IGP. Keep in mind that only PE2 on the illustration is
> > interested in this bad news.
> >
> > All in respect to L3VPN Option C as example of the service.
> >
> > *Option 1* - Classic/ Today's design. If you simply enable BFD on IBGP
> > between PE1 and RR I bet we would not even be discussing anything as
> > things will just work well as is today.
>
> I don't understand how BFD between PE1 and RR is going to address the
> problem in hand. If PE1 goes down, RR will have to withdraw all
> individual BGP prefixes advertised by PE1. Could be global internet
> routes, internet in VRF is not uncommon either. With BGP per prefix
> withdrawal the convergence is slow by definition. We want BGP PIC like
> behavior and that is not what you have described above.
>
> >
> > image.png
> >
> > *Option 2 -* BGP recursion as discussed earlier to speed up NH down
> > propagation vs service route withdraw.
>
> same as above.
>
>
> >
> > image.png
> >
> > Again very easy to accomplish today modulo your BGP implementation. RR1
> > to PE1 can be two BGP session - one with BFD one without to easily
> > separate the sequence of BGP events.
> >
> > *Option 3* - BGP-LS from ABRs
>
> BGP can carry pulses, but as I mentioned several times there are SP
> networks that do not run MPLS and use other tunneling mechanisms. They
> would not appreciate BGP only solution.
>
> Having a solution in both IGP and BGP and let user decide which one he
> wants to use seems a better approach to me.
>
> thanks,
> Peter
>
> > image.png
> >
> > BGP-LS essentially is carrying those PUA/PULSES to those who need it.
> >
> > In all cases RFC8679 can still protect against PE1 failure at local PLR
> > directing traffic to backup PE1' (not on the picture but we assume it is
> > there otherwise it is all moot).
> >
> > And in fact local protection is the only one which can assure minimum
> > service disruption time.
> >
> > For PUA/PULSE to get triggered by ABR all PE1 IGP neighbours must report
> > PE1 to be out - hence we are already limited to the local area detection
> > of PE1 down and local flooding.
> >
> > Now imagine someone will not like to use BFD+BGP. Well that means that
> > IBGP will time out in 180 sec. That also means that whatever PUA/PULSE
> > is there it MUST "last" min 200 sec on the remote PEs.
> >
> > (Also attaching pdf with the above illustration in case jpg-s are poor).
> >
> > Many thx,
> > Robert
> >
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] BGP vs PUA/PULSE

[Peter Psenak]

Robert,

On 25/11/2021 18:25, Robert Raszuk wrote:

Dear LSR WG,

I wanted to visualize the scenario we are so deeply discussing here. 
Specifically BGP vs IGP flooding as well as applicability of RFC8679.


Below are three options comparing what it takes to distribute bad news 
in BGP vs IGP. Keep in mind that only PE2 on the illustration is 
interested in this bad news.


All in respect to L3VPN Option C as example of the service.

*Option 1* - Classic/ Today's design. If you simply enable BFD on IBGP 
between PE1 and RR I bet we would not even be discussing anything as 
things will just work well as is today.


I don't understand how BFD between PE1 and RR is going to address the 
problem in hand. If PE1 goes down, RR will have to withdraw all 
individual BGP prefixes advertised by PE1. Could be global internet 
routes, internet in VRF is not uncommon either. With BGP per prefix 
withdrawal the convergence is slow by definition. We want BGP PIC like 
behavior and that is not what you have described above.




image.png

*Option 2 -* BGP recursion as discussed earlier to speed up NH down 
propagation vs service route withdraw.


same as above.




image.png

Again very easy to accomplish today modulo your BGP implementation. RR1 
to PE1 can be two BGP session - one with BFD one without to easily 
separate the sequence of BGP events.


*Option 3* - BGP-LS from ABRs


BGP can carry pulses, but as I mentioned several times there are SP 
networks that do not run MPLS and use other tunneling mechanisms. They 
would not appreciate BGP only solution.


Having a solution in both IGP and BGP and let user decide which one he 
wants to use seems a better approach to me.


thanks,
Peter


image.png

BGP-LS essentially is carrying those PUA/PULSES to those who need it.

In all cases RFC8679 can still protect against PE1 failure at local PLR 
directing traffic to backup PE1' (not on the picture but we assume it is 
there otherwise it is all moot).


And in fact local protection is the only one which can assure minimum 
service disruption time.


For PUA/PULSE to get triggered by ABR all PE1 IGP neighbours must report 
PE1 to be out - hence we are already limited to the local area detection 
of PE1 down and local flooding.


Now imagine someone will not like to use BFD+BGP. Well that means that 
IBGP will time out in 180 sec. That also means that whatever PUA/PULSE 
is there it MUST "last" min 200 sec on the remote PEs.


(Also attaching pdf with the above illustration in case jpg-s are poor).

Many thx,
Robert



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

Re: [Lsr] WG Adoption Call for "IS-IS Fast Flooding" - draft-decraeneginsberg-lsr-isis-fast-flooding-00

[Gyan Mishra]

I support WG adoption.

Thanks

Gyan

On Mon, Nov 22, 2021 at 9:12 AM Acee Lindem (acee)  wrote:

> We indicated the intent to adopt of
> draft-decraeneginsberg-lsr-isis-fast-flooding-00 as an LSR WG document at
> the IETF 112 LSR WG meeting.
>
> We are now confirming WG consensus on this action. Please indicate your
> support or objection on this list by 12:00 AM UTC on December 7th, 2021.
>
>
>
> Another question that came to light is whether the document should be
> standards track or experimental. If you have an opinion on this matter,
> please chime in along with your arguments for one track or the other. We
> probably won’t make a final decision on this now but let’s get the
> discussion started.
>
>
>
> Here is a link for your convenience:
>
>
>
>
> https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/
>
>
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*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]

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
>>> 
>>> .)  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 

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
>> 
>> .)  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: 

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
> 
> .)  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 

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.)
  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>> 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 

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] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

[zhang.zheng]

Support the publishment of this draft. 
Thanks,
Sandy



--原始邮件--
发件人：AceeLindem(acee)
收件人：lsr@ietf.org;
日 期 ：2021年11月23日 03:48
主 题 ：[Lsr] WG Last Call fo "IS-IS Flood Reflection" 
-draft-ietf-lsr-isis-flood-reflection-05
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please 
post your support or objection to this list by 12:00 AM UTC on Dec 14th , 2021. 
Also please post your comments on the draft. I’m allowing as extra week as I 
like to get some additional reviews – although my comments have been addressed.
Thanks,
Acee

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