Re: [mpls] Opsdir last call review of draft-ietf-mpls-sr-over-ip-02

"MORTON, ALFRED C (AL)" <acm@research.att.com> Sun, 17 February 2019 13:46 UTC

Return-Path: <acm@research.att.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA311295EC; Sun, 17 Feb 2019 05:46:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 sVOSS88VZ11j; Sun, 17 Feb 2019 05:46:57 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1ED1293B1; Sun, 17 Feb 2019 05:46:57 -0800 (PST)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x1HDjV6P018814; Sun, 17 Feb 2019 08:46:57 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0048589.ppops.net-00191d01. with ESMTP id 2qpsqxenbd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 Feb 2019 08:46:56 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDktep053990; Sun, 17 Feb 2019 07:46:55 -0600
Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [135.46.181.156]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDkqg9053961; Sun, 17 Feb 2019 07:46:52 -0600
Received: from zlp30497.vci.att.com (zlp30497.vci.att.com [127.0.0.1]) by zlp30497.vci.att.com (Service) with ESMTP id 1F0E340141FF; Sun, 17 Feb 2019 13:46:52 +0000 (GMT)
Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30497.vci.att.com (Service) with ESMTP id F2B1840141F8; Sun, 17 Feb 2019 13:46:51 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDkpeH010472; Sun, 17 Feb 2019 07:46:51 -0600
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x1HDkhnD010020; Sun, 17 Feb 2019 07:46:43 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id D53FFE40DB; Sun, 17 Feb 2019 08:46:10 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0439.000; Sun, 17 Feb 2019 08:46:42 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "mpls@ietf.org" <mpls@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-mpls-sr-over-ip.all@ietf.org" <draft-ietf-mpls-sr-over-ip.all@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-mpls-sr-over-ip-02
Thread-Index: AQHUxrKxZBFm/1ktuk++wNABClUm86XkALAA
Date: Sun, 17 Feb 2019 13:46:19 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF6BFF80C5@njmtexg5.research.att.com>
References: <155035125470.28448.13188042604940095760@ietfa.amsl.com> <00ef01d4c6b2$98102420$c8306c60$@olddog.co.uk>
In-Reply-To: <00ef01d4c6b2$98102420$c8306c60$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [69.141.203.172]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-17_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1902170108
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/MXZ6ASxSoySKdLx4UfSFTdNpdMs>
Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sr-over-ip-02
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2019 13:47:00 -0000

Thanks Adrian.

@OPS-DIR - consider these comments resolved.

Al

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Sunday, February 17, 2019 6:19 AM
> To: MORTON, ALFRED C (AL) <acm@research.att.com>;; ops-dir@ietf.org
> Cc: mpls@ietf.org; ietf@ietf.org; draft-ietf-mpls-sr-over-ip.all@ietf.org
> Subject: RE: Opsdir last call review of draft-ietf-mpls-sr-over-ip-02
> 
> Hi Al,
> 
> Thanks very much for reviewing.
> 
> Responses in line.
> 
> > Thanks for preparing this draft.
> > Providing transition methods is very welcome to
> > Operations.
> 
> We aim to please 😊
> 
> > There seem to be a few more opportunities to employ
> > Requirements Language in this draft (currently only
> > 3 MUSTs and 2 MAYs), to improve the consistency of
> > implementations and subsequent adoption in operations.
> 
> You are right.
> The original vision for this document was Informational (telling you how
> to use existing tools), so the Requirements language only crept in as we
> moved to Standards Track, and we should probably have more of it.
> 
> > For example:
> > Section 2:
> >   o  Incremental deployment of the SR-MPLS technology may be
> >      facilitated by tunneling SR-MPLS packets across parts of a network
> >      that are not SR-MPLS enabled using an IP tunneling mechanism such
> >      as MPLS-in-UDP [RFC7510].  The tunnel destination address is the
> >	                                                           ^^^^
> >      address of the next SR-MPLS capable node along the path (i.e., the
> >      egress of the active node segment).  This is shown in Figure 1.
> >
> > Setting the Dst address correctly seems to be a requirement,
> > because this material in Section 2 is referenced later, in 3.2.3.
> > This seems a reasonable spot for s/is/SHOULD be/ at least.
> 
> Well, in this specific case I'm going to agree with you, but for a
> different reason. You don't set a destination address, you pick a tunnel
> that has an end point.
> 
> So we should probably write...
> OLD
>       The tunnel destination address is the
>       address of the next SR-MPLS capable node along the path (i.e., the
>       egress of the active node segment).
> NEW
>       The tunnel selected MUST have its remote end point (destination)
>       Address equal to the address of the next SR-MPLS capable node
>       along the path (i.e., the egress of the active node segment).
> END
> 
> > Section 3.1 FIB construction relies on about 5 drafts:
> > much work in progress, just noting dependencies (no action)
> 
> Yes, it is sad for me that the SR work still lingers in the pipe.
> 
> > SRGB - ?? spell-out at first use
> 
> Good catch.
> Segment Routing Global Block
> 
> > Section 3.2.3. Additional Forwarding Procedures
> >....
> >      IP Header Fields:  When encapsulating an MPLS packet in UDP, the
> >      resulting packet is further encapsulated in IP for transmission.
> >      IPv4 or IPv6 may be used according to the capabilities of the
> >      network.  The address fields are set as described in Section 2.
> >	                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >      The other IP header fields (such as DSCP code point, or IPv6 Flow
> >      Label) on each UDP-encapsulated segment can be set according to
> >	                                          ^^^^^^^^^^
> >      the operator's policy:
> >Suggest:
> > s/can be set/SHOULD be configurable/
> 
> Yes