Subject: [mpls] Retiring ACH TLVs

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 May 2013 18:08:34 +0100

Hi,

ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is about explaining why no-one actually wants to use them (i.e., when each new ACH Type is defined and has a "No TLVs" written for it, we get asked "why not?").

It seems to us that ACH TLVs are an idea that has been rejected. Initially we thought they might be used (especially for identifiers), but there seems to be good opinion that handling generic TLVs would be a pain.

Since I was heavily responsible for insisting that ACH TLVs were included in RFC 5586, it seems reasonable that I do the work to fix it.

The I-D below retires ACH TLVs and handles the necessary registry changes.

Note, of course, that structured data are still possible within individual ACHs if the protocol spec for an individual ACH decides to have them.

We're directing this work to the MPLS working group because that is where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. 

Thanks for any comments.

As humble WG contributors we would be enthusiastic to see early WG adoption and last call :-)

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 07 May 2013 17:33
> To: Adrian Farrel; Stewart Bryant
> Subject: New Version Notification for draft-farbryantrel-mpls-retire-ach-tlv-
> 00.txt
> 
> 
> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> 
> Filename:	 draft-farbryantrel-mpls-retire-ach-tlv
> Revision:	 00
> Title:		 Retiring TLVs from the Associated Channel Header of the MPLS
> Generic Associated Channel
> Creation date:	 2013-05-07
> Group:		 Individual Submission
> Number of pages: 4
> URL:             http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire-
> ach-tlv-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv
> Htmlized:        http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00
> 
> 
> Abstract:
>    The MPLS Generic Associated Channel (G-ACh) is a generalization of
>    the applicability of the Pseudowire (PW) Associated Channel Header
>    (ACH).  RFC 5586 defines the concept of Type-Length-Variable (TLV)
>    constructs that can be carried in messages on the G-ACh by placing
>    them in the ACH.
> 
>    No Associated Channel Type yet defined uses a TLV.  Furthermore, it
>    is believed that handling TLVs in hardware introduces significant
>    problems to the fast-path, and since G-ACh messages are intended to
>    be processed substantially in hardware, the use of TLVs in
>    undesirable.
> 
>    This document updates RFC 5586 by retiring ACH TLVs and removing the
>    associated registry.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 10 May 2013 18:21:23 +0000

Fully support the ID. I was never a fan of ACH TLVs.

Thanks
Nitin Bahadur

On 5/7/13 10:08 AM, "Adrian Farrel" <[email-masked]> wrote:

>Hi,
>
>ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is
>about explaining why no-one actually wants to use them (i.e., when each
>new ACH Type is defined and has a "No TLVs" written for it, we get asked
>"why not?").
>
>It seems to us that ACH TLVs are an idea that has been rejected.
>Initially we thought they might be used (especially for identifiers), but
>there seems to be good opinion that handling generic TLVs would be a pain.
>
>Since I was heavily responsible for insisting that ACH TLVs were included
>in RFC 5586, it seems reasonable that I do the work to fix it.
>
>Note, of course, that structured data are still possible within
>individual ACHs if the protocol spec for an individual ACH decides to
>have them.
>
>We're directing this work to the MPLS working group because that is where
>5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information.
>
>Thanks for any comments.
>
>> URL:            
>>http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire-
>> ach-tlv-00.txt
>> Status:         
>>http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv
>> Htmlized:       
>>http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00
>> 
>> 
>> Abstract:
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Giles Heron <[email-masked]>
Date: Fri, 10 May 2013 19:36:59 +0100

Likewise.

ACH TLVs tripped me up when editing the PWE3 static status draft (now RFC6478), so I'd be glad to be rid of them :)

Giles

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 12 May 2013 20:28:00 +0000

+1.

Thanks,

-- Carlos.

---

From: Dan Frost <[email-masked]>
Date: Mon, 13 May 2013 11:15:53 +0100

Full support, and sooner the better.  :)

-d

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 13 May 2013 06:30:35 -0400

Fully support.

-sam

Sent from my iPhone

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 14 May 2013 15:30:26 +0000

Absolutely!

On 5/13/13 6:30 AM, "Sam Aldrin" <[email-masked]> wrote:

>> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it
>>is about explaining why no-one actually wants to use them (i.e., when
>>each new ACH Type is defined and has a "No TLVs" written for it, we get
>>asked "why not?").
>> 
>>Initially we thought they might be used (especially for identifiers),
>>but there seems to be good opinion that handling generic TLVs would be a
>>pain.
>> 
>> Since I was heavily responsible for insisting that ACH TLVs were
>>included in RFC 5586, it seems reasonable that I do the work to fix it.
>> 
>> We're directing this work to the MPLS working group because that is
>>where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for
>>information. 
>> 
>> Thanks for any comments.
>>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 14 May 2013 16:10:36 +0000

Support

Regards,
Jeff

---

From: David Allan I <[email-masked]>
Date: Tue, 14 May 2013 16:16:49 +0000

I'm all for deprecating ACH TLVs. 

Support 
Dave 

>>> Hi,
>>> 
>>> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly 
>>> it is about explaining why no-one actually wants to use them (i.e., 
>>> when each new ACH Type is defined and has a "No TLVs" written for 
>>> it, we get asked "why not?").
>>> 
>>> Initially we thought they might be used (especially for 
>>> identifiers), but there seems to be good opinion that handling 
>>> generic TLVs would be a pain.
>>> 
>>> individual ACHs if the protocol spec for an individual ACH decides 
>>> to have them.
>>> 
>>>>  No Associated Channel Type yet defined uses a TLV.  Furthermore, 
>>>> it  is believed that handling TLVs in hardware introduces 
>>>> significant  problems to the fast-path, and since G-ACh messages 
>>>> are intended to  be processed substantially in hardware, the use of 
>>>> TLVs in  undesirable.
>>>> 
>>>>  This document updates RFC 5586 by retiring ACH TLVs and removing 
>>>> the  associated registry.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> The IETF Secretariat
>>>

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 14 May 2013 17:03:32 +0000

Support.

Thx
SD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow (swallow)
Sent: Tuesday, May 14, 2013 8:30 AM
To: Sam Aldrin; [email-masked]
Cc: <[email-masked]>
Subject: Re: [mpls] Retiring ACH TLVs

Absolutely!

---

From: Pablo Frank <[email-masked]>
Date: Thu, 16 May 2013 11:13:23 -0400

Please, please do this.

thanks,
Pablo

On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel <[email-masked]> wrote:

> about explaining why no-one actually wants to use them (i.e., when each new
> ACH Type is defined and has a "No TLVs" written for it, we get asked "why
> not?").
>
> It seems to us that ACH TLVs are an idea that has been rejected. Initially
> we thought they might be used (especially for identifiers), but there seems
> to be good opinion that handling generic TLVs would be a pain.
>
> Note, of course, that structured data are still possible within individual
> ACHs if the protocol spec for an individual ACH decides to have them.
>

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 16 May 2013 16:13:52 +0000

Actually, I hadn't noticed that the registry was under Pseudowire Name Spaces,
which is silly, since TLVs were never defined for the PW ACh.
(The ACh types is different, since at least some of these are used for VCCV.)

If there is no use for them, then let's deprecate.
However, I believe that options for the signalling and management channels of RFC 5718
have never been spelled out.  Are we sure that these will not need some standard modifiers/parameters ?

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 07 May, 2013 20:09
To: [email-masked]
Subject: [mpls] Retiring ACH TLVs

Hi,

Thanks for any comments.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 May 2013 17:42:14 +0100

Yaakov,

> However, I believe that options for the signalling and management channels of
> RFC 5718 have never been spelled out.  Are we sure that these will not need
> some standard modifiers/parameters ?

It's a reasonable question, and perhaps why the TLV space was initially defined.
The example use cases I have seen discussed have been addresses and security.

However, we have got this far without any actual use cases which makes me think
that "standard modifiers/parameters" will not be applied to all of the existing
ACH types (essentially they had the "No TLVs" box checked in the registry). 

So, I think the way it works is that if one or more new ACH types need
"standard" modifiers in their messages, they can build that information into the
messages they define rather than into the generic header that is the ACH.

Cheers,
Adrian