Re: [RTG-DIR] RtgDir review: draft-ietf-spring-segment-routing-ldp-interop-11

Ahmed Bashandy <abashandy.ietf@gmail.com> Wed, 13 June 2018 15:07 UTC

Return-Path: <abashandy.ietf@gmail.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 65C1D130E26; Wed, 13 Jun 2018 08:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Sgh1P76v3n1r; Wed, 13 Jun 2018 08:07:29 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D45130E36; Wed, 13 Jun 2018 08:07:29 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id e16-v6so5355249wmd.0; Wed, 13 Jun 2018 08:07:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=4sgvETpk5VKTG+yakTvIQ03L1odm9hUGsmcx2h1DPcg=; b=NfTEoSy1AlPwb56io1YV+lDwCFYqQDLoQQg/i3xs3neN/s0vANeqroFVM3UmNxa4Bv 1ZksHMUvunAwhvBUDeblcKTUfbT+83eTpEZ/iRG4NlGu4Su3ynzZTDR68CMYbpPGelpR HqsPS0VJ0l6QDVL6BkkYnG6GVoWXa7wWb/S2B/wJ+D5ZDXY585PgMUAk852LdGNgVef0 MMjKeSnfrxBRXU3UQcmqHabzcV4+Xe8luIo5FT55n1mmdC06PieOzg1EfEEl1nt6+MSh yFZUz7BsfZ+bQoLhx1K//NCdwqfSgSEdT6eL15OKC3JifW1xwcZCCYf8Vi4uILpqdjE9 HfBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=4sgvETpk5VKTG+yakTvIQ03L1odm9hUGsmcx2h1DPcg=; b=ZvddQl+kasELQ5mca0qNBAKQ0Fb9H/DVpNkLm6hJsaZo91XkbIQ20SOkQjrPLEQyhF r68rumwq7yVh4nALgDuaKjwVVkxvVgZW778It3x0h2bj2BmF3SkjNBfxwo944LGNx3eC WDoEaNr6V85Fgmgp/PwFKDp7SUUW2LdoXXNR+BO5acbDuTD+2OCTSwhnn6lotimoyGQW nPf9tXz8EhML3gsYfYnmNQ9b55WYpEg9M6E0Sy5MgyAcGdUps0ZFuX2uTluRmZTm18OS DCVgbOHpWOzRDBLbVXsQYd4kSoUB/mMFLA1MdDFjF+rQiasm+tcfw72KaZk+/91oFet/ gWgw==
X-Gm-Message-State: APt69E2UZLfqnMZlbyXuY4CVacFepUPJ1Hx4N4ROyQfRqg4EJKZ57MhL rCOzQJ2MHJ3g8dgRK2bTeMc=
X-Google-Smtp-Source: ADUXVKIJjHGaugLaUfvUvaZnVtv9yURGd3cLBKnsKTH7wC6IDu1pcsfPf0NsomflXM7cdCPMCzhQ5g==
X-Received: by 2002:a1c:7153:: with SMTP id m80-v6mr3582230wmc.7.1528902447668; Wed, 13 Jun 2018 08:07:27 -0700 (PDT)
Received: from [192.168.1.33] ([41.236.13.216]) by smtp.gmail.com with ESMTPSA id 12-v6sm5118028wmt.19.2018.06.13.08.07.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 08:07:27 -0700 (PDT)
To: Tomonori Takeda <tomonori.takeda@ntt.com>, "'rtg-ads@ietf.org'" <rtg-ads@ietf.org>
Cc: "'spring@ietf.org'" <spring@ietf.org>, "'rtg-dir@ietf.org'" <rtg-dir@ietf.org>, "'draft-ietf-spring-segment-routing-ldp-interop.all@ietf.org'" <draft-ietf-spring-segment-routing-ldp-interop.all@ietf.org>
References: <TYXPR01MB1677C591FBCB0576D82C7726E8680@TYXPR01MB1677.jpnprd01.prod.outlook.com>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
Message-ID: <e1f89f3b-f4ee-a9ef-bb59-18f2840e2df3@gmail.com>
Date: Wed, 13 Jun 2018 08:07:25 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <TYXPR01MB1677C591FBCB0576D82C7726E8680@TYXPR01MB1677.jpnprd01.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/_YMYYZ5qSn8UwnQdX9FPuZEH0kY>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-spring-segment-routing-ldp-interop-11
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 13 Jun 2018 15:07:33 -0000

Hi

I just published version 13
https://www.ietf.org/internet-drafts/draft-ietf-spring-segment-routing-ldp-interop-13.txt

I moved the section about migration to appendix

Thanks

Ahmed



On 5/26/18 8:47 AM, Tomonori Takeda 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-ietf-spring-segment-routing-ldp-interop-11
>   Reviewer: Tomonori Takeda
>   Review Date: May 26th, 2018
>   IETF LC End Date: Not known
>   Intended Status: Standards Track
>
> Summary:
> This document is basically ready for publication, but has nits that should be considered prior to publication.
>
> Major Issues:
> None
>
> Minor Issues:
> I am a little bit confused about the relationship of SR/LDP interworking and migration from LDP to SR.
>
> The document says:
>   
>     "This document outlines the mechanisms through which SR interworks
>     with LDP in cases where a mix of SR-capable and non-SR-capable
>     routers co- exist within the same network and more precisely in the
>     same routing domain."
>
> My understanding of SR/LDP interworking and migration from LDP to SR is a different story.
> Migration from LDP to SR may or may not use SR/LDP interworking.
>
> Section 3 described migration from LDP to SR, but this migration scenario does not use
> SR/LDP interworking (expect for SR-based FRR usage to protect LDP traffic).
> This migration scenario uses SR/LDP co-existence, though.
>
> Is section 3 for information purpose only?
>
> Nits:
> None
>
>
> Thanks,
> Tomonori Takeda
>