Subject: [mpls] [Technical Errata Reported] RFC5586 (4364)

From: RFC Errata System <[email-masked]>
Date: Tue, 12 May 2015 07:14:06 -0700 (PDT)

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 <[email-masked]>

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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 13 May 2015 08:59:10 +0200

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 13 May 2015 11:58:28 +0000

Will do -
Thanks Loa-
Deborah

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Wednesday, May 13, 2015 2:59 AM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; BRUNGARD, DEBORAH A; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

Folks,

Deborah,

/Loa

--

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 May 2015 12:14:18 +0000

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:   [email-masked]

-----Original Message-----
From: BRUNGARD, DEBORAH A [mailto:[email-masked]] 
Sent: Wednesday, May 13, 2015 2:58 PM
To: Loa Andersson; RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Alexander Vainshtein; [email-masked]
Subject: RE: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

Will do -
Thanks Loa-
Deborah

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Wednesday, May 13, 2015 2:59 AM
To: RFC Errata System; [email-masked]; [email-masked]; [email-masked]; [email-masked]; BRUNGARD, DEBORAH A; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: to be rejected - Re: [Technical Errata Reported] RFC5586 (4364)

Folks,

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,

/Loa

On 2015-05-12 16:14, RFC Errata System wrote:
> The following errata report has been submitted for RFC5586, "MPLS 
> Generic Associated Channel".
>
> 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
> -----
> 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.
>

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 13 May 2015 17:43:17 +0200

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

--