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
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
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 ?
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
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
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."
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
>
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.
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
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
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
(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;
>
12 matches
Mail list logo
