Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 28 February 2019 11:18 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F63130E7E for <lsr@ietfa.amsl.com>; Thu, 28 Feb 2019 03:18:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZHIfdHM_w3R for <lsr@ietfa.amsl.com>; Thu, 28 Feb 2019 03:18:41 -0800 (PST)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id E07B9128BCC for <lsr@ietf.org>; Thu, 28 Feb 2019 03:18:40 -0800 (PST)
Received: from [240.0.0.1] (unknown [81.90.189.30]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id CEFEF662420; Thu, 28 Feb 2019 19:18:30 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-19710BB2-AED1-42EC-8524-9FC8B7F0CFF0"
Mime-Version: 1.0 (1.0)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <06CF729DA0D6854E8C1E5121AC3330DFADDD8036@dggemm509-mbx.china.huawei.com>
Date: Thu, 28 Feb 2019 19:18:21 +0800
Cc: "lsr@ietf.org" <lsr@ietf.org>, "acee@cisco.com" <acee@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <91C8D487-C0CF-4A7E-85EF-DBE7CD7FA407@tsinghua.org.cn>
References: <201902271636111453989@zte.com.cn> <06CF729DA0D6854E8C1E5121AC3330DFADDD8036@dggemm509-mbx.china.huawei.com>
To: peng.shaofu@zte.com.cn
X-HM-Spam-Status: e1kIGBQJHllBS1VLV1koWUFKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZMjUtOj cyP0FLVUtZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NAw6Nww4SDkMGCIrTQ03LhhR PTkKCTJVSlVKTk5KSE5JTEpDSEJPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlDSlVCS1VKQ0JVSEtZV1kIAVlBSk9PS083Bg++
X-HM-Tid: 0a6933d3c6c19373kuwscefef662420
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/C3qgKKU949YB7NLH-FTKJaFV7i8>
Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 11:18:44 -0000

Hi, Shaofu:

Thanks for your comments.
The topology retrieval process described in this draft can work for your scenario because the multiple links between two nodes have different prefixes.
The TE task on these links is another topic, we have some solutions considerations on it but not reflected in current draft.
Wish the above explanation can eliminate your worrying points on this draft.

Best Regards.

Aijun Wang
China Telecom
>  
> From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of peng.shaofu@zte.com.cn
> Sent: Wednesday, February 27, 2019 4:36 PM
> To: acee@cisco.com
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Working Group Adoption Poll for "OSPF Extension for PrefixOriginator" - draft-wang-lsr-ospf-prefix-originator-ext-01
>  
> 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) <acee@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