Hi guys,
I think that there’s some confusion here.
> 1) The alternate backup path would appear to also require the criteria
> of being link diverse with the FT if the goal is to protect against multiple
> failures.
>
> [HC]: Can you give some more details about this?
I think that
For the record;
Also there is a an encapsulation capability TLV in ITU-T G.7712
here
https://www.itu.int/rec/dologin_pub.asp?lang=e=T-REC-G.7712-201009-I!!PDF-E=items
see appendix B.
also described here
https://tools.ietf.org/html/draft-ietf-isis-auto-encap-03
regards, Philip
On 13/04/2019
Thanks Xiaohu,
That at least indicates that you would like to see an RFC published.
But I wonder whether the WG has given up on this work? Two years is a long time
to make no advances and to have no demands for publication.
I wonder why no one has cared in the interim.
Best,
Adrian
Hi Huaimo,
> 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
I will update the ISIS draft soon.
Xiaohu
来自钉钉专属商务邮箱--
发件人：Adrian Farrel
日 期：2019年04月13日 23:59:05
收件人：
主 题：[Lsr] Status of draft-ietf-isis-encapsulation-cap
Hi,
Any clues?
Hi Dave,
Thank you for your observations.
My explanations are inline below with prefix [HC].
>From: David Allan I [mailto:david.i.al...@ericsson.com]
>Sent: Friday, April 12, 2019 8:57 AM
>To: Huaimo Chen ; tony...@tony.li
>Cc: lsr@ietf.org
>Subject: RE: [Lsr] Min Links for Multiple Failures on
Hi Sarah,
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. Enabling temporary flooding on a link
Olivier –
As Jeff has indicated in his reply, the use cases and issues around these
protocol extensions have been discussed extensively on the WG lists (including
of course the now subsumed OSPS/IS-IS WG lists) and were the subject of many
presentations at many IETFs. The history of these
