Re: [mpls] [OSPF] Working group last call on draft-ietf-mpls-residence-time

Greg Mirsky <gregimirsky@gmail.com> Tue, 31 January 2017 20:52 UTC

Return-Path: <gregimirsky@gmail.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 36FCD129A75; Tue, 31 Jan 2017 12:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 zNjJR2kMLLis; Tue, 31 Jan 2017 12:52:00 -0800 (PST)
Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (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 96C0812956A; Tue, 31 Jan 2017 12:52:00 -0800 (PST)
Received: by mail-ot0-x241.google.com with SMTP id 73so43157147otj.1; Tue, 31 Jan 2017 12:52:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ISBbqu1oMnPY5Yg9hJO7VfoBmKZ+fRWVNFQStDeznQ=; b=UksXX6vASd36AnNKiuX/NieMFBecaz10jqt4UY3Z6DZbvDX/LtdOAAJK06bi5zVv5b oz5Mr6/+HeJB/SeGNpxeyNSNSmW0V99soVLsXSIqyPB/IDhuyzQJSl5q1e01Pq4ISQsJ a0eMLS8zrXRQ4iLALFd8lKLWeXt8ETnHj1a4hKc6efq8bGf+yhhfXic8vruN4Aec2y2i YGQYWZatTcp0U8v49ryAxSMfrRyc4L+kydtHNj9bOHzw/4ItsrjoAq54Hp41pvtebRF8 zbtisK7SOoXwdSz3Ac6HZsc4V6oMkSCm4VathJegez3hjpCMeDGgOZS2+uyfgI8QKAhe Hp8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1ISBbqu1oMnPY5Yg9hJO7VfoBmKZ+fRWVNFQStDeznQ=; b=USbpVjHn6slSPbIZduYaXFPw7whNx+zUUw0RJRbbUgbnon/o3zkPlfWkR7Vars04Jb 84Zajsls4FmDnkzkVkB7vTlpt4Y5BVNaXYuJj2yBwYrNbjW9wmm/HGhP/Ieb6YpMvnXd CvT8dUE9mKbAsLxpnzr+X9RcCVAdOAiCUjlNKTw01YkMHSRqNZ4Leqbq3dUqM2mEGmr9 8GGAQ+WCycLziK9KLbR8bksU/fCtDJQPKo2IpYadgvX5tNoGo2+7mrDlORP8JttHo42n 6h4rvg7HHIW1BEb+t89tQo+1N0iPjGZnpgKjVk59MUpzsuypSHbuPQ7XYb2+IoSmJaZY zySg==
X-Gm-Message-State: AIkVDXLlKECQd9w+NPqKiCigMMPRHy5MDybT/q3ysHtM8NsiqTTY3CrcTmOizr/7W2Fq/+1T5tAHs6vcHtL60A==
X-Received: by 10.157.43.55 with SMTP id o52mr15760874otb.206.1485895919918; Tue, 31 Jan 2017 12:51:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.1.103 with HTTP; Tue, 31 Jan 2017 12:51:59 -0800 (PST)
In-Reply-To: <25B4902B1192E84696414485F57268540187F922@SJCEML703-CHM.china.huawei.com>
References: <f56d7fa5-8a6a-69fe-2779-9c11e5e85e5b@pi.nu> <d4ba0355c0db469ebbbb896717c5f911@XCH-ALN-001.cisco.com> <CA+RyBmXQxvg9k0f75f72PTGkVtQ0z3TUsMGjb38_E8eKvscX6w@mail.gmail.com> <3fa098bb1ca644e98eee3c470d8c05a4@XCH-ALN-001.cisco.com> <CA+RyBmWZZmHuwy3xWQxRLz5jTLYpvFd-NADfuE_TygVk=JDbYA@mail.gmail.com> <51a1f73605a44fafbab0a293c868bc88@XCH-ALN-001.cisco.com> <CA+RyBmV2OEp_TzSqMxH8pWxBP4sihLoY91fnSZ1eLgcxO35HzA@mail.gmail.com> <2baf22cab3c747498221800e7775fab4@XCH-ALN-001.cisco.com> <25B4902B1192E84696414485F57268540187F922@SJCEML703-CHM.china.huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 31 Jan 2017 12:51:59 -0800
Message-ID: <CA+RyBmUPRH502va-j2ZU5U55g-2iRyfwRoiha5o6Z5uh9wGxXQ@mail.gmail.com>
To: Uma Chunduri <uma.chunduri@huawei.com>
Content-Type: multipart/alternative; boundary="001a113ef06a7ae53005476a1abd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/LWB7i2pao51mD1XG1uHo72O3eeU>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, Isis-wg <isis-wg-bounces@ietf.org>, "draft-ietf-mpls-residence-time@tools.ietf.org" <draft-ietf-mpls-residence-time@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, TEAS WG <teas@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>
Subject: Re: [mpls] [OSPF] Working group last call on draft-ietf-mpls-residence-time
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 31 Jan 2017 20:52:04 -0000

Hi Uma,
great catch and astute observation, thank you!
I think that making RTM Capabilities space in IS-IS extendable beyond
remaining 13 bit-long space is prudent. But now, as you've pointed out,
need to reconcile formats. I'd prefer to take option 1, i.e. use variable
length Value field in RTM Capabilities sub-TLV for OSPFv2. Acee, would that
be acceptable?

Regards,
Greg

On Tue, Jan 31, 2017 at 10:22 AM, Uma Chunduri <uma.chunduri@huawei.com>
wrote:

> Had a quick look at this diff.
>
>
>
> This is about unifying the encoding parts in IGP to have a consistent view
> for BGP-LS encoding or keeping these separate and yet having a correct
> representation in BGP-LS for both IGPs.
>
>
>
> ==
>
> With variable length bit field for Section 4.5 and fixed 4 byte value (as
> indicated as MUST  for length) in section 4.3  - I saw a discrepancy  in
> section 4.6 (BGP-LS) which is referencing section 4.3.
>
>
>
> You have multiple options to fix this:
>
>
>
> 1.       Change section 4.3 to match section 4.5 (I am not sure why we
> have to have variable length for this bit field to start with in this case
> like rfc 7794…but I won’t say much now)
>
> 2.       Change Section 4.6 to represent differences in encoding section
> 4.5 and 4.3 correctly.
>
> “Length, RTM, and Reserved fields as defined in Section 4.3.”
>
>    3. Lastly unify section 4.5 to 4.3  i.e., 4 byte value with 3 bits
> defined and 29 bits reserved.
>
> --
>
> Uma C.
>
>
>
> *From:* mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Les Ginsberg
> (ginsberg)
> *Sent:* Tuesday, January 31, 2017 8:22 AM
> *To:* Greg Mirsky <gregimirsky@gmail.com>
> *Cc:* mpls@ietf.org; isis-chairs@ietf.org; Isis-wg <
> isis-wg-bounces@ietf.org>; draft-ietf-mpls-residence-time@tools.ietf.org;
> TEAS WG Chairs <teas-chairs@ietf.org>; mpls-chairs@ietf.org; TEAS WG <
> teas@ietf.org>; ospf@ietf.org; ospf-chairs@ietf.org
> *Subject:* Re: [mpls] [OSPF] Working group last call on
> draft-ietf-mpls-residence-time
>
>
>
> Greg –
>
>
>
> Looks good.
>
>
>
>    Les
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com <gregimirsky@gmail.com>]
>
> *Sent:* Tuesday, January 31, 2017 8:06 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Loa Andersson; mpls@ietf.org; TEAS WG; ospf@ietf.org; Isis-wg;
> ospf-chairs@ietf.org; draft-ietf-mpls-residence-time@tools.ietf.org; TEAS
> WG Chairs; isis-chairs@ietf.org; mpls-chairs@ietf.org
> *Subject:* Re: [OSPF] Working group last call on
> draft-ietf-mpls-residence-time
>
>
>
> Hi Les,
>
> thank you for your patience and apologies for missing it.
>
> Diff and the update been attached.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jan 31, 2017 at 5:07 AM, Les Ginsberg (ginsberg) <
> ginsberg@cisco.com> wrote:
>
> Greg –
>
>
>
> Almost…
>
>
>
> Please change the title of Section 7.5 to “IS-IS RTM Capability sub-TLV”.
>
>
>
> Please change the title of Table 5 to “IS-IS RTM Capability sub-TLV
> Registry Description”.
>
>
>
> The common point being since this is not exclusively for TLV 22 we do not
> want to say “for TLV 22”.
>
> Thanx.
>
>
>
>     Les
>
>
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Monday, January 30, 2017 11:43 PM
>
>
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Loa Andersson; mpls@ietf.org; TEAS WG; ospf@ietf.org; Isis-wg;
> ospf-chairs@ietf.org; draft-ietf-mpls-residence-time@tools.ietf.org; TEAS
> WG Chairs; isis-chairs@ietf.org; mpls-chairs@ietf.org
> *Subject:* Re: [OSPF] Working group last call on
> draft-ietf-mpls-residence-time
>
>
>
> Hi Les,
>
> many thanks for your the most detailed suggestions. Hope I've it right.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jan 30, 2017 at 11:04 PM, Les Ginsberg (ginsberg) <
> ginsberg@cisco.com> wrote:
>
> Greg –
>
>
>
> Thanx for the quick turnaround.
>
>
>
> Section 4.5 (revised text)
>
>
>
>    The capability to support RTM on a particular link (interface) is
>
>    advertised in a new sub-TLV which may be included in TLVs advertising
>
>    Intemediate System (IS) Reachability on a specific link (TLVs 22, 23,
> 222, and 223).
>
>
>
>    The format for the RTM Capabilities sub-TLV is presented in Figure 5
>
>
>
>      0                   1                   2
>
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>
>     |      Type     |     Length    | RTM |              ...
>
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
>
>
>
>    Figure 5: RTM Capability sub-TLV
>
>
>
> … (Remainder unchanged)
>
>
>
> Section 7.5 (revised text)
>
>
>
> 7.5.  IS-IS RTM Capability sub-TLV
>
>
>
>    IANA is requested to assign a new Type for RTM capability sub-TLV
>
>    from the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry as
>
>    follows:
>
>
>
>     +------+-------------+----+----+-----+-----+-----+---------------+
>
>     | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference     |
>
>     +------+-------------+----+----+-----+-----+-----+---------------+
>
>     | TBA3 |     RTM      | y  | y  | n   | y   | y   | This document |
>
>     |           | Capability |      |     |      |       |
> |                                |
>
>     +------+-------------+----+----+-----+-----+-----+---------------+
>
>
>
>              Table 5: IS-IS RTM Capability sub-TLV Registry Description
>
>
>
>
>
> Thanx.
>
>
>
>     Les
>
>
>
> *From:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *Sent:* Monday, January 30, 2017 10:36 PM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* Loa Andersson; mpls@ietf.org; TEAS WG; ospf@ietf.org; Isis-wg;
> ospf-chairs@ietf.org; draft-ietf-mpls-residence-time@tools.ietf.org; TEAS
> WG Chairs; isis-chairs@ietf.org; mpls-chairs@ietf.org
> *Subject:* Re: [OSPF] Working group last call on
> draft-ietf-mpls-residence-time
>
>
>
> Hi Les,
>
> attached are diff and the updated version -14. Would be much obliged to
> hear from you if the updates are according to your suggestions and address
> your comments.
>
>
>
> Kind regards,
>
> Greg
>
>
>
>
>
> On Mon, Jan 30, 2017 at 1:11 PM, Les Ginsberg (ginsberg) <
> ginsberg@cisco.com> wrote:
>
> Loa -
>
>
>
> The change for IS-IS encoding to utilize a sub-TLV of TLV 22 et al to
> advertise RTM capability is a better solution than the previous proposal
> and this has my support.
>
> However, there are some details as regards the proposed sub-TLV that
> should be revised.
>
>
>
> 1)Rather than use a fixed 16 bit field for the flags I suggest you utilize
> the encoding style introduced in RFC 7794 (see Section 2.1) which allows
> for a variable length flags field. This addresses two issues:
>
>
>
>    o You need never worry that the size of the flags field will be too
> small for future extensions
>
>    o It minimizes the number of bytes required to be sent
>
>
>
> The latter point is something IS-IS has always been more conservative
> about than OSPF because of the fixed size of an LSP set which can be
> advertised by a single router.
>
>
>
> 2)In the IANA considerations you have limited the sub-TLV to being used in
> TLV 22 only, but there is no reason to do so. This does not allow MT to be
> supported and it needlessly prevents use of the sub-TLV by the RFC 5311
> extensions (however unpopular those may be). I can understand why the
> sub-TLV may not be useful in TLV 141, therefore I suggest the table in
> Section 7.5 be revised to be:
>
>
>
>
>
>     | Type | Description | 22 | 23 | 141 | 222 | 223 | Reference
> |
>
>    +------+-------------+----+----+-----+-----+-----+---------------+
>
>   | TBA3 |    RTM       | y  | y  | n   | y   | y   | This document
> |
>
>     +------+-------------+----+----+-----+-----+-----+---------------+
>
>
>
>
> i.e. "y" for all but TLV 141 (in case the ASCII art doesn't translate well
> in your mailer).
>
>
>
> You should also remove the reference to RFC 5305 in Section 4.5 as it is
> too limiting. Simply referencing the IANA registry http://www.iana.org/
> assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-
> codepoints-22-23-141-222-223 should be sufficient. All necessary
> references can be found there.
>
>
>
> 3)An editorial correction:
>
>
>
> Introduction 3rd paragraph:
>
>
>
> s/ Althugh/ Although
>
>
>
>    Les
>
>
>
> > -----Original Message-----
>
> > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Loa Andersson
>
> > Sent: Monday, January 30, 2017 8:02 AM
>
> > To: mpls@ietf.org; TEAS WG; ospf@ietf.org; Isis-wg
>
> > Cc: isis-chairs@ietf.org; draft-ietf-mpls-residence-time@tools.ietf.org;
> TEAS
>
> > WG Chairs; mpls-chairs@ietf.org; ospf-chairs@ietf.org
>
> > Subject: [OSPF] Working group last call on draft-ietf-mpls-residence-time
>
> >
>
> > Working Groups,
>
> >
>
> > This is to initiate a two week working group last call in four working
> groups on
>
> > draft-ietf-mpls-residence-time-13.
>
> >
>
> > The MPLS working group has done an earlier working group last call and a
>
> > request for publication has been made.
>
> >
>
> > The changes to the document were such that we decided to do a new
>
> > working group last call and extend it to MPLS, TEAS, OSPF and IS-IS.
>
> >
>
> > There are three major changes between the version of the document for
>
> > which publication was requested are:
>
> >
>
> > (1) that section 7 " One-step Clock and Two-step Clock Modes" has been
>
> >      moved up to become section 2.1.
>
> > (2) that a sub-TLV for TLV 22 instead of TLV 251 is used to RTM
>
> >      Capability when IS-IS used advertise RTM capabilities
>
> > (3) BGP-LS has been added as a RTM capability advertisement method
>
> >
>
> > A side-by-side diff between version -12 and -13 is available at:
>
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-residence-time-13
>
> >
>
> > Please send your comments to the mpls wg mailing list (mpls@ietf.org),
> if
>
> > you are not subscribed to the mpls wg list, send to "your own"
>
> > working group mailing list, and we'll make sure they are posted to the
> MPLS
>
> > wg list.
>
> >
>
> > There were one IPR disclosure against this document.
>
> >
>
> > All the authors and contributors have stated on the working group
> mailing list
>
> > that they are not aware of any other IPRs that relates to this document.
>
> >
>
> > This working group last call ends February 13, 2017.
>
> >
>
> >
>
> > /Loa
>
> > MPLS wg co-chairs
>
> > --
>
> >
>
> >
>
> > Loa Andersson                        email: loa@mail01.huawei.com
>
> > Senior MPLS Expert                          loa@pi.nu
>
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
> >
>
> > _______________________________________________
>
> > OSPF mailing list
>
> > OSPF@ietf.org
>
> > https://www.ietf.org/mailman/listinfo/ospf
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>
>
>
>
>
>