Re: [mpls] draft-smack-mpls-rfc4379bis

[David Allan I <[e-mail]>]

HI Kireeti:

<snipped>

> I've read it though and will state up front, that as a next step in the standards process (bis version), I'm applying a tougher standard to the document and looking at this as more of a "last call". Even more so as it is OAM and therefore IMO requires a high degree of interoperability to be useful. As pretty much all of this is from the original document and outside the scope of what has been proposed (errata incorporation etc.) and likely just complicates life, you can take it with "a grain of salt”.

First of all, thanks, Dave, for doing the review and reading the doc so carefully!

Well I was a bit surprised to find the original RFC and a to do list after looking the document over. But that’s fine ☺, gotta start somewhere.

Will do :-)

>
> My chief concern with the document is that the language is very non specific and vague, and what I would expect to say "this is..." typically says "this might...".  I appreciate that much of this originates with the original RFC 4379, but for a BIS I would expect it to be cleaned up.
>
> Some examples:
> "An MPLS echo request with 1 (Do not reply) in the Reply Mode field  may be used for one-way connectivity tests;". IMO it is not a "may be", it "is" used for one way connectivity tests. If there is no reply, what else are you going to do.

As Carlos says, grain of salt applied.  Being prescriptive here doesn't make sense (imo) -- an echo request with "Do not reply" could be used for one-way connectivity tests or some other really cool, innovative reason that we haven't thought of yet.  This doesn't affect interoperability; using "It is" limits the use.  Note lower case "may", not MAY.

My point would be if someone thinks of an innovative use and keeps it to themselves, fine. Meanwhile, from the POV of interoperability and design of support systems, it is probably more useful to describe what it “is” used for, not to allude to some as of yet unimagined future, and if some interesting use appears in the future and we had reason to expose it to improve the network, presumably we would document it.

> "Sub-TLVs have  independent types and MUST also be 4-octet aligned. Two examples follow."  The examples would appear to be a normative definition of the ONLY sub-TLVs that are defined in this I-D. Other RFCs (e.g. VCCV) may define more, but these are the ones defined here, they are NOT examples.

I read the two examples as examples of how sub-TLVs are to be padded to be 4-octet aligned (it helps that Carlos (or someone) fixed the wrong TLV length in the example :)).

Would the following read better?

An example of how TLV and sub-TLV lengths are computed, and of how sub-TLVs are padded follows.

Irrespective of the fact my critique of this was off base, the proposed rewording is much better.

> And finally....
> I'm hoping I'm reading this incorrectly, but assuming my read IS correct, It is obviously far far too late to change it but the FEC stack would have been easier to use if it listed the FECs from BOS to TOS, and not TOS to BOS as it is described now.  An intermediate LSR would need to count from BOS backwards given the depth of the current stack would be arbitrary at any intermediate LSR. Should have caught that years ago….

Grain-of-salt applied — these all sound all good discussion points for the wg to ponder, after adoption, since they “might” significantly change meaning.

Can't change this now, certainly not as a bis RFC.

I gathered that. Like I said, wished I had read it more carefully first time around ☺

But certainly I agree with going over the potentially ambiguous or vague language and tidying that up, after adoption, as needed, based on deployment experience.

Agree.

>

> All of this being said, I have no idea what leeway in an IETF bis that one has to fix editorial and style issues. Meanwhile I do consider correcting the references and applying all errata to be a useful step.

Thanks!

Indeed, thanks!

My pleasure
Dave


— Carlos.

>
> Cheers
> Dave
>
>
>
>
>
> -----Original Message-----
> From: David Allan I
> Sent: Monday, November 30, 2015 10:23 AM
> To: '[e-mail]<mailto:[e-mail]>'; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: RE:
>
> I had not seen the original either, thanks Curtis for spotting this.
>
> I'll confirm that I'll give the draft a read...
>
> Cheers
> Dave
>
> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Sunday, November 29, 2015 11:05 AM
> To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; David Allan I
> Cc: [e-mail]<mailto:[e-mail]>
> Subject:
>
> Hi Loa, Yimin, Dave,
>
> The email below made it to all the IETF mailing lists since they have
> IPv6 connectivity.  My host msa1 lost IPv4 for a while (config error on my part) so mail bounced to you guys with IPv4 connectivity only.
>
> Unless you already got this by way of one or more IETF mailing list.
> Sorry for the inconvenience if you already got a copy.
>
> Curtis
>
> ps - maybe time to ask your IT people about IPv6 connectivity.  While you are at it mention DNSSEC (you can mention http://dnssec-debugger.verisignlabs.com/pi.nu
> http://dnssec-debugger.verisignlabs.com/juniper.net
> http://dnssec-debugger.verisignlabs.com/ericsson.com
> as a way to tell whether DNSSEC is working for your domain.  Us IETFers are supposed to be leading in deployment of our own stuff.)
>
> ------- Forwarded Message
>
> Return-Path: <>
> X-Original-To: curtis
> Delivered-To: [e-mail]<mailto:[e-mail]>
> Received: by harbor2.v6only.occnc.com<http://harbor2.v6only.occnc.com> (Postfix, from userid 100)
>       id E74063A1B0; Sun, 29 Nov 2015 12:46:26 -0500 (EST)
> Received: from mda23-em2.v6only.occnc.com<http://mda23-em2.v6only.occnc.com> [2001:470:88e6:2::247]
>       by harbor2.v6only.occnc.com<http://harbor2.v6only.occnc.com> with IMAP (fetchmail-6.3.26)
>       for <curtis@localhost> (single-drop); Sun, 29 Nov 2015 12:46:26 -0500 (EST)
> Received: from mda23.v6only.occnc.com<http://mda23.v6only.occnc.com> ([unix socket])
>        by mda23.v6only.occnc.com<http://mda23.v6only.occnc.com> (Cyrus 2.5.6) with LMTPA;
>        Sat, 28 Nov 2015 23:41:55 -0500
> X-Sieve: CMU Sieve 2.4
> Received: from mta1.orleans.occnc.com<http://mta1.orleans.occnc.com> (mta1-em1.orleans.occnc.com<http://mta1-em1.orleans.occnc.com> [IPv6:2001:470:88e6:1::141])
>       (using TLSv1 with cipher ECDHE-ECDSA-AES256-SHA (256/256 bits))
>       (Client CN "mta1.orleans.occnc.com<http://mta1.orleans.occnc.com>", Issuer "" (verified OK))
>       (Authenticated sender: [e-mail]<mailto:[e-mail]>)
>       by mda23.v6only.occnc.com<http://mda23.v6only.occnc.com> (Postfix) with ESMTPSA id A8602B71A
>       for <[e-mail]<mailto:[e-mail]>>; Sat, 28 Nov 2015 23:40:52 -0500 (EST)
> Received: from msa1.orleans.occnc.com<http://msa1.orleans.occnc.com> (msa1-em1.orleans.occnc.com<http://msa1-em1.orleans.occnc.com> [IPv6:2001:470:88e6:1::140])
>       (using TLSv1 with cipher ECDHE-ECDSA-AES256-SHA (256/256 bits))
>       (Client CN "msa1.orleans.occnc.com<http://msa1.orleans.occnc.com>", Issuer "" (verified OK))
>       (Authenticated sender: [e-mail]<mailto:[e-mail]>)
>       by mta1.orleans.occnc.com<http://mta1.orleans.occnc.com> (Postfix) with ESMTPSA id 0C35AA8AE
>       for <[e-mail]<mailto:[e-mail]>>; Sat, 28 Nov 2015 23:39:41 -0500 (EST)
> Received: by msa1.orleans.occnc.com<http://msa1.orleans.occnc.com> (Postfix)
>       id 05CD881BB; Sat, 28 Nov 2015 23:39:37 -0500 (EST)
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orleans.occnc.com<http://orleans.occnc.com>;
>       s=orleans; t=1448771978;
>       bh=J/kyAMTjPkigB948kzMx3YBPrrnHlQNeR0px6Xl4em0=;
>       h=Date:From:Subject:To;
>       b=oA63DSwLokSCUGQ897dS4xiqkCFjfegEVoAgyS9AbHaKV3xR7vl/oO05DkLJHknhR
>        VS3RNKxqehLHf9OM5tMHKsqJNBfTSzeMQBZ++7m+zHevhnQc/Vs/W9tBftziP4JQwn
>        k7DXwGSzltkC+N09o2y7YrzLRiwi8UM4MtOOWNvw=
> Date: Sat, 28 Nov 2015 23:39:37 -0500 (EST)
> From: [e-mail]<mailto:[e-mail]> (Mail Delivery System)
> Subject: Undelivered Mail Returned to Sender
> To: [e-mail]<mailto:[e-mail]>
> Auto-Submitted: auto-replied
> MIME-Version: 1.0
> Content-Type: multipart/report; report-type=delivery-status;
>       boundary="703F28329.1448771977/msa1.orleans.occnc.com<http://msa1.orleans.occnc.com>"
> Message-Id: <[e-mail]<mailto:[e-mail]>>
> X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,T_DKIM_INVALID,
>       UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1
> X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on oink2.v6ds.occnc.com<http://oink2.v6ds.occnc.com>
>
> This is a MIME-encapsulated message.
>
> - --703F28329.1448771977/msa1.orleans.occnc.com<http://msa1.orleans.occnc.com>
> Content-Description: Notification
> Content-Type: text/plain; charset=us-ascii
>
> This is the mail system at host msa1.orleans.occnc.com<http://msa1.orleans.occnc.com>.
>
> I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can delete your own text from the attached returned message.
>
>                   The mail system
>
> <[e-mail]<mailto:[e-mail]>>: connect to pipi.pi.nu<http://pipi.pi.nu>[83.168.239.141]:25: No route to host
>
> <[e-mail]<mailto:[e-mail]>>: connect to
>    juniper-net.mail.eo.outlook.com<http://juniper-net.mail.eo.outlook.com>[207.46.163.170]:25: No route to host
>
> <[e-mail]<mailto:[e-mail]>>: connect to
>    sesbmg13.ericsson.net<http://sesbmg13.ericsson.net>[193.180.251.49<tel:%5B193.180.251.49>]:25: No route to host
>
> - --703F28329.1448771977/msa1.orleans.occnc.com<http://msa1.orleans.occnc.com>
> Content-Description: Delivery report
> Content-Type: message/delivery-status
>
> Reporting-MTA: dns; msa1.orleans.occnc.com<http://msa1.orleans.occnc.com>
> X-Postfix-Queue-ID: 703F28329
> X-Postfix-Sender: rfc822; [e-mail]<mailto:[e-mail]>
> Arrival-Date: Mon, 23 Nov 2015 22:38:05 -0500 (EST)
>
> Final-Recipient: rfc822; [e-mail]<mailto:[e-mail]>
> Original-Recipient: rfc822;[e-mail]<mailto:[e-mail]>
> Action: failed
> Status: 4.4.1
> Diagnostic-Code: X-Postfix; connect to pipi.pi.nu<http://pipi.pi.nu>[83.168.239.141]:25: No route
>    to host
>
> Final-Recipient: rfc822; [e-mail]<mailto:[e-mail]>
> Original-Recipient: rfc822;[e-mail]<mailto:[e-mail]>
> Action: failed
> Status: 4.4.1
> Diagnostic-Code: X-Postfix; connect to
>    juniper-net.mail.eo.outlook.com<http://juniper-net.mail.eo.outlook.com>[207.46.163.170]:25: No route to host
>
> Final-Recipient: rfc822; [e-mail]<mailto:[e-mail]>
> Original-Recipient: rfc822;[e-mail]<mailto:[e-mail]>
> Action: failed
> Status: 4.4.1
> Diagnostic-Code: X-Postfix; connect to
>    sesbmg13.ericsson.net<http://sesbmg13.ericsson.net>[193.180.251.49<tel:%5B193.180.251.49>]:25: No route to host
>
> - --703F28329.1448771977/msa1.orleans.occnc.com<http://msa1.orleans.occnc.com>
> Content-Description: Undelivered Message
> Content-Type: message/rfc822
>
> Return-Path: <[e-mail]<mailto:[e-mail]>>
> Received: from harbor2.v6only.occnc.com<http://harbor2.v6only.occnc.com> (harbor2-em2.v6only.occnc.com<http://harbor2-em2.v6only.occnc.com> [IPv6:2001:470:88e6:2::231])
>       (using TLSv1 with cipher ECDHE-ECDSA-AES256-SHA (256/256 bits))
>       (Client did not present a certificate)
>       (Authenticated sender: [e-mail]<mailto:[e-mail]>)
>       by msa1.orleans.occnc.com<http://msa1.orleans.occnc.com> (Postfix) with ESMTPSA id 703F28329;
>       Mon, 23 Nov 2015 22:38:05 -0500 (EST)
> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ipv6.occnc.com<http://ipv6.occnc.com>;
>       s=curtis-ipv6; t=1448336286;
>       bh=7m15Bo/aV+XVrU+nE3ZZkyiw607TYWoVhIgtD1vpQas=;
>       h=To:cc:Reply-To:From:Subject:In-reply-to:Date;
>       b=lUqGSehbmw0NdtDtUtzuiwiWNeMxvdxP9f0aqpRnHvFpyggLz4xy4nryuO/zWMDBw
>        rJBFuSqd3SULw500bo2Gj5NKTAAyzpeVBjhPX4erMJqI5hBJ68gNRsUktMj3Vty3vT
>        MEm8NBfMrYvdQYR/CQaYUZcbg3EGCcO8WhfN3E4g=
> To: Loa Andersson <[e-mail]<mailto:[e-mail]>>, Lizhong <[e-mail]<mailto:[e-mail]>>
> cc: [e-mail]<mailto:[e-mail]>, Curtis Villamizar <[e-mail]<mailto:[e-mail]>>,
>    David Allan I <[e-mail]<mailto:[e-mail]>>,
>    "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>,
>    "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
> Reply-To: [e-mail]<mailto:[e-mail]>
> From: Curtis Villamizar <[e-mail]<mailto:[e-mail]>>
> Subject: Re: MPLS-RT review od draft-smack-mpls-rfc4379bis
> In-reply-to: Your message of "Tue, 24 Nov 2015 11:08:30 +0800."
>             <[e-mail]<mailto:[e-mail]>>
> MIME-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> Content-ID: <[e-mail]<mailto:[e-mail]>>
> Content-Transfer-Encoding: quoted-printable
> Date: Mon, 23 Nov 2015 22:38:05 -0500
>
> Hi Loa, Lizhong,
>
> I'm replying to the email from Lizhong because I misplaced Loa's original.  Oops.
>
> Dec 6 should be OK.
>
> Curtis
>
>
> In message <[e-mail]<mailto:[e-mail]>>
> Lizhong writes:
>> =
>
>> Hi Loa,
>> Should be OK for me. Thanks.
>> =
>
>> Regards
>> Lizhong
>> =
>
>> > =
>
>> > Lizhong, Yimin, Curtis, and  Dave,
>> > =
>
>> > =
>
>> > You have been selected as MPLS-RT reviewers for
>> > draft-smack-mpls-rfc43=
> 79bis.
>> > =
>
>> > Note to authors: You have been CC'd on this email so that you can
>> > know that this review is going on. However, please do not review
>> > your own document.
>> > =
>
>> > Reviews should comment on whether the document is coherent, is it
>> > useful (ie, is it likely to be actually useful in operational
>> > networks=
> ), and is the document technically sound?
>> > =
>
>> > We are interested in knowing whether the document is ready to be
>> > considered for WG adoption (ie, it doesn't have to be perfect at
>> > this point, but should be a good start).
>> > =
>
>> > This MPLS-RT review is a bit different in that it is a bis-version
>> > of a widely implemented and deployed protocol, however the basic
>> > question is the same - are we ready to adopt it as a wg document? If
>> > the meet all the criteria LSP Ping will be progressed to Internet Standard.
>> > =
>
>> > Reviews should be sent to the document authors, WG co-chairs and WG
>> > secretary, and CC'd to the MPLS WG email list. If necessary,
>> > comments may be sent privately to only the WG chairs.
>> > =
>
>> > If you have technical comments you should try to be explicit about
>> > wha=
> t
>> > needs to be resolved before adopting it as a working group document,
>> > a=
> nd
>> > what can wait until the document is a working group document and the
>> > working group has the revision control.
>> > =
>
>> > Are you able to review this draft by December 6, 2015? Please
>> > respond in a timely fashion.
>> > =
>
>> > Thanks, Loa
>> > (as MPLS WG chair)
>> > =
>
>> > =
>
>> > -- =
>
>> > =
>
>> > =
>
>> > Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
>> > Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
>> > Huawei Technologies (consultant)     phone: [phone]<tel:%2B46%20739%2081%2021%2064>
>
> - --703F28329.1448771977/msa1.orleans.occnc.com--
>
> ------- End of Forwarded Message
>
> --
>
>
> Loa Andersson                        email: [e-mail]<mailto:[e-mail]>
> Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
> Huawei Technologies (consultant)     phone: [phone]<tel:%2B46%20739%2081%2021%2064>
>
>



--
Kireeti