Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 13 May 2015 17:39 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C941A909C for <mpls@ietfa.amsl.com>; Wed, 13 May 2015 10:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.492
X-Spam-Level:
X-Spam-Status: No, score=0.492 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=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 PaL_K7loNEqu for <mpls@ietfa.amsl.com>; Wed, 13 May 2015 10:39:57 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090711A908A for <mpls@ietf.org>; Wed, 13 May 2015 10:39:55 -0700 (PDT)
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (25.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (25.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.160.19; Wed, 13 May 2015 16:49:19 +0000
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([25.161.55.12]) with mapi id 15.01.0166.017; Wed, 13 May 2015 16:49:19 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Loa Andersson <loa@pi.nu>, "BRUNGARD, DEBORAH A" <db3546@att.com>
Thread-Topic: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
Thread-Index: AQHQjZzAsr+eVgEnQkSV6+FhG15t2Q==
Date: Wed, 13 May 2015 16:49:18 +0000
Message-ID: <DB3PR03MB0780EB97294D9CD37A9711A19DD90@DB3PR03MB0780.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Infraware POLARIS Mobile Mailer v2.5
authentication-results: pi.nu; dkim=none (message not signed) header.d=none;
x-originating-ip: [109.253.142.204]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779;
x-microsoft-antispam-prvs: <DB3PR03MB077963CC2E104CCB636761BC9DD90@DB3PR03MB0779.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779;
x-forefront-prvs: 0575F81B58
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(479174004)(13464003)(51704005)(252514010)(377424004)(377454003)(76576001)(189998001)(19617315012)(50226001)(2656002)(87936001)(46102003)(2900100001)(16799955002)(92566002)(86362001)(62966003)(77156002)(74316001)(122556002)(5001960100002)(50986999)(15188155005)(19580405001)(40100003)(19580395003)(5001770100001)(106116001)(33656002)(19625215002)(102836002)(15975445007)(66066001)(16236675004)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780EB97294D9CD37A9711A19DD90DB3PR03MB0780eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2015 16:49:18.3269 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/kRfV-htyb8zNYMJLI6HoA3gl8zA>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "rcallon@juniper.net" <rcallon@juniper.net>
Subject: Re: [mpls] to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 13 May 2015 17:39:59 -0000

Loa,

I do not argue with the decision.



I would simply like to understand

(a) whether you think that this change should be considered if/when 5586bis is considered

(b) how to preserve this input if it has any value.



My gut feeling after reading your original email was that the change is worth considering. And I do not know the answer for (b).



Thumb typed on my LG,
Sasha

------ Original message ------
From: Loa Andersson
Date: 13/05/2015 18:43
To: Alexander Vainshtein;BRUNGARD, DEBORAH A;
Cc: mpls@ietf.org;matthew.bocci@alcatel-lucent.com;martin.vigoureux@alcatel-lucent.com;stbryant@cisco.com;akatlas@gmail.com;aretana@cisco.com;rcallon@juniper.net;swallow@cisco.com;
Subject:Re: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

Sasha,

I think the rationale is that the wg chairs don't see this as an
errata, but rather as a change.

Not being an errata, it seems odd to use the errata system to maintain a
non-errata.

/Loa

On 2015-05-13 14:14, Alexander Vainshtein wrote:
> Deborah, Loa and all,
> I accept the decision to reject the errata, of course.
>
> Revisiting this issue if/when the document is updated is OK with me, even if must admit that  I do not understand the difference between this and the disposition of errata that says "take into account when the document is updated" (or something like this).
>
> I would just like to clarify that my interest in the issue was triggered by a question I've received from the field, when a person examining some capture as asked me:
> "Why is the TTL in the LSE containing GAL set to 2" Is this standard?"
>
> I have looked up RFC 5586, and I did not find a straightforward answer to this question.
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>
> -----Original Message-----
> From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]
> Sent: Wednesday, May 13, 2015 2:58 PM
> To: Loa Andersson; RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net
> Cc: Alexander Vainshtein; mpls@ietf.org
> Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
>
> Will do -
> Thanks Loa-
> Deborah
>
>
> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: Wednesday, May 13, 2015 2:59 AM
> To: RFC Errata System; matthew.bocci@alcatel-lucent.com; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com; akatlas@gmail.com; BRUNGARD, DEBORAH A; aretana@cisco.com; swallow@cisco.com; rcallon@juniper.net
> Cc: Alexander.Vainshtein@ecitele.com; mpls@ietf.org
> Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)
>
> Folks,
>
> MPLS chairs have discussed the errata.
>
> We feel that it is a change to the document rather than an errata, on that ground it should be rejected.
>
> We think that the appropriate would be to revisit this if the document is updated.
>
> I'm always uncertain of the procedures around accepting/rejecting errata, but I guess it requires AD decision.
>
> Deborah,
>
> Can you mark this a "rejected"?
>
>
> /Loa
>
> On 2015-05-12 16:14, RFC Errata System wrote:
>> The following errata report has been submitted for RFC5586, "MPLS
>> Generic Associated Channel".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5586&eid=4364
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Alexander ("Sasha") Vainshtein
>> <Alexander.Vainshtein@ecitele.com>
>>
>> Section: 4.2.1
>>
>> Original Text
>> -------------
>>      The Time-To-Live (TTL) field of the LSE that contains the GAL follows
>>      the definition and processing rules specified in [RFC3443].
>>
>> Corrected Text
>> --------------
>> The value of the  Time-To-Live (TTL) field of the LSE that contains
>> the GAL follows is irrelevant as long as it exceeds 1. (Setting this
>> value to 0 or 1 SHOULD be avoided because it could result in trapping
>> the OAM packets in with wrong reason: "TTL expiration" instead of "GAL
>> encountered").
>>
>> Notes
>> -----
>> The processing rules specific in RFC 3443 deal with handling TTL in the LSE of a labeled packets that are forwarded based on this LSE, or with setting the TTL value by a LER pushing a label stack on an unlabeled packet.
>> As per the last para in Section 4.2, LSRs and LERs MUST NOT forward packets based on the LSE that contains GAL, hence these rules are mainly not applicable.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or rejected.
>> When a decision is reached, the verifying party (IESG) can log in to
>> change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5586 (draft-ietf-mpls-tp-gach-gal-06)
>> --------------------------------------
>> Title               : MPLS Generic Associated Channel
>> Publication Date    : June 2009
>> Author(s)           : M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.
>> Category            : PROPOSED STANDARD
>> Source              : Multiprotocol Label Switching
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>

--


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64