Re: [RTG-DIR] RtgDir review: draft-smirnov-ospf-xaf-te

Anton Smirnov <asmirnov@cisco.com> Tue, 24 May 2016 14:51 UTC

Return-Path: <asmirnov@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629EB12D85C; Tue, 24 May 2016 07:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.948
X-Spam-Level:
X-Spam-Status: No, score=-15.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 P9_SLCi3lB_k; Tue, 24 May 2016 07:51:36 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D626F12D867; Tue, 24 May 2016 07:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27408; q=dns/txt; s=iport; t=1464101492; x=1465311092; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=QdxorxvFsFk9U7m5UJeYie3jCA1OQNzWgq2T/z7Ul+Y=; b=YSHNc1qxkx82GvyGgevYclIkQ24fEeU7V/JI4iPPu3uOyay1B7Kc3l3v HCOeQ1b1x8FNGqRwUKtmHuBAnV7Ke04WvsJdD2bUFOB5unFDvsuZdvtkq AO42NqQ+qN+wkwQ+OCIkADVxrOhABoFwDnaVg00YoZZO5+37kb7+zgDVc o=;
X-Files: draft-smirnov-ospf-xaf-te-06a.txt : 17080
X-IronPort-AV: E=Sophos;i="5.26,360,1459814400"; d="txt'?scan'208";a="677344285"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2016 14:51:30 +0000
Received: from as-lnx.cisco.com (ams-asmirnov-nitro5.cisco.com [10.55.206.134]) (authenticated bits=0) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4OEpTLP014912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2016 14:51:29 GMT
Message-ID: <57446A6C.6020603@cisco.com>
Date: Tue, 24 May 2016 16:51:24 +0200
From: Anton Smirnov <asmirnov@cisco.com>
Organization: Cisco Systems
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: IJsbrand Wijnands <ice@cisco.com>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
References: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com>
In-Reply-To: <887E0412-D057-4404-ACED-69F7B162AEC5@cisco.com>
Content-Type: multipart/mixed; boundary="------------030009060800060304040704"
X-Authenticated-User: asmirnov
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/WwLPhLFuMVlL0GUUL43B3LxHuOo>
Cc: rtg-dir@ietf.org, draft-smirnov-ospf-xaf-te@ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-smirnov-ospf-xaf-te
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2016 14:51:39 -0000

    Hi Ice,
    thanks for your review comments. Please find updated text attached 
to this email. If changes are OK then I will publish them in a new revision.

 > Does this also solve the use-case for P2MP TE LSPs?
 > If it does, maybe its good to mention this. I do think it has
 > consequences as it requires an IPv4/IPv6 explicit NULL label, if you
 > want to share IPv4 and IPv6 traffic over the same P2MP LSP.

    The method described in this document can be used to compute 
cross-AF mapping of egress LSR for sub-LSPs of a P2MP LSP. I've added a 
sentence mentioning this.
    The document concentrates on path computation aspects specific to
OSPF. Data plane considerations are not specific to OSPF, so I don't 
think this document is a good place to have a text about how to forward 
cross-AF traffic thru P2MP LSP.


 > Section 3. "For example, suppose the OSPFv2 instance …”
 >
 > This paragraph could benefit from a rewrite as I find it hard to
 > follow what the intention is. I would also advise not to use real IP
 > addresses as an example since the actual value does not matter.
 > Better to say IPv4_1, IPv4_2,.. IMO.

    I rewrote the paragraph. Hopefully the text is clearer now.
    Having in the example IP addresses from the documentation range is 
very explicit in showing what information is put into TLVs. So I left in 
the text IP addresses but reduced their number from 3 to 2. I hope this 
also will make the example more straightforward to follow.


 > The acronym “ASON” is used in this document, but it is not spelled
 > out what it stands for.

    Fixed.

Anton


On 05/20/2016 02:31 PM, IJsbrand Wijnands wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
>
> Document: draft-smirnov-ospf-xaf-te
> Reviewer: IJsbrand Wijnands
> Review Date: 20-05-2016
> Intended Status: Standards Track
>
> Summary:
>
> This document is basically ready for publication, but has nits that should be considered prior to publication.
>
> Comments:
>
> This document is well written and the use-case is very clear and useful to solve. Does this also solve the use-case for P2MP TE LSPs? If it does, maybe its good to mention this. I do think it has consequences as it requires an IPv4/IPv6 explicit NULL label, if you want to share IPv4 and IPv6 traffic over the same P2MP LSP.
>
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
>
> Section 3.
> "For example, suppose the OSPFv2 instance …”
>
> This paragraph could benefit from a rewrite as I find it hard to follow what the intention is. I would also advise not to use real IP addresses as an example since the actual value does not matter. Better to say IPv4_1, IPv4_2,.. IMO.
>
> Nits:
>
> The acronym “ASON” is used in this document, but it is not spelled out what it stands for.
>
> Thx,
>
> Ice.
>