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

[Kireeti Kompella <[e-mail]>]

Replying to Carlos's reply to Dave and copying the mailing list.

On Sun, Dec 6, 2015 at 9:43 PM, Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Dave,
>
> > On Dec 5, 2015, at 9:18 PM, Loa Andersson <[e-mail]> wrote:
> >
> >
> > Authors,
> >
> > Dave Allan's review. I asked him to send it to the list also.
> >
> > /Loa
> >
> > -------- Forwarded Message --------
> > Subject: RE: draft-smack-mpls-rfc4379bis
> > Date: Mon, 30 Nov 2015 21:47:28 +0000
> > From: David Allan I <[e-mail]>
> > To: [e-mail] <[e-mail]>
> > CC: [e-mail] <[e-mail]>, [e-mail] <
> [e-mail]>
> >
> > HI Loa:
> >
> > 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!


> 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.


> > "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.

> 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.


> 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!

Kireeti.


>
> — Carlos.
>
> >
> > Cheers
> > Dave
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: David Allan I
> > Sent: Monday, November 30, 2015 10:23 AM
> > To: '[e-mail]'; [e-mail]; [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]]
> > Sent: Sunday, November 29, 2015 11:05 AM
> > To: [e-mail]; [e-mail]; David Allan I
> > Cc: [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]
> > Received: by 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 [2001:470:88e6:2::247]
> >       by 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 ([unix socket])
> >        by 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 (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", Issuer "" (verified OK))
> >       (Authenticated sender: [e-mail])
> >       by mda23.v6only.occnc.com (Postfix) with ESMTPSA id A8602B71A
> >       for <[e-mail]>; Sat, 28 Nov 2015 23:40:52 -0500 (EST)
> > Received: from msa1.orleans.occnc.com (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", Issuer "" (verified OK))
> >       (Authenticated sender: [e-mail])
> >       by mta1.orleans.occnc.com (Postfix) with ESMTPSA id 0C35AA8AE
> >       for <[e-mail]>; Sat, 28 Nov 2015 23:39:41 -0500 (EST)
> > Received: by 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;
> >       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] (Mail Delivery System)
> > Subject: Undelivered Mail Returned to Sender
> > To: [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"
> > Message-Id: <[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
> >
> > This is a MIME-encapsulated message.
> >
> > - --703F28329.1448771977/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.
> >
> > 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]>: connect to pipi.pi.nu[83.168.239.141]:25: No route to host
> >
> > <[e-mail]>: connect to
> >    juniper-net.mail.eo.outlook.com[207.46.163.170]:25: No route to host
> >
> > <[e-mail]>: connect to
> >    sesbmg13.ericsson.net[193.180.251.49]:25: No route to host
> >
> > - --703F28329.1448771977/msa1.orleans.occnc.com
> > Content-Description: Delivery report
> > Content-Type: message/delivery-status
> >
> > Reporting-MTA: dns; msa1.orleans.occnc.com
> > X-Postfix-Queue-ID: 703F28329
> > X-Postfix-Sender: rfc822; [e-mail]
> > Arrival-Date: Mon, 23 Nov 2015 22:38:05 -0500 (EST)
> >
> > Final-Recipient: rfc822; [e-mail]
> > Original-Recipient: rfc822;[e-mail]
> > Action: failed
> > Status: 4.4.1
> > Diagnostic-Code: X-Postfix; connect to pipi.pi.nu[83.168.239.141]:25:
> No route
> >    to host
> >
> > Final-Recipient: rfc822; [e-mail]
> > Original-Recipient: rfc822;[e-mail]
> > Action: failed
> > Status: 4.4.1
> > Diagnostic-Code: X-Postfix; connect to
> >    juniper-net.mail.eo.outlook.com[207.46.163.170]:25: No route to host
> >
> > Final-Recipient: rfc822; [e-mail]
> > Original-Recipient: rfc822;[e-mail]
> > Action: failed
> > Status: 4.4.1
> > Diagnostic-Code: X-Postfix; connect to
> >    sesbmg13.ericsson.net[193.180.251.49]:25: No route to host
> >
> > - --703F28329.1448771977/msa1.orleans.occnc.com
> > Content-Description: Undelivered Message
> > Content-Type: message/rfc822
> >
> > Return-Path: <[e-mail]>
> > Received: from harbor2.v6only.occnc.com (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])
> >       by 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;
> >       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]>, Lizhong <[e-mail]>
> > cc: [e-mail], Curtis Villamizar <[e-mail]>,
> >    David Allan I <[e-mail]>,
> >    "[e-mail]" <
> [e-mail]>,
> >    "[e-mail]" <[e-mail]>
> > Reply-To: [e-mail]
> > From: Curtis Villamizar <[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]>
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset="us-ascii"
> > Content-ID: <[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]>
> > 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]
> >> > Senior MPLS Expert                          [e-mail]
> >> > Huawei Technologies (consultant)     phone: [phone]
> >
> > - --703F28329.1448771977/msa1.orleans.occnc.com--
> >
> > ------- End of Forwarded Message
> >
> > --
> >
> >
> > Loa Andersson                        email: [e-mail]
> > Senior MPLS Expert                          [e-mail]
> > Huawei Technologies (consultant)     phone: [phone]
> >
> >
>
>


-- 
Kireeti