Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-15 Thread tony . li
Hi Huaimo, > Consider the case that the multiple failures occur at almost the same time > and there is no other failure following these multiple failures shortly. In > this case, the backup paths will connect the live end nodes of the failures > on the FT, and the FT partition is fixed. Note

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

2019-04-15 Thread Huaimo Chen
Hi Tony, Computing a whole backup path between two end nodes of a failure and enabling temporary flooding at each hop of the path will guarantee that these two end nodes are connected on the FT, thus the FT partition caused by multiple failures is fixed. The backup path is not a guarantee.

Re: [Lsr] RtgDir review: draft-ietf-isis-segment-routing-extensions-23

2019-04-15 Thread Les Ginsberg (ginsberg)
(Resending w corrected address for rtg-dir) Russ - Thanx for the review - and the kind words. Les > -Original Message- > From: 7ri...@gmail.com <7ri...@gmail.com> > Sent: Sunday, April 14, 2019 6:56 PM > To: rtg-...@ietf.org > Cc: rtg-...@ietfr.org; >

Re: [Lsr] RtgDir review: draft-ietf-isis-segment-routing-extensions-23

2019-04-15 Thread Les Ginsberg (ginsberg)
Russ - Thanx for the review - and the kind words. Les > -Original Message- > From: 7ri...@gmail.com <7ri...@gmail.com> > Sent: Sunday, April 14, 2019 6:56 PM > To: rtg-...@ietf.org > Cc: rtg-...@ietfr.org; > draft-ietf-isis-segment-routing-extensions@ietf.org; > lsr@ietf.org >

Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

2019-04-15 Thread Adrian Farrel
Hi again. I'm not sure what you are trying to prove (and unclear whether debating a draft that has IETF consensus on the wrong mailing list will solve anything). If you are saying "What happens if an MPLS label gets corrupted in an in-flight packet?" then, yes, packets can be misdelivered."

Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

2019-04-15 Thread Xiejingrong
Hi Adrian, thanks for the remind. I think the use case illustrated in the two diagrams is more attractive and easy to understand. I feel that, the use of dynamic tunnel inside an IGP will cause some other security concerns, as the RFC7510 said: "Corruption of that label could leak traffic

Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

2019-04-15 Thread Adrian Farrel
Wrong list for this discussion, Jingrong. Wrong draft to anchor this discussion to  But anyway, I think you need to read the whole of draft-ietf-mpls-sr-over-ip carefully to see its scope, how it does not compete with SRv6, and how it provides a handy migration strategy. Thanks, Adrian

Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

2019-04-15 Thread Xiejingrong
Hi Adrian, Is the intra-AS SR over IP really a key use case for draft-ietf-mpls-sr-over-ip ? I saw it says for this use case: "Tunneling MPLS into IP provides a technology that enables SR in an IPv4 and/or IPv6 network where the routers do not support SRv6 capabilities ..." SRv6 may have easier

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

2019-04-15 Thread Peter Psenak
Robert, On 15/04/2019 11:21 , Robert Raszuk wrote: Peter, IMO what Olivier has indicated is a practical and operational aspect. The theoretical aspects of protocol operation is what this document is extending. Those are two different things :) And this is not the first time where IETF is

Re: [Lsr] Status of draft-ietf-isis-encapsulation-cap

2019-04-15 Thread bruno.decraene
Hi Adrian, > On the other hand, > https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found > its way onto the RFC Editor Queue at around the same date and has languished > there ever since. The OSPF document progressed well. The decision was made to normatively reference the

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

2019-04-15 Thread Robert Raszuk
Peter, IMO what Olivier has indicated is a practical and operational aspect. The theoretical aspects of protocol operation is what this document is extending. Those are two different things :) And this is not the first time where IETF is manufacturing specs without any serious input from folks

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

2019-04-15 Thread Peter Psenak
Hi Olivier, On 12/04/2019 16:26 , olivier.dug...@orange.com wrote: Hello Peter, Le 12/04/2019 à 15:27, Peter Psenak a écrit : Hi Oliver, There are two major purposes served by the drafts: 1)Support of incongruent topologies for different applications Don't understand. What do you mean ?