Subject: RE: Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Mar 2014 20:33:19 -0000

Hi,

I have one issue I want to bring up as a last call comment. I discussed it
briefly with Eric and we agreed it is something that needs wider discussion than
just a late editorial change.

Currently 6378 does not describe the format of PSC TLVs and
draft-ietf-mpls-tp-itu introduces one without defining the format tightly.
Therefore, this document contains a simple statement of the fields and meanings
in a TLV.

However, 6378 also does not state how to handle:
- a malformed TLV
- an unknown TLV type

We need to add some simple text to cover this.

Options for each of the above are:
- ignore the TLV but process the message
- report the TLV but ignore the TLV and process the message
- ignore the message
- report the message but ignore it
- reject the message

Thanks,
Adrian

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of The IESG
> Sent: 26 March 2014 19:57
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to
MPLS
> Transport Profile Linear Protection) to Proposed Standard
> 
> 
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> - 'Updates to MPLS Transport Profile Linear Protection'
>   <draft-ietf-mpls-psc-updates-03.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-04-09. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
>    This document contains four updates to the Protection State
>    Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile
>    (MPLS-TP) Linear Protection" . Two of the updates correct existing
>    behavior.  The third clarifies a behavior which was not explained in
>    the RFC, and the fourth adds rules around handling capabilities
>    mismatches.
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ballot/
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 31 Mar 2014 21:16:17 +0100

Thanks Eric,

"reject the message" means send some form of error response?
Or do you mean "drop the message" and "vigorously report it"?

Thanks,
Adrian

> From: Eric Osborne [mailto:[email-masked]]
> Sent: 31 March 2014 20:09
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates
to
> MPLS Transport Profile Linear Protection) to Proposed Standard
> 
> Hello Adrian, WG-
> 
>   I propose this:
> 
> Malformed TLV: reject the message and vigorously report it
> Unknown TLV type: report the TLV, ignore the TLV and process the rest
> of the message
> 
> I'm open to other opinions, though.
> 
> 
> 
> 
> eric
> 
> On Wed, Mar 26, 2014 at 4:33 PM, Adrian Farrel <[email-masked]> wrote:
> > Hi,
> >