Support, as this draft provide useful originial source router-id of prefix, as
the same as RFC7794.
For topology deducing, it seems too hard to work according to current
description in the document. For example, It is hard to represent mulptile
links between two nodes if we only know two node-id information but lack of
interface IP address or interface-id that is link attribute not be included in
prefix flooding, thus there is no way to consider which link could be contained
in which TE path, also, so many TE parameters of link need to be supplied for
the deducing topology, TE metric, bandwidth, etc. Maybe there already have a
complete solution but just not describe detailedly in document.
Thanks
Deccan(Shaofu peng)
原始邮件
发件人：AceeLindem(acee) <a...@cisco.com>
收件人：lsr@ietf.org <lsr@ietf.org>;
日 期 ：2019年02月13日 21:26
主 题 ：[Lsr] Working Group Adoption Poll for "OSPF Extension for
PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
This begins a two week adoption poll for the subject draft. Please send your
comments to this list before 12:00 AM UTC on Thursday, February 28th, 2019.
All authors have responded to the IPR poll and there is one
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-wang-lsr-ospf-prefix-originator-ext
It is listed multiple times but references the same CN201810650141.
Thanks,
Acee
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
