Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Tony Przygienda]

Gyan, all good except you find that once you have MFI thought through and
really working (implementations do wonder to understanding) with all kind
of frills like Les pointed out you'll build MT by another name again most
likely AFAIS.

If you want to flood everywhere and have some attribution on links you try
to put into computation you end up in flex algo corner pretty much (which
has been done pretty much already in a mild but extremely practical form in
RFC2676 but wasn't the hot cookie of the day then)

The sharing of FECs Tarek proposes seems like a clever optimization and
something bitsy new if that gives you the "slice" definition @ maximum
scale you look for.

-- tony

On Tue, Mar 9, 2021 at 3:47 PM Gyan Mishra  wrote:

> Tony,
>
> In-line
>
> On Tue, Mar 9, 2021 at 5:55 AM Tony Przygienda 
> wrote:
>
>> and replying to myself, as was mentioned yesterday in LSR already, the
>> key questions is HOW MANY control plane slices and then FIB slices do you
>> really need in the technology to be built.  And how much of that needs to
>> be really in the core? Both will have large implication on solutions, you
>> cannot run 2000 IGP processes in a box but you could run 2K topologies on
>> IGP (cough, cough). IGP control plane will be limited by how many
>> computations you can crunch (unless you take that off box, bit risky but
>> thnkable) and then can you OAM & operate such a solution, especially if
>> topologies disjoin. FEC sharing tricks are proposed here and are worth
>> thinking through if they allow to squeeze #context in control plane into
>> less context in FIB but compression is a devil (think SR stack compression
>> today) since it often leads operationally to surprising effects. In
>> forwarding path all those things are trickier/more costly, on the edge we
>> run thousands of VPNs/EVIs in MP-BGP so it's thinkable, in the core, ehem,
>> well, you start to reinvent MPLS since about only thing that scales on
>> every core box is switching (if you want precise per box
>> accounting/control). You can 'fudge' things by the ancient loose source
>> routing, ehem, sorry, it's called SR now ;-) but this has a formidable set
>> of operational challenges since the ole Token Ring doing it.
>>
>> exec summary: figure out how many "slices" you need in control & data
>> plane & how tight they need to be in terms of SLAs and then swallow the
>> trade-offs. that may not be a single data point and multiple solutions may
>> be necessary.
>>
>> Gyan> Agreed.  For draft "draft-xie-lsr-isis-sr-vtn-mt-03" VTN
> underpinning it makes sense with this draft to pick the design to use MT
> separate forwarding plane RIB/FIB topology resource isolation over MI -
> Separate control plane & forwarding plane resource isolation.  As you
> stated with TEAS NS there could be 1000s of slices and so you really need
> to pick your poison carefully as far as degree of resource isolation to
> provide optimized overall scalability. This draft is another way to skin
> the cat for VTN network slice as far as isolation and taking it another
> step further to provide lesser isolation then MT with isolating with MFI
> flood instance to provide greater scalability with slices.
>
>> --- tony
>>
>> On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda 
>> wrote:
>>
>>> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
>>> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
>>> done for about forever
>>>
>>> problem with lots of those proposals and assertions here is that
>>> powerpoint and rfc text always compiles no matter what you put into it,
>>> silicon and real implementations force to face the world not as you imagine
>>> it but as you can actually make it work in practical terms. Akin to talking
>>> about pottery (*there is a value to it in itself) and making a real pot
>>> with clay. Making a real pot first gives you a much better chance to
>>> actually talk about pottery meaningfully albeit it does not teach you
>>> aesthetics of pottery or a complete new way to make pots possibly.
>>>
>>> 2c
>>>
>>> -- tony
>>>
>>> On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra 
>>> wrote:
>>>
 Hi Peter

 On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:

> Gyan,
>
> On 05/03/2021 16:46, Gyan Mishra wrote:
> > Yali
> >
> > I agree with a Peter.
> >
> > As for resource isolation and provisioning of a VTN I think you
> really
> > need separate LSDB instances provided by MT or MI as better suited
> for
> > network slicing.
>
> MT does not provide LSDB separation, only MI does.
>
> thanks,
> Peter


I thought that each MT topology was a separate RIB meaning separate
 LSDB.  The RFC is confusing.😄

 https://tools.ietf.org/html/rfc5120

 6 .  MT SPF Computation

Each MT MUST run its own instance of the decision process.  The
pseudo-no

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Robert Raszuk]

Hi Peter,


> > Example 1:
> >
> > If session to PE1 goes down, withdraw all RDs received from such PE.
>
> still dependent on RDs and BGP specific.


To me this does sound like a feature ... to you I think it was rather
pejorative.


> We want app independent way of
> signaling the reachability loss. At the end that's what IGPs do without
> a presence of summarization.
>

Here you go. I suppose you just drafted the first use case for OSPF
Transport Instance.

I suppose you just run new ISIS or OSPF Instance and flood info about PE
down events to all other instance nodes (hopefully just PEs and no Ps as
such plane would be OTT one).  Still you will be flooding this to 100s of
PEs which may never need this information at all which I think is the main
issue here. Such bad news IMHO should be distributed on a pub/sub basis
only. First you subscribe then you get updates ... not get everything then
keep junk till it get's removed or expires.

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

Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

[Ketan Talaulikar (ketant)]

Hi Alvaro,

Please check inline below with [KT2]

I will wait for your responses on a few of the points before posting the draft 
update.

-Original Message-
From: Alvaro Retana  
Sent: 09 March 2021 02:57
To: Ketan Talaulikar (ketant) ; 
draft-ietf-lsr-ospf-prefix-origina...@ietf.org
Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org; 
Christian Hopps 
Subject: RE: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

On March 8, 2021 at 12:35:52 PM, Ketan Talaulikar (ketant) wrote:


Ketan:

Hi!

I have a couple of comments below, which I think can be handled with other 
last-call comments.  I'm starting the IETF LC.

Thanks!!

Alvaro.




...
> 127 2. Protocol Extensions
>
> 129 This document defines the Prefix Source Router-ID and the Prefix
> 130 Originator Sub-TLVs for inclusion of the Router ID and a reachable
> 131 address information for the router originating the prefix as a 
> prefix
> 132 attribute.
>
> [major] I understand that the 2 sub-TLVs are optional and complement 
> each other. Is there an expectation for both to be present? Should 
> (SHOULD/MUST) both be present? What if they're not?
>
> [KT] There is no dependency between the two and hence either one or 
> both of them may be advertised.

Why do we need both then?  Can the users of this information figure stuff out 
with only one?  After all you added the Prefix Originator Sub-TLV for a reason. 
;-)
[KT2] One sub-TLV signals the OSPF Router-ID of the originating node in the 
OSPF domain, the other sub-TLV signals a reachable address of the originating 
node (may be within or even outside the OSPF domain for external prefixes). The 
draft explains this in the introduction and the procedures. I think perhaps it 
helps if we rename as

s/Prefix Source Router-ID Sub-TLV/Prefix Source OSPF Router-ID Sub-TLV
s/Prefix Originator Sub-TLV/Prefix Source Router Address Sub-TLV

...
> 134 2.1. Prefix Source Router-ID Sub-TLV ...
> 161 o OSPF Router ID : the OSPF Router ID of the OSPF router that
> 162 originated the prefix advertisement in the OSPF domain.
>
> [major] Should there be a relationship between the router ID and the 
> Advertising Router field in the LSA containing the prefix? What does 
> it mean if the router ID doesn't match?
>
> [KT] The value MUST match for intra-area. So we can clarify this part 
> and if it does not match then the sub-TLV can be ignored. For external (e.g.
> Type 5), we cannot determine because we don't know if it was not 
> translated from Type 7 to Type 5 by an NSSA ABR. Same way we cannot 
> figure this out reliably for inter-area prefix advertisements. Not 
> sure if there is anything we can say other than intra-area.

Right.

OLD>
   For intra-area prefix advertisements, the Prefix Source Router-ID
   Sub-TLV MUST be considered invalid and ignored if it is not the same
   as Advertising Router ID for the prefix advertisement.

NEW>
   For intra-area prefix advertisements, the Prefix Source Router-ID Sub-TLV
   MUST be considered invalid and ignored if the OSPF Router ID field is not
   the same as the Advertising Router field in the containing LSA.
[KT2] Ack


For inter-area, maybe it's worth mentioning the fact that it cannot be 
verified, so a rogue ABR (see more on rogue below) can inject incorrect 
information.
[KT2] Ack. Will add - " Similar validation cannot be reliably performed for 
inter-area and external prefix advertisements." At the end of the above 
paragraph. 


> [major] Even though this document doesn't specify any 
> OSPF-in-the-network action based on the new information, it does say 
> that the information is useful for "topology analysis and traffic 
> engineering", which means that the values may have an impact on route 
> calculation (at a controller). I'm asking the questions about matching 
> values because (if they don't) then it would be relatively easy for a 
> rogue node to introduce non-congruent values which could have an effect on 
> the controller's decision.
>
> [KT] We need to remember that we are talking about a prefix 
> advertisement - a rogue would need to make a prefix advertisement 
> first (which is considered for OSPF routing) and only then comes the 
> part when this sub-TLV value is mismatched. Isn't the first part a bigger 
> issue?

Yes.  But a rogue node can already do that!!  This draft adds the second part.

Note that by rogue I mean a router that has been subverted; e.g.
someone got the password and now has the ability to inject anything into the 
network.  In this case authentication does not help because the router has the 
proper keys.

Note that I'm not asking you to fix the problem -- just to mention the new risk.
[KT2] I am assuming you are asking for this to be mentioned in the Securities 
Considerations section. I am not sure what would be a helpful text here. Does 
the following work?


A rogue node that can inject prefix advertisements may use the new extensions 
introduced in this document to indicate incorrect prefix source inf

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[lic...@chinatelecom.cn]

Hi, all

 This draft describes the IGP control plane mechanism with necessary extensions 
to build SR based VTNs. It is useful. I support the adoption of this document.



Best regards，
Cong Li
 
发件人： Acee Lindem (acee)
发送时间： 2021-03-03 07:27
收件人： lsr@ietf.org
主题： [Lsr]WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment 
Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03
This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption. 
 
This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020. 
 
Thanks,
Acee
 
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Gyan Mishra]

Tony,

In-line

On Tue, Mar 9, 2021 at 5:55 AM Tony Przygienda  wrote:

> and replying to myself, as was mentioned yesterday in LSR already, the key
> questions is HOW MANY control plane slices and then FIB slices do you
> really need in the technology to be built.  And how much of that needs to
> be really in the core? Both will have large implication on solutions, you
> cannot run 2000 IGP processes in a box but you could run 2K topologies on
> IGP (cough, cough). IGP control plane will be limited by how many
> computations you can crunch (unless you take that off box, bit risky but
> thnkable) and then can you OAM & operate such a solution, especially if
> topologies disjoin. FEC sharing tricks are proposed here and are worth
> thinking through if they allow to squeeze #context in control plane into
> less context in FIB but compression is a devil (think SR stack compression
> today) since it often leads operationally to surprising effects. In
> forwarding path all those things are trickier/more costly, on the edge we
> run thousands of VPNs/EVIs in MP-BGP so it's thinkable, in the core, ehem,
> well, you start to reinvent MPLS since about only thing that scales on
> every core box is switching (if you want precise per box
> accounting/control). You can 'fudge' things by the ancient loose source
> routing, ehem, sorry, it's called SR now ;-) but this has a formidable set
> of operational challenges since the ole Token Ring doing it.
>
> exec summary: figure out how many "slices" you need in control & data
> plane & how tight they need to be in terms of SLAs and then swallow the
> trade-offs. that may not be a single data point and multiple solutions may
> be necessary.
>
> Gyan> Agreed.  For draft "draft-xie-lsr-isis-sr-vtn-mt-03" VTN
underpinning it makes sense with this draft to pick the design to use MT
separate forwarding plane RIB/FIB topology resource isolation over MI -
Separate control plane & forwarding plane resource isolation.  As you
stated with TEAS NS there could be 1000s of slices and so you really need
to pick your poison carefully as far as degree of resource isolation to
provide optimized overall scalability. This draft is another way to skin
the cat for VTN network slice as far as isolation and taking it another
step further to provide lesser isolation then MT with isolating with MFI
flood instance to provide greater scalability with slices.

> --- tony
>
> On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda 
> wrote:
>
>> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
>> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
>> done for about forever
>>
>> problem with lots of those proposals and assertions here is that
>> powerpoint and rfc text always compiles no matter what you put into it,
>> silicon and real implementations force to face the world not as you imagine
>> it but as you can actually make it work in practical terms. Akin to talking
>> about pottery (*there is a value to it in itself) and making a real pot
>> with clay. Making a real pot first gives you a much better chance to
>> actually talk about pottery meaningfully albeit it does not teach you
>> aesthetics of pottery or a complete new way to make pots possibly.
>>
>> 2c
>>
>> -- tony
>>
>> On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra  wrote:
>>
>>> Hi Peter
>>>
>>> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:
>>>
 Gyan,

 On 05/03/2021 16:46, Gyan Mishra wrote:
 > Yali
 >
 > I agree with a Peter.
 >
 > As for resource isolation and provisioning of a VTN I think you
 really
 > need separate LSDB instances provided by MT or MI as better suited
 for
 > network slicing.

 MT does not provide LSDB separation, only MI does.

 thanks,
 Peter
>>>
>>>
>>>I thought that each MT topology was a separate RIB meaning separate
>>> LSDB.  The RFC is confusing.😄
>>>
>>> https://tools.ietf.org/html/rfc5120
>>>
>>> 6 .  MT SPF Computation
>>>
>>>Each MT MUST run its own instance of the decision process.  The
>>>pseudo-node LSPs are used by all topologies during computation.  Each
>>>non-default topology MAY have its attached bit and overload bit set
>>>in the MT TLV.  A reverse-connectivity check within SPF MUST follow
>>>the according MT to assure the bi-directional reachability within the
>>>same MT.
>>>
>>>The results of each computation SHOULD be stored in a separate
>>>Routing Information Base (RIB), in normal cases, otherwise
>>>overlapping addresses in different topologies could lead to
>>>undesirable routing behavior, such as forwarding loops.  The
>>>forwarding logic and configuration need to ensure the same MT is
>>>traversed from the source to the destination for packets.  The
>>>nexthops derived from the MT SPF MUST belong to the adjacencies
>>>
>>>
>>> conforming to the same MT for correct forwarding.  

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Gyan Mishra]

Thanks Tony for the clarification on MI versus MT.  Peter set me straight
as well on the difference. There are use cases for either one and in this
particular case for VTN underpinning it makes sense as the authors pointed
out that the forwarding plane resources is what needs to be constrained &
isolated which makes MT the proper choice over MI which is overkill as it
provides control & forwarding plane resource isolation with separate LSDB.

Kind Regards

Gyan

On Tue, Mar 9, 2021 at 5:48 AM Tony Przygienda  wrote:

> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
> done for about forever
>
> problem with lots of those proposals and assertions here is that
> powerpoint and rfc text always compiles no matter what you put into it,
> silicon and real implementations force to face the world not as you imagine
> it but as you can actually make it work in practical terms. Akin to talking
> about pottery (*there is a value to it in itself) and making a real pot
> with clay. Making a real pot first gives you a much better chance to
> actually talk about pottery meaningfully albeit it does not teach you
> aesthetics of pottery or a complete new way to make pots possibly.
>
> 2c
>
> -- tony
>
> On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra  wrote:
>
>> Hi Peter
>>
>> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:
>>
>>> Gyan,
>>>
>>> On 05/03/2021 16:46, Gyan Mishra wrote:
>>> > Yali
>>> >
>>> > I agree with a Peter.
>>> >
>>> > As for resource isolation and provisioning of a VTN I think you really
>>> > need separate LSDB instances provided by MT or MI as better suited for
>>> > network slicing.
>>>
>>> MT does not provide LSDB separation, only MI does.
>>>
>>> thanks,
>>> Peter
>>
>>
>>I thought that each MT topology was a separate RIB meaning separate
>> LSDB.  The RFC is confusing.😄
>>
>> https://tools.ietf.org/html/rfc5120
>>
>> 6 .  MT SPF Computation
>>
>>Each MT MUST run its own instance of the decision process.  The
>>pseudo-node LSPs are used by all topologies during computation.  Each
>>non-default topology MAY have its attached bit and overload bit set
>>in the MT TLV.  A reverse-connectivity check within SPF MUST follow
>>the according MT to assure the bi-directional reachability within the
>>same MT.
>>
>>The results of each computation SHOULD be stored in a separate
>>Routing Information Base (RIB), in normal cases, otherwise
>>overlapping addresses in different topologies could lead to
>>undesirable routing behavior, such as forwarding loops.  The
>>forwarding logic and configuration need to ensure the same MT is
>>traversed from the source to the destination for packets.  The
>>nexthops derived from the MT SPF MUST belong to the adjacencies
>>
>>
>> conforming to the same MT for correct forwarding.  It is recommended
>>for the administrators to ensure consistent configuration of all
>>routers in the domain to prevent undesirable forwarding behavior.
>>
>>No attempt is made in this document to allow one topology to
>>calculate routes using the routing information from another topology
>>inside SPF.  Even though it is possible to redistribute and leak
>>routes from another IS-IS topology or from external sources, the
>>exact mechanism is beyond the scope of this document.
>>
>>
>>
>>>
>>> >
>>> > To me it seems a common LSDB shared among network slices VTN underlay
>>> > could be problematic with network overlap issues.
>>> >
>>> > Kind Regards
>>> >
>>> > Gyan
>>> >
>>> > On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak >> > > wrote:
>>> >
>>> > Hi Yali,
>>> >
>>> > On 05/03/2021 15:31, wangyali wrote:
>>> >  > Hi Peter,
>>> >  >
>>> >  > Thanks for your question. Please see inline [yali3].
>>> >  >
>>> >  > -Original Message-
>>> >  > From: Peter Psenak [mailto:ppse...@cisco.com
>>> > ]
>>> >  > Sent: Thursday, March 4, 2021 11:20 PM
>>> >  > To: wangyali >> > >; Gyan Mishra <
>>> hayabusa...@gmail.com
>>> > >; Robert Raszuk >> > >
>>> >  > Cc: Huzhibo mailto:huzh...@huawei.com>>;
>>> > Aijun Wang >> > >; Tony Li >> > >; lsr mailto:lsr@ietf.org
>>> >>;
>>> > Tianran Zhou >> zhoutian...@huawei.com>>
>>> >  > Subject: Re: [Lsr] New Version Notification for
>>> > draft-wang-lsr-isis-mfi-00.txt
>>> >  >
>>> >  > Hi Yali,
>>> >  >
>>> >  > On 04/03/2021 14:45, wangyali wrote:
>>> >  >> Hi Peter,
>>> >  >>
>>> >  >> Please see inline [Yali2]. Thanks a lot.
>>> >  >>
>>> >  >> -Original Message-
>>> >  >> From: Peter Psenak [mailto:ppse...@cisco.com
>>>

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[peng.shaofu]

Hi Jie and all,






I'm sorry to have digressed in the adoption on this informational 
draft-xie-lsr-isis-sr-vtn-mt-03. However, I think these enhanced-vpn related 
documents are closely related, although they are divided into multiple 
documents. So discussing the main document (draft-dong-lsr-sr-for-enhanced-vpn) 
doesn't conflict with this one.





For VTN-ID, I don't believe it is interpreted by you as for scalability 
purpose, which is very interesting. 

Here are two things:

1) The slice-based ID is introduced into the control plane and the forwarding 
plane, and the SID per slice is assigned and advertised. This is done by 
draft-peng.

2) Optimize scalability issues. For example, the forwarding behavior of 
prefix-SID per slice can be inherited from flex-algo. That is clearly described 
by draft-bestbar.




Please don't confuse the above two things, that is, you can't say that one 
thing becomes another just because we try to optimize one aspect of it.


Once the slice-based ID is introduced, it can be used to distinguish which 
slice the service belongs to, and that is not related with whether different 
slice can or not share the same topology.






Regards,


PSF






原始邮件



发件人：Dongjie(Jimmy)
收件人：彭少富10053815;
抄送人：hayabusa...@gmail.com;rob...@raszuk.net;ts...@juniper.net;chongfeng@foxmail.com;ginsberg=40cisco@dmarc.ietf.org;lsr@ietf.org;a...@cisco.com;tonysi...@gmail.com;
日 期 ：2021年03月09日 19:32
主 题 ：Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03


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

 

Hi,


 


Since this discussion is not related to the adoption poll for 
draft-xie-lsr-isis-sr-vtn-mt, please start a separate mail thread if you want 
to discuss other documents.


 


A brief reply:


 


In the current version or any previous version of 
draft-peng-teas-network-slicing, there is no scalability considerations, nor 
any mechanism to improve the scalability. While the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn was introduced for the scalability purpose 
one year ago. Thus I think your statement is totally wrong.


 


Best regards,


Jie


 




From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of peng.sha...@zte.com.cn
 Sent: Tuesday, March 9, 2021 10:52 AM
 To: Dongjie (Jimmy) 
 Cc: hayabusa...@gmail.com; rob...@raszuk.net; ts...@juniper.net; 
chongfeng@foxmail.com; ginsberg=40cisco@dmarc.ietf.org; lsr@ietf.org; 
a...@cisco.com; tonysi...@gmail.com
 Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03




 

 

Hi Jie,

 

Now that you mention VTN-ID, I have to point out that the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in 
draft-peng-teas-network-slicing, just a new name. That can be seen from the 
evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/

 

I'm glad to see that the idea in draft-peng-teas-network-slicing and 
draft-bestbar-spring-scalable-ns have been generously adopted by you.

 

Regards,

PSF


 


原始邮件



发件人：Dongjie(Jimmy)



收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;



抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert 
Raszuk;lsr@ietf.org;



日 期 ：2021年03月09日 00:31



主 题 ：Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03




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


Hi Tarek,


 


Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.


 


As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.


 


Best regards,


Jie


 




From: Tarek Saad [mailto:ts...@juniper.net] 
 Sent: Monday, March 8, 2021 10:44 PM
 To: Dongjie (Jimmy) ; Gyan Mishra 
; Tony Przygienda 
 Cc: Les Ginsberg (ginsberg) ; Chongfeng 
Xie ; Acee Lindem (acee) ; Robert 
Raszuk ; lsr@ietf.org
 Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03




 


Hi authors,


 


My understanding is the draft is proposing a separate MT topology (uniqu

Re: [Lsr] Why not leverage Network conditions to optimize balancing among multiple App Layer Load Balancers? as proposed by draft-dunbar-lsr-5g-edge-compute-ospf-ext

[Linda Dunbar]

Christian,

If “network fails”, the packets won’t even get into the desired App Server (or 
App Layer Load Balancer).
What the draft has proposed is to add a “Tie breaker” or additional weight to 
the “Best Path” selection by  BGP/IGP.

There is definitely interaction among the Application Function Controller (AF) 
and the network. The Load measurement can be advertised to the AF which can 
perform dynamic analysis and send back more accurate value for the “Site 
preference” to the routers. But they are out of the scope of this draft.

[cid:image003.png@01D714A7.8CDF3010]


Optimizing the ANYCAST for 5G EC is a concrete use case for Dynamic ANYCAST 
initiative. While the Dynamic ANYCAST is for bigger network, the 5G EC 
optimization is for smaller 5G Local Data Network.

Linda

From: Christian Hopps 
Sent: Monday, March 8, 2021 6:00 PM
To: Linda Dunbar 
Cc: Christian Hopps ; lsr@ietf.org
Subject: Re: Why not leverage Network conditions to optimize balancing among 
multiple App Layer Load Balancers? as proposed by 
draft-dunbar-lsr-5g-edge-compute-ospf-ext




On Mar 8, 2021, at 7:40 PM, Linda Dunbar 
mailto:linda.dun...@futurewei.com>> wrote:

Christian,

You said at LSR session today that there might be concern of network optimizing 
ANYCAST traffic to better balance among multiple App Layer Load Balancers.
First of all, only the Applications that need to leverage the network condition 
to balance among their multiple Load Balancers will get the benefit of path 
selection that are based on the combination of routing distance and other 
dynamic running status. The networks (e.g. 5G EC Local Data Networks)  only 
optimize the ANYCAST traffic for the registered addresses.
The network is already responsible for selecting the shortest path to one 
Application Load Balancer. draft-dunbar-lsr-5g-edge-compute-ospf-ext proposes 
to add additional weight in path selection.

ANYCAST makes it possible to dynamically load balance across server locations 
based on network conditions. With multiple servers having the same ANYCAST 
address, it eliminates the single point of failure and bottleneck at the 
application layer load balancer that has the shortest routing distance. Another 
benefit of using ANYCAST address is removing the dependency on how UEs get the 
IP addresses for their Applications. Some UEs (or clients) might use stale 
cached IP addresses for extended period.

Network service providers can even offer this as a value added service, making 
network information more useful to deliver services to applications.
Isn’t it a win-win approach for both network service providers and the 
applications owners?

As WG member,

It's not a win when their network fails.

At a high level I think the idea of a smart network is interesting. I don't 
have good initial feelings though about trying to achieve that by adding 
application load based metrics into the routing protocol. There's all sort of 
layer violations going on there for one, but perhaps more importantly, our 
routing protocols have not been tried and tested over the decades with this use 
in mind.

One could imagine designing a higher layer distributed load balancing 
application/protocol that utilized routing information though, something like 
that would align more closely with the layering we've been designing to all 
these years. It probably would not rely on anycast exclusively, but instead use 
anycast to talk to a server that implemented this LB protocol (something 
anycast is good at) which would provide a unicast address for the requested 
application, with the ability to adjust (reacquire a new unicast address, 
whatever) as conditions (either at the routing or application layer) change 
through notifications or polling. Just brainstorming here, but there are lots 
of ways one could imagine this working.

Thanks,
Chris.



Linda Dunbar

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

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Peter Psenak]

Robert,

On 09/03/2021 12:20, Robert Raszuk wrote:


 > In addition you may have a hierarchical RR, which would still involve
 > BGP signalling.

Last time I measured time it takes to propage withdraw via good RR was 
single milliseconds.



 > because BGP signalling is prefix based and as a result slow.
+
 > that is the whole point, you need something that is prefix independent.

BGP can be easily setup in prefix independent way today.

Example 1:

If session to PE1 goes down, withdraw all RDs received from such PE.


still dependent on RDs and BGP specific. We want app independent way of 
signaling the reachability loss. At the end that's what IGPs do without 
a presence of summarization.


Again, I'm not advocating the solution proposed in 
draft-wang-lsr-prefix-unreachable-annoucement. I'm just saying the 
problem seems valid  and IGP based solution is not an unreasonable thing 
to consider if a reasonable one can be found.




Example 2:

Use IGP recursion - Use RFC3107 to construct your interarea LSPs. If PE 


there is no LSP in SRv6.

Peter

goes down withdraw it. IGP can still signal summary no issue as no 
inet.3 route.


Best,
R.


On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak > wrote:


Hi Robert,

On 09/03/2021 12:02, Robert Raszuk wrote:
 > Hey Peter,
 >
 > Well ok so let's forget about LDP - cool !
 >
 > So IGP sends summary around and that is all what is needed.
 >
 > So the question why not propage information that PE went down in
service
 > signalling - today mainly BGP.

because BGP signalling is prefix based and as a result slow.

 >
 >  >   And forget BFD, does not scale with 10k PEs.
 >
 > You missed the point. No one is proposing full mesh of BFD sessions
 > between all PEs. I hope so at least.
 >
 > PE is connected to RRs so you need as many BFD sessions as RR to
PE BGP
 > sessions.

that can be still too many.
In addition you may have a hierarchical RR, which would still involve
BGP signalling.

Once that session is brought down RR has all it needs to
 > trigger a message (withdraw or implicit withdraw) to remove the
 > broken service routes in a scalable way.

that is the whole point, you need something that is prefix independent.

thanks,
Peter

 >
 > Thx,
 > R.
 >
 > PS. Yes we still need to start support signalling of
unreachability in
 > BGP itself when BGP is used for underlay but this is a bit
different use
 > case and outside of scope of LSR
 >
 >
 > On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak mailto:ppse...@cisco.com>
 > >> wrote:
 >
 >     Robert,
 >
 >     On 09/03/2021 11:47, Robert Raszuk wrote:
 >      >  > You’re trying to fix a problem in the overlay by
morphing the
 >      > underlay.  How can that seem like a good idea?
 >      >
 >      > I think this really nails this discussion.
 >      >
 >      > We have discussed this before and while the concept of
signalling
 >      > unreachability does seem useful such signalling should be done
 >     where it
 >      > belongs.
 >      >
 >      > Here clearly we are talking about faster connectivity
restoration
 >     for
 >      > overlay services so it naturally belongs in overlay.
 >      >
 >      > It could be a bit misleading as this is today underlay which
 >     propagates
 >      > reachability of PEs and overlay relies on it. And to scale,
 >      > summarization is used hence in the underlay, failing
remote PEs
 >     remain
 >      > reachable. That however in spite of many efforts in lots of
 >     networks are
 >      > really not the practical problem as those networks still
relay on
 >     exact
 >      > match of IGP to LDP FEC when MPLS is used. So removal of
/32 can and
 >      > does happen.
 >
 >     think SRv6, forget /32 or /128 removal. Think summarization.
 >
 >     I'm not necessary advocating the solution proposed in this
particular
 >     draft, but the problem is valid. We need fast detection of
the PE loss.
 >
 >     And forget BFD, does not scale with 10k PEs.
 >
 >     thanks,
 >     Peter
 >
 >
 >
 >      >
 >      > In the same time BGP can pretty quickly (milliseconds)
 >     remove affected
 >      > service routes (or rather paths) hence connectivity can be
 >     restored to
 >      > redundantly connected endpoints in sub second. Such
removal can
 >     be in a
 >      > form of atomic withdraw (or readvertisement), removal of
recursive
 >      > routes (next hop going down) or withdraw of few RD/64
prefixes.
 >      >
 >      > I am not convinced and I have not seen any evidence tha

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Giuseppe Fioccola]

Hi All,
I support the adoption of this document. It provides an useful mechanism to 
build SR based VTNs using existing IS-IS Multi-Topology instances to provide 
the network resources for each VTN.

Regards,

Giuseppe

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, March 3, 2021 12:28 AM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.

This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.

Thanks,
Acee


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

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Dongjie (Jimmy)]

Hi,

Since this discussion is not related to the adoption poll for 
draft-xie-lsr-isis-sr-vtn-mt, please start a separate mail thread if you want 
to discuss other documents.

A brief reply:

In the current version or any previous version of 
draft-peng-teas-network-slicing, there is no scalability considerations, nor 
any mechanism to improve the scalability. While the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn was introduced for the scalability purpose 
one year ago. Thus I think your statement is totally wrong.

Best regards,
Jie

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of 
peng.sha...@zte.com.cn
Sent: Tuesday, March 9, 2021 10:52 AM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>
Cc: hayabusa...@gmail.com; 
rob...@raszuk.net; 
ts...@juniper.net; 
chongfeng@foxmail.com; 
ginsberg=40cisco@dmarc.ietf.org;
 lsr@ietf.org; a...@cisco.com; 
tonysi...@gmail.com
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03




Hi Jie,



Now that you mention VTN-ID, I have to point out that the VTN-ID in 
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in 
draft-peng-teas-network-slicing, just a new name. That can be seen from the 
evolution of the historical versions of the these two drafts.

See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/



I'm glad to see that the idea in draft-peng-teas-network-slicing and 
draft-bestbar-spring-scalable-ns have been generously adopted by you.



Regards,

PSF


原始邮件
发件人：Dongjie(Jimmy)
收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;
抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert 
Raszuk;lsr@ietf.org;
日 期 ：2021年03月09日 00:31
主 题 ：Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Hi Tarek,

Your understanding about the scalability implication of this MT based VTN 
mechanism is correct, this is also described in section “scalability 
considerations” of this draft. The value of this mechanism is that it reuses 
several existing TLVs together to provide the required function.

As for the mechanisms which can provide better scalability, you could refer to 
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is 
introduced, and multiple VTNs can be associated with the same topology. Further 
discussion about that draft and its relationship with 
draft-bestbar-lsr-spring-sa could happen in a separate thread.

Best regards,
Jie
 
From: Tarek Saad [mailto:ts...@juniper.net]
Sent: Monday, March 8, 2021 10:44 PM
To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; Gyan 
Mishra mailto:hayabusa...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Cc: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Chongfeng Xie mailto:chongfeng@foxmail.com>>; 
Acee Lindem (acee) mailto:a...@cisco.com>>; Robert Raszuk 
mailto:rob...@raszuk.net>>; lsr@ietf.org
Subject: Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03

Hi authors,

My understanding is the draft is proposing a separate MT topology (unique 
MT-ID) to identify a forwarding treatment to be enforced on a shared resource.
While this may work for limited number of MT topologies (i.e. forwarding 
treatments), as described in RF5120 there is overhead with creating/advertising 
and managing and running separate SPF for each of the MT topology. This will 
restrict the scalability of such approach (number of forwarding treatments to 
be realized) using this approach.

In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an independent ID 
(associated with the forwarding treatment) independent of the topology ID. This 
allows the # of forwarding treatmentst to be independent of the # of MT 
topologies that need to be managed by IGP; and hence, allow it to scale. Your 
feedback on this approach is welcome.

Regards,
Tarek


On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" 
mailto:lsr-boun...@ietf.org> on behalf of 
jie.d...@huawei.com> wrote:

Hi Gyan,

Thanks for your comments.

As you mentioned, both MT and MI can provide separate topologies and the 
topology based computation, and MI can provide separate LSDBs at some 
additional cost (separate adjacencies, etc.). In this document, the resource of 
VTN mainly refers to the forwarding plane resources, thus MT is chos

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Robert Raszuk]

> In addition you may have a hierarchical RR, which would still involve
> BGP signalling.

Last time I measured time it takes to propage withdraw via good RR was
single milliseconds.


> because BGP signalling is prefix based and as a result slow.
+
> that is the whole point, you need something that is prefix independent.

BGP can be easily setup in prefix independent way today.

Example 1:

If session to PE1 goes down, withdraw all RDs received from such PE.

Example 2:

Use IGP recursion - Use RFC3107 to construct your interarea LSPs. If PE
goes down withdraw it. IGP can still signal summary no issue as no inet.3
route.

Best,
R.


On Tue, Mar 9, 2021 at 12:12 PM Peter Psenak  wrote:

> Hi Robert,
>
> On 09/03/2021 12:02, Robert Raszuk wrote:
> > Hey Peter,
> >
> > Well ok so let's forget about LDP - cool !
> >
> > So IGP sends summary around and that is all what is needed.
> >
> > So the question why not propage information that PE went down in service
> > signalling - today mainly BGP.
>
> because BGP signalling is prefix based and as a result slow.
>
> >
> >  >   And forget BFD, does not scale with 10k PEs.
> >
> > You missed the point. No one is proposing full mesh of BFD sessions
> > between all PEs. I hope so at least.
> >
> > PE is connected to RRs so you need as many BFD sessions as RR to PE BGP
> > sessions.
>
> that can be still too many.
> In addition you may have a hierarchical RR, which would still involve
> BGP signalling.
>
> Once that session is brought down RR has all it needs to
> > trigger a message (withdraw or implicit withdraw) to remove the
> > broken service routes in a scalable way.
>
> that is the whole point, you need something that is prefix independent.
>
> thanks,
> Peter
>
> >
> > Thx,
> > R.
> >
> > PS. Yes we still need to start support signalling of unreachability in
> > BGP itself when BGP is used for underlay but this is a bit different use
> > case and outside of scope of LSR
> >
> >
> > On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak  > > wrote:
> >
> > Robert,
> >
> > On 09/03/2021 11:47, Robert Raszuk wrote:
> >  >  > You’re trying to fix a problem in the overlay by morphing the
> >  > underlay.  How can that seem like a good idea?
> >  >
> >  > I think this really nails this discussion.
> >  >
> >  > We have discussed this before and while the concept of signalling
> >  > unreachability does seem useful such signalling should be done
> > where it
> >  > belongs.
> >  >
> >  > Here clearly we are talking about faster connectivity restoration
> > for
> >  > overlay services so it naturally belongs in overlay.
> >  >
> >  > It could be a bit misleading as this is today underlay which
> > propagates
> >  > reachability of PEs and overlay relies on it. And to scale,
> >  > summarization is used hence in the underlay, failing remote PEs
> > remain
> >  > reachable. That however in spite of many efforts in lots of
> > networks are
> >  > really not the practical problem as those networks still relay on
> > exact
> >  > match of IGP to LDP FEC when MPLS is used. So removal of /32 can
> and
> >  > does happen.
> >
> > think SRv6, forget /32 or /128 removal. Think summarization.
> >
> > I'm not necessary advocating the solution proposed in this particular
> > draft, but the problem is valid. We need fast detection of the PE
> loss.
> >
> > And forget BFD, does not scale with 10k PEs.
> >
> > thanks,
> > Peter
> >
> >
> >
> >  >
> >  > In the same time BGP can pretty quickly (milliseconds)
> > remove affected
> >  > service routes (or rather paths) hence connectivity can be
> > restored to
> >  > redundantly connected endpoints in sub second. Such removal can
> > be in a
> >  > form of atomic withdraw (or readvertisement), removal of recursive
> >  > routes (next hop going down) or withdraw of few RD/64 prefixes.
> >  >
> >  > I am not convinced and I have not seen any evidence that if we
> > put this
> >  > into IGP it will be any faster across areas or domains (case of
> >  > redistribution over ASBRs to and from IGP to BGP). One thing for
> > sure -
> >  > it will be much more complex to troubleshoot.
> >  >
> >  > Thx,
> >  > R.
> >  >
> >  > On Tue, Mar 9, 2021 at 5:39 AM Tony Li  > 
> >  > >> wrote:
> >  >
> >  >
> >  > Hi Gyan,
> >  >
> >  >  > Gyan> In previous threads BFD multi hop has been
> > mentioned to
> >  > track IGP liveliness but that gets way overly complicated
> > especially
> >  > with large domains and not viable.
> >  >
> >  >
> >  > This is not tracking IGP liveness, this is to track BGP
> endpoint
> >  > liveness.
> >  >
> >  > Here in 2021, we se

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Tony Przygienda]

I know it's not fashionable (yet) but put multipoint BFD on BIER & run 2
subdomains and you got 10K. Add subdomains to taste which will also allow
to partition it across chips easily. Yepp, needs silicon that will sustain
reasonable rates but you have a pretty good darn' solution. IGP gives you
reachability for BIER already, you got minimal replication and you can tune
your timers to heart's delight.

Sticking stuff in IGP (to second Tony #1) is very satisfying, especially
since some of that could work some time @ no load on IGP. All those "let's
add a million things to IGP" only catches you when you realize in serious
outage your IGP is busy figuring out/flooding junk rather than getting you
basic connectivity. Yes, good implementation technique and careful design
of protocol can help (e.g. take ISIS extensions that allow you for a large
LSP space where you know what priority things are that need to go out/come
in/compute, here is sympathize with the new idea of separate instance for
"junk hauling" BTW ;-) but mashing overlay into underlay of your most time
sensitive and delicate piece of network control to use it as overlay
signalling protocol does not have a promising history. Confounding the
whole thing on top with adding a route type as signalling means is a bit
injury on top of insult or vice versa

-- tony

On Tue, Mar 9, 2021 at 12:03 PM Robert Raszuk  wrote:

> Hey Peter,
>
> Well ok so let's forget about LDP - cool !
>
> So IGP sends summary around and that is all what is needed.
>
> So the question why not propage information that PE went down in service
> signalling - today mainly BGP.
>
> >   And forget BFD, does not scale with 10k PEs.
>
> You missed the point. No one is proposing full mesh of BFD sessions
> between all PEs. I hope so at least.
>
> PE is connected to RRs so you need as many BFD sessions as RR to PE BGP
> sessions. Once that session is brought down RR has all it needs to trigger
> a message (withdraw or implicit withdraw) to remove the broken service
> routes in a scalable way.
>
> Thx,
> R.
>
> PS. Yes we still need to start support signalling of unreachability in BGP
> itself when BGP is used for underlay but this is a bit different use case
> and outside of scope of LSR
>
>
> On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak  wrote:
>
>> Robert,
>>
>> On 09/03/2021 11:47, Robert Raszuk wrote:
>> >  > You’re trying to fix a problem in the overlay by morphing the
>> > underlay.  How can that seem like a good idea?
>> >
>> > I think this really nails this discussion.
>> >
>> > We have discussed this before and while the concept of signalling
>> > unreachability does seem useful such signalling should be done where it
>> > belongs.
>> >
>> > Here clearly we are talking about faster connectivity restoration for
>> > overlay services so it naturally belongs in overlay.
>> >
>> > It could be a bit misleading as this is today underlay which propagates
>> > reachability of PEs and overlay relies on it. And to scale,
>> > summarization is used hence in the underlay, failing remote PEs remain
>> > reachable. That however in spite of many efforts in lots of networks
>> are
>> > really not the practical problem as those networks still relay on exact
>> > match of IGP to LDP FEC when MPLS is used. So removal of /32 can and
>> > does happen.
>>
>> think SRv6, forget /32 or /128 removal. Think summarization.
>>
>> I'm not necessary advocating the solution proposed in this particular
>> draft, but the problem is valid. We need fast detection of the PE loss.
>>
>> And forget BFD, does not scale with 10k PEs.
>>
>> thanks,
>> Peter
>>
>>
>>
>> >
>> > In the same time BGP can pretty quickly (milliseconds) remove affected
>> > service routes (or rather paths) hence connectivity can be restored to
>> > redundantly connected endpoints in sub second. Such removal can be in a
>> > form of atomic withdraw (or readvertisement), removal of recursive
>> > routes (next hop going down) or withdraw of few RD/64 prefixes.
>> >
>> > I am not convinced and I have not seen any evidence that if we put this
>> > into IGP it will be any faster across areas or domains (case of
>> > redistribution over ASBRs to and from IGP to BGP). One thing for sure -
>> > it will be much more complex to troubleshoot.
>> >
>> > Thx,
>> > R.
>> >
>> > On Tue, Mar 9, 2021 at 5:39 AM Tony Li > > > wrote:
>> >
>> >
>> > Hi Gyan,
>> >
>> >  > Gyan> In previous threads BFD multi hop has been mentioned to
>> > track IGP liveliness but that gets way overly complicated especially
>> > with large domains and not viable.
>> >
>> >
>> > This is not tracking IGP liveness, this is to track BGP endpoint
>> > liveness.
>> >
>> > Here in 2021, we seem to have (finally) discovered that we can
>> > automate our management plane. This ameliorates a great deal of
>> > complexity.
>> >
>> >
>> >  > Gyan> As we are trying to signal the IGP to trigger the
>> > control plane converge

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Peter Psenak]

Hi Robert,

On 09/03/2021 12:02, Robert Raszuk wrote:

Hey Peter,

Well ok so let's forget about LDP - cool !

So IGP sends summary around and that is all what is needed.

So the question why not propage information that PE went down in service 
signalling - today mainly BGP.


because BGP signalling is prefix based and as a result slow.



 >   And forget BFD, does not scale with 10k PEs.

You missed the point. No one is proposing full mesh of BFD sessions 
between all PEs. I hope so at least.


PE is connected to RRs so you need as many BFD sessions as RR to PE BGP 
sessions. 


that can be still too many.
In addition you may have a hierarchical RR, which would still involve 
BGP signalling.


Once that session is brought down RR has all it needs to
trigger a message (withdraw or implicit withdraw) to remove the 
broken service routes in a scalable way.


that is the whole point, you need something that is prefix independent.

thanks,
Peter



Thx,
R.

PS. Yes we still need to start support signalling of unreachability in 
BGP itself when BGP is used for underlay but this is a bit different use 
case and outside of scope of LSR



On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak > wrote:


Robert,

On 09/03/2021 11:47, Robert Raszuk wrote:
 >  > You’re trying to fix a problem in the overlay by morphing the
 > underlay.  How can that seem like a good idea?
 >
 > I think this really nails this discussion.
 >
 > We have discussed this before and while the concept of signalling
 > unreachability does seem useful such signalling should be done
where it
 > belongs.
 >
 > Here clearly we are talking about faster connectivity restoration
for
 > overlay services so it naturally belongs in overlay.
 >
 > It could be a bit misleading as this is today underlay which
propagates
 > reachability of PEs and overlay relies on it. And to scale,
 > summarization is used hence in the underlay, failing remote PEs
remain
 > reachable. That however in spite of many efforts in lots of
networks are
 > really not the practical problem as those networks still relay on
exact
 > match of IGP to LDP FEC when MPLS is used. So removal of /32 can and
 > does happen.

think SRv6, forget /32 or /128 removal. Think summarization.

I'm not necessary advocating the solution proposed in this particular
draft, but the problem is valid. We need fast detection of the PE loss.

And forget BFD, does not scale with 10k PEs.

thanks,
Peter



 >
 > In the same time BGP can pretty quickly (milliseconds)
remove affected
 > service routes (or rather paths) hence connectivity can be
restored to
 > redundantly connected endpoints in sub second. Such removal can
be in a
 > form of atomic withdraw (or readvertisement), removal of recursive
 > routes (next hop going down) or withdraw of few RD/64 prefixes.
 >
 > I am not convinced and I have not seen any evidence that if we
put this
 > into IGP it will be any faster across areas or domains (case of
 > redistribution over ASBRs to and from IGP to BGP). One thing for
sure -
 > it will be much more complex to troubleshoot.
 >
 > Thx,
 > R.
 >
 > On Tue, Mar 9, 2021 at 5:39 AM Tony Li mailto:tony...@tony.li>
 > >> wrote:
 >
 >
 >     Hi Gyan,
 >
 >      >     Gyan> In previous threads BFD multi hop has been
mentioned to
 >     track IGP liveliness but that gets way overly complicated
especially
 >     with large domains and not viable.
 >
 >
 >     This is not tracking IGP liveness, this is to track BGP endpoint
 >     liveness.
 >
 >     Here in 2021, we seem to have (finally) discovered that we can
 >     automate our management plane. This ameliorates a great deal of
 >     complexity.
 >
 >
 >      >     Gyan> As we are trying to signal the IGP to trigger the
 >     control plane convergence, the flooding machinery in the IGP
already
 >     exists well as the prefix originator sub TLV from the link or
node
 >     failure.  IGP seems to be the perfect mechanism for the control
 >     plane signaling switchover.
 >
 >
 >     You’re trying to fix a problem in the overlay by morphing the
 >     underlay.  How can that seem like a good idea?
 >
 >
 >      >       Gyan>As I mentioned advertising flooding of the longer
 >     prefix defeats the purpose of summarization.
 >
 >
 >     PUA also defeats summarization.  If you really insist on faster
 >     convergence and not building a sufficiently redundant
topology, then
 >     yes, your area will partition and you will have to pay the
price of
 >     additional state for your longer prefixes.
 >
 >
 > 

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Robert Raszuk]

Hey Peter,

Well ok so let's forget about LDP - cool !

So IGP sends summary around and that is all what is needed.

So the question why not propage information that PE went down in service
signalling - today mainly BGP.

>   And forget BFD, does not scale with 10k PEs.

You missed the point. No one is proposing full mesh of BFD sessions between
all PEs. I hope so at least.

PE is connected to RRs so you need as many BFD sessions as RR to PE BGP
sessions. Once that session is brought down RR has all it needs to trigger
a message (withdraw or implicit withdraw) to remove the broken service
routes in a scalable way.

Thx,
R.

PS. Yes we still need to start support signalling of unreachability in BGP
itself when BGP is used for underlay but this is a bit different use case
and outside of scope of LSR


On Tue, Mar 9, 2021 at 11:55 AM Peter Psenak  wrote:

> Robert,
>
> On 09/03/2021 11:47, Robert Raszuk wrote:
> >  > You’re trying to fix a problem in the overlay by morphing the
> > underlay.  How can that seem like a good idea?
> >
> > I think this really nails this discussion.
> >
> > We have discussed this before and while the concept of signalling
> > unreachability does seem useful such signalling should be done where it
> > belongs.
> >
> > Here clearly we are talking about faster connectivity restoration for
> > overlay services so it naturally belongs in overlay.
> >
> > It could be a bit misleading as this is today underlay which propagates
> > reachability of PEs and overlay relies on it. And to scale,
> > summarization is used hence in the underlay, failing remote PEs remain
> > reachable. That however in spite of many efforts in lots of networks are
> > really not the practical problem as those networks still relay on exact
> > match of IGP to LDP FEC when MPLS is used. So removal of /32 can and
> > does happen.
>
> think SRv6, forget /32 or /128 removal. Think summarization.
>
> I'm not necessary advocating the solution proposed in this particular
> draft, but the problem is valid. We need fast detection of the PE loss.
>
> And forget BFD, does not scale with 10k PEs.
>
> thanks,
> Peter
>
>
>
> >
> > In the same time BGP can pretty quickly (milliseconds) remove affected
> > service routes (or rather paths) hence connectivity can be restored to
> > redundantly connected endpoints in sub second. Such removal can be in a
> > form of atomic withdraw (or readvertisement), removal of recursive
> > routes (next hop going down) or withdraw of few RD/64 prefixes.
> >
> > I am not convinced and I have not seen any evidence that if we put this
> > into IGP it will be any faster across areas or domains (case of
> > redistribution over ASBRs to and from IGP to BGP). One thing for sure -
> > it will be much more complex to troubleshoot.
> >
> > Thx,
> > R.
> >
> > On Tue, Mar 9, 2021 at 5:39 AM Tony Li  > > wrote:
> >
> >
> > Hi Gyan,
> >
> >  > Gyan> In previous threads BFD multi hop has been mentioned to
> > track IGP liveliness but that gets way overly complicated especially
> > with large domains and not viable.
> >
> >
> > This is not tracking IGP liveness, this is to track BGP endpoint
> > liveness.
> >
> > Here in 2021, we seem to have (finally) discovered that we can
> > automate our management plane. This ameliorates a great deal of
> > complexity.
> >
> >
> >  > Gyan> As we are trying to signal the IGP to trigger the
> > control plane convergence, the flooding machinery in the IGP already
> > exists well as the prefix originator sub TLV from the link or node
> > failure.  IGP seems to be the perfect mechanism for the control
> > plane signaling switchover.
> >
> >
> > You’re trying to fix a problem in the overlay by morphing the
> > underlay.  How can that seem like a good idea?
> >
> >
> >  >   Gyan>As I mentioned advertising flooding of the longer
> > prefix defeats the purpose of summarization.
> >
> >
> > PUA also defeats summarization.  If you really insist on faster
> > convergence and not building a sufficiently redundant topology, then
> > yes, your area will partition and you will have to pay the price of
> > additional state for your longer prefixes.
> >
> >
> >  > In order to do what you are stating you have to remove the
> > summarization and go back to domain wide flooding
> >
> >
> > No, I’m suggesting you maintain the summary and ALSO advertise the
> > longer prefix that you feel is essential to reroute immediately.
> >
> >
> >  > which completely defeats the goal of the draft which is to make
> > host route summarization viable for operators.  We know the prefix
> > that went down and that is why with the PUA negative advertisement
> > we can easily flood a null0 to block the control plane from
> > installing the route.
> >
> >
> > So you can also advertise the more specific from the connected ABR…
> >
> >
> >  > We don

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Peter Psenak]

Robert,

On 09/03/2021 11:47, Robert Raszuk wrote:
 > You’re trying to fix a problem in the overlay by morphing the 
underlay.  How can that seem like a good idea?


I think this really nails this discussion.

We have discussed this before and while the concept of signalling 
unreachability does seem useful such signalling should be done where it 
belongs.


Here clearly we are talking about faster connectivity restoration for 
overlay services so it naturally belongs in overlay.


It could be a bit misleading as this is today underlay which propagates 
reachability of PEs and overlay relies on it. And to scale, 
summarization is used hence in the underlay, failing remote PEs remain 
reachable. That however in spite of many efforts in lots of networks are 
really not the practical problem as those networks still relay on exact 
match of IGP to LDP FEC when MPLS is used. So removal of /32 can and 
does happen.


think SRv6, forget /32 or /128 removal. Think summarization.

I'm not necessary advocating the solution proposed in this particular 
draft, but the problem is valid. We need fast detection of the PE loss.


And forget BFD, does not scale with 10k PEs.

thanks,
Peter





In the same time BGP can pretty quickly (milliseconds) remove affected 
service routes (or rather paths) hence connectivity can be restored to 
redundantly connected endpoints in sub second. Such removal can be in a 
form of atomic withdraw (or readvertisement), removal of recursive 
routes (next hop going down) or withdraw of few RD/64 prefixes.


I am not convinced and I have not seen any evidence that if we put this 
into IGP it will be any faster across areas or domains (case of 
redistribution over ASBRs to and from IGP to BGP). One thing for sure - 
it will be much more complex to troubleshoot.


Thx,
R.

On Tue, Mar 9, 2021 at 5:39 AM Tony Li > wrote:



Hi Gyan,

 >     Gyan> In previous threads BFD multi hop has been mentioned to
track IGP liveliness but that gets way overly complicated especially
with large domains and not viable.


This is not tracking IGP liveness, this is to track BGP endpoint
liveness.

Here in 2021, we seem to have (finally) discovered that we can
automate our management plane. This ameliorates a great deal of
complexity.


 >     Gyan> As we are trying to signal the IGP to trigger the
control plane convergence, the flooding machinery in the IGP already
exists well as the prefix originator sub TLV from the link or node
failure.  IGP seems to be the perfect mechanism for the control
plane signaling switchover.


You’re trying to fix a problem in the overlay by morphing the
underlay.  How can that seem like a good idea?


 >       Gyan>As I mentioned advertising flooding of the longer
prefix defeats the purpose of summarization.


PUA also defeats summarization.  If you really insist on faster
convergence and not building a sufficiently redundant topology, then
yes, your area will partition and you will have to pay the price of
additional state for your longer prefixes.


 > In order to do what you are stating you have to remove the
summarization and go back to domain wide flooding


No, I’m suggesting you maintain the summary and ALSO advertise the
longer prefix that you feel is essential to reroute immediately.


 > which completely defeats the goal of the draft which is to make
host route summarization viable for operators.  We know the prefix
that went down and that is why with the PUA negative advertisement
we can easily flood a null0 to block the control plane from
installing the route.


So you can also advertise the more specific from the connected ABR…


 > We don’t have any prior knowledge of the alternate for the egress
PE bgp next hop attribute for the customer VPN overlay.  So the only
way to accomplish what you are asking is not do any summarization
and flood al host routes.  Of course  as I stated defeats the
purpose of the draft.


Please read again.

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] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Tony Przygienda]

and replying to myself, as was mentioned yesterday in LSR already, the key
questions is HOW MANY control plane slices and then FIB slices do you
really need in the technology to be built.  And how much of that needs to
be really in the core? Both will have large implication on solutions, you
cannot run 2000 IGP processes in a box but you could run 2K topologies on
IGP (cough, cough). IGP control plane will be limited by how many
computations you can crunch (unless you take that off box, bit risky but
thnkable) and then can you OAM & operate such a solution, especially if
topologies disjoin. FEC sharing tricks are proposed here and are worth
thinking through if they allow to squeeze #context in control plane into
less context in FIB but compression is a devil (think SR stack compression
today) since it often leads operationally to surprising effects. In
forwarding path all those things are trickier/more costly, on the edge we
run thousands of VPNs/EVIs in MP-BGP so it's thinkable, in the core, ehem,
well, you start to reinvent MPLS since about only thing that scales on
every core box is switching (if you want precise per box
accounting/control). You can 'fudge' things by the ancient loose source
routing, ehem, sorry, it's called SR now ;-) but this has a formidable set
of operational challenges since the ole Token Ring doing it.

exec summary: figure out how many "slices" you need in control & data plane
& how tight they need to be in terms of SLAs and then swallow the
trade-offs. that may not be a single data point and multiple solutions may
be necessary.

--- tony

On Tue, Mar 9, 2021 at 11:47 AM Tony Przygienda  wrote:

> Gyan, you are confusing RIB with LSDB. It is absolutely feasible and
> normal to generate multiple RIBs/FIBs from a single LSDB and that has been
> done for about forever
>
> problem with lots of those proposals and assertions here is that
> powerpoint and rfc text always compiles no matter what you put into it,
> silicon and real implementations force to face the world not as you imagine
> it but as you can actually make it work in practical terms. Akin to talking
> about pottery (*there is a value to it in itself) and making a real pot
> with clay. Making a real pot first gives you a much better chance to
> actually talk about pottery meaningfully albeit it does not teach you
> aesthetics of pottery or a complete new way to make pots possibly.
>
> 2c
>
> -- tony
>
> On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra  wrote:
>
>> Hi Peter
>>
>> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:
>>
>>> Gyan,
>>>
>>> On 05/03/2021 16:46, Gyan Mishra wrote:
>>> > Yali
>>> >
>>> > I agree with a Peter.
>>> >
>>> > As for resource isolation and provisioning of a VTN I think you really
>>> > need separate LSDB instances provided by MT or MI as better suited for
>>> > network slicing.
>>>
>>> MT does not provide LSDB separation, only MI does.
>>>
>>> thanks,
>>> Peter
>>
>>
>>I thought that each MT topology was a separate RIB meaning separate
>> LSDB.  The RFC is confusing.😄
>>
>> https://tools.ietf.org/html/rfc5120
>>
>> 6 .  MT SPF Computation
>>
>>Each MT MUST run its own instance of the decision process.  The
>>pseudo-node LSPs are used by all topologies during computation.  Each
>>non-default topology MAY have its attached bit and overload bit set
>>in the MT TLV.  A reverse-connectivity check within SPF MUST follow
>>the according MT to assure the bi-directional reachability within the
>>same MT.
>>
>>The results of each computation SHOULD be stored in a separate
>>Routing Information Base (RIB), in normal cases, otherwise
>>overlapping addresses in different topologies could lead to
>>undesirable routing behavior, such as forwarding loops.  The
>>forwarding logic and configuration need to ensure the same MT is
>>traversed from the source to the destination for packets.  The
>>nexthops derived from the MT SPF MUST belong to the adjacencies
>>
>>
>> conforming to the same MT for correct forwarding.  It is recommended
>>for the administrators to ensure consistent configuration of all
>>routers in the domain to prevent undesirable forwarding behavior.
>>
>>No attempt is made in this document to allow one topology to
>>calculate routes using the routing information from another topology
>>inside SPF.  Even though it is possible to redistribute and leak
>>routes from another IS-IS topology or from external sources, the
>>exact mechanism is beyond the scope of this document.
>>
>>
>>
>>>
>>> >
>>> > To me it seems a common LSDB shared among network slices VTN underlay
>>> > could be problematic with network overlap issues.
>>> >
>>> > Kind Regards
>>> >
>>> > Gyan
>>> >
>>> > On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak >> > > wrote:
>>> >
>>> > Hi Yali,
>>> >
>>> > On 05/03/2021 15:31, wangyali wrote:
>>> >  > Hi Peter,
>>> >  

Re: [Lsr] New Version Notification for draft-wang-lsr-isis-mfi-00.txt

[Tony Przygienda]

Gyan, you are confusing RIB with LSDB. It is absolutely feasible and normal
to generate multiple RIBs/FIBs from a single LSDB and that has been done
for about forever

problem with lots of those proposals and assertions here is that powerpoint
and rfc text always compiles no matter what you put into it, silicon and
real implementations force to face the world not as you imagine it but as
you can actually make it work in practical terms. Akin to talking about
pottery (*there is a value to it in itself) and making a real pot with
clay. Making a real pot first gives you a much better chance to actually
talk about pottery meaningfully albeit it does not teach you aesthetics of
pottery or a complete new way to make pots possibly.

2c

-- tony

On Fri, Mar 5, 2021 at 5:11 PM Gyan Mishra  wrote:

> Hi Peter
>
> On Fri, Mar 5, 2021 at 10:56 AM Peter Psenak  wrote:
>
>> Gyan,
>>
>> On 05/03/2021 16:46, Gyan Mishra wrote:
>> > Yali
>> >
>> > I agree with a Peter.
>> >
>> > As for resource isolation and provisioning of a VTN I think you really
>> > need separate LSDB instances provided by MT or MI as better suited for
>> > network slicing.
>>
>> MT does not provide LSDB separation, only MI does.
>>
>> thanks,
>> Peter
>
>
>I thought that each MT topology was a separate RIB meaning separate
> LSDB.  The RFC is confusing.😄
>
> https://tools.ietf.org/html/rfc5120
>
> 6 .  MT SPF Computation
>
>Each MT MUST run its own instance of the decision process.  The
>pseudo-node LSPs are used by all topologies during computation.  Each
>non-default topology MAY have its attached bit and overload bit set
>in the MT TLV.  A reverse-connectivity check within SPF MUST follow
>the according MT to assure the bi-directional reachability within the
>same MT.
>
>The results of each computation SHOULD be stored in a separate
>Routing Information Base (RIB), in normal cases, otherwise
>overlapping addresses in different topologies could lead to
>undesirable routing behavior, such as forwarding loops.  The
>forwarding logic and configuration need to ensure the same MT is
>traversed from the source to the destination for packets.  The
>nexthops derived from the MT SPF MUST belong to the adjacencies
>
>
> conforming to the same MT for correct forwarding.  It is recommended
>for the administrators to ensure consistent configuration of all
>routers in the domain to prevent undesirable forwarding behavior.
>
>No attempt is made in this document to allow one topology to
>calculate routes using the routing information from another topology
>inside SPF.  Even though it is possible to redistribute and leak
>routes from another IS-IS topology or from external sources, the
>exact mechanism is beyond the scope of this document.
>
>
>
>>
>> >
>> > To me it seems a common LSDB shared among network slices VTN underlay
>> > could be problematic with network overlap issues.
>> >
>> > Kind Regards
>> >
>> > Gyan
>> >
>> > On Fri, Mar 5, 2021 at 10:28 AM Peter Psenak > > > wrote:
>> >
>> > Hi Yali,
>> >
>> > On 05/03/2021 15:31, wangyali wrote:
>> >  > Hi Peter,
>> >  >
>> >  > Thanks for your question. Please see inline [yali3].
>> >  >
>> >  > -Original Message-
>> >  > From: Peter Psenak [mailto:ppse...@cisco.com
>> > ]
>> >  > Sent: Thursday, March 4, 2021 11:20 PM
>> >  > To: wangyali > > >; Gyan Mishra > > >; Robert Raszuk > > >
>> >  > Cc: Huzhibo mailto:huzh...@huawei.com>>;
>> > Aijun Wang > > >; Tony Li > > >; lsr mailto:lsr@ietf.org
>> >>;
>> > Tianran Zhou mailto:zhoutian...@huawei.com
>> >>
>> >  > Subject: Re: [Lsr] New Version Notification for
>> > draft-wang-lsr-isis-mfi-00.txt
>> >  >
>> >  > Hi Yali,
>> >  >
>> >  > On 04/03/2021 14:45, wangyali wrote:
>> >  >> Hi Peter,
>> >  >>
>> >  >> Please see inline [Yali2]. Thanks a lot.
>> >  >>
>> >  >> -Original Message-
>> >  >> From: Peter Psenak [mailto:ppse...@cisco.com
>> > ]
>> >  >> Sent: Thursday, March 4, 2021 6:50 PM
>> >  >> To: wangyali > > >; Gyan Mishra
>> >  >> mailto:hayabusa...@gmail.com>>; Robert
>> > Raszuk mailto:rob...@raszuk.net>>
>> >  >> Cc: Huzhibo mailto:huzh...@huawei.com>>;
>> > Aijun Wang
>> >  >> mailto:wang...@chinatelecom.cn>>;
>> Tony
>> > Li mailto:tony...@tony.li>>; lsr
>> >  >> mailto:lsr@ietf.org>>; Tianran Zhou
>> > mailto:zhoutian...@huawei.com>>
>> >  >> Subject: Re: [Lsr] New Version Notification for
>> >  >> draft-wang-lsr-isis-mfi-00.txt
>> >  >>
>> >  >> Hi Yali,
>> >  >>
>> > 

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Robert Raszuk]

> You’re trying to fix a problem in the overlay by morphing the underlay.
How can that seem like a good idea?

I think this really nails this discussion.

We have discussed this before and while the concept of signalling
unreachability does seem useful such signalling should be done where it
belongs.

Here clearly we are talking about faster connectivity restoration for
overlay services so it naturally belongs in overlay.

It could be a bit misleading as this is today underlay which propagates
reachability of PEs and overlay relies on it. And to scale, summarization
is used hence in the underlay, failing remote PEs remain reachable. That
however in spite of many efforts in lots of networks are really not the
practical problem as those networks still relay on exact match of IGP to
LDP FEC when MPLS is used. So removal of /32 can and does happen.

In the same time BGP can pretty quickly (milliseconds) remove affected
service routes (or rather paths) hence connectivity can be restored to
redundantly connected endpoints in sub second. Such removal can be in a
form of atomic withdraw (or readvertisement), removal of recursive routes
(next hop going down) or withdraw of few RD/64 prefixes.

I am not convinced and I have not seen any evidence that if we put this
into IGP it will be any faster across areas or domains (case of
redistribution over ASBRs to and from IGP to BGP). One thing for sure - it
will be much more complex to troubleshoot.

Thx,
R.

On Tue, Mar 9, 2021 at 5:39 AM Tony Li  wrote:

>
> Hi Gyan,
>
> > Gyan> In previous threads BFD multi hop has been mentioned to track
> IGP liveliness but that gets way overly complicated especially with large
> domains and not viable.
>
>
> This is not tracking IGP liveness, this is to track BGP endpoint liveness.
>
> Here in 2021, we seem to have (finally) discovered that we can automate
> our management plane. This ameliorates a great deal of complexity.
>
>
> > Gyan> As we are trying to signal the IGP to trigger the control
> plane convergence, the flooding machinery in the IGP already exists well as
> the prefix originator sub TLV from the link or node failure.  IGP seems to
> be the perfect mechanism for the control plane signaling switchover.
>
>
> You’re trying to fix a problem in the overlay by morphing the underlay.
> How can that seem like a good idea?
>
>
> >   Gyan>As I mentioned advertising flooding of the longer prefix
> defeats the purpose of summarization.
>
>
> PUA also defeats summarization.  If you really insist on faster
> convergence and not building a sufficiently redundant topology, then yes,
> your area will partition and you will have to pay the price of additional
> state for your longer prefixes.
>
>
> > In order to do what you are stating you have to remove the summarization
> and go back to domain wide flooding
>
>
> No, I’m suggesting you maintain the summary and ALSO advertise the longer
> prefix that you feel is essential to reroute immediately.
>
>
> > which completely defeats the goal of the draft which is to make host
> route summarization viable for operators.  We know the prefix that went
> down and that is why with the PUA negative advertisement we can easily
> flood a null0 to block the control plane from installing the route.
>
>
> So you can also advertise the more specific from the connected ABR…
>
>
> > We don’t have any prior knowledge of the alternate for the egress PE bgp
> next hop attribute for the customer VPN overlay.  So the only way to
> accomplish what you are asking is not do any summarization and flood al
> host routes.  Of course  as I stated defeats the purpose of the draft.
>
>
> Please read again.
>
> 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

[Lsr] draft-peng-lsr-flex-algo-l2bundles

[Peter Psenak]

Dear authors,

here are couple of comments to draft-peng-lsr-flex-algo-l2bundles:

1. Flex-algo specification as specified in draft-ietf-lsr-flex-algo only 
uses L3 link information for path computation. This is consistent with 
the regular Algo 0 path computation. My preference would be to keep it 
that way.


2. Flex-algo is not a replacement for SRTE. The problem that you are 
trying to solve can be solved by SRTE with the usage of the L2 Adj-SIDs.


3. Usage of the L2 link data for flex-algo path computation is much more 
complex than defining the L-flag in the FAD. You would need to deal with 
things like:


a) conflicting information in L3 and L2 link information
b) missing information in L3 or L2 link information

which would require to define a strict path computation preference rules 
and conflict resolutions that all routers would need to follow. I would 
argue that this is much easier to be done with SRTE, where the logic to 
select the path is a local matter compared to consistency in path 
selection that is required for distributed calculation used by flex-algo.


thanks,
Peter




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

[Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo

[Peter Psenak]

Dear authors,

here are couple of comments to draft-zhu-lsr-isis-sr-vtn-flexalgo:

1. whether we want to flood VTN specific link data in IGPs or not is 
something that deserves its own discussion.


2. Nevertheless, the proposed encoding does not seem to be a fortunate one:

a) it hijacks the L2 bundle member TLV for VTN data. I don't see the 
need for that.


b) the proposed mechanism to associate the VTN specific link data with 
the VTN itself by the use of the link affinities is a very user 
unfriendly way of doing it. If the VTN need only the low latency 
optimization, provisioning additional affinities seems like a 
unnecessary provisioning price that would need to be paid by the user 
for the encoding deficiency. You want to flood the VTN specific link 
data, put the VTN ID in it.


thanks,
Peter




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

Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Peter Psenak]

Tony,

On 09/03/2021 01:03, Tony Li wrote:


Gyan,

If I understand the purpose of this draft, the point is to punch a hole 
in a summary so that traffic is redirected via an alternate, working path.


Rather than punch a hole, why not rely on existing technology? Have the 
valid path advertise the more specific. This will attract the traffic.


that would defeat the purpose of the summarization.

thanks,
Peter



Tony


On Mar 8, 2021, at 3:57 PM, Gyan Mishra > wrote:



Acee.

Please ask the two questions you raised about the PUA draft so we can 
address your concerns.


If anyone else has any other outstanding questions or concerns we 
would like to address as well and resolve.


Once all questions and  concerns are satisfied we would like to ask 
for WG adoption.


Kind Regards

Gyan
--



*Gyan Mishra*
/Network Solutions A//rchitect /
/M 301 502-1347
13101 Columbia Pike
/Silver Spring, MD

___
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