Subject: [mpls-tp] WG Last Call on draft-ietf-mpls-tp-ach-tlv-02.txt

From: Loa Andersson <[email-masked]>
Date: Sat, 06 Mar 2010 18:28:49 +0100

All,

this is to start a three week MPLS working group last call on

http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ach-tlv-02.txt

Please review and send your comments only to the [email-masked]
mailing list.

The working group last call end March 28, 2010.

Loa and George

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 6 Mar 2010 12:26:43 -0800

Dear Authors and All,
my question on how the Type range control been organized. Is the whole range
from 0x0000 through 0xffff controlled by IANA? Would we like to leave some
smaller range out for experimental use?

Regards,
Greg

On Sat, Mar 6, 2010 at 9:28 AM, Loa Andersson <[email-masked]> wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 06 Mar 2010 22:30:29 +0000

Greg Mirsky wrote:
> Dear Authors and All,
> my question on how the Type range control been organized. Is the whole 
> range from 0x0000 through 0xffff controlled by IANA? 
> Would we like to leave some smaller range out for experimental use?
>
I imagine that we could allocate a small number (say 8) for experimental 
in the same way that we did for for the ACH itself.

- Stewart

> Regards,
> Greg
>
> On Sat, Mar 6, 2010 at 9:28 AM, Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     All,
>
>     <mailto:[email-masked]>
>     mailing list.
>
>     Loa Andersson                         email:
>     [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 07 Mar 2010 16:44:52 -0500

In message <[email-masked]>
> The working group last call end March 28, 2010.

This would be a good time to define a capabilities TLV with wording to
indicate that IANA will assign capabilities identifiers.

  x.x  Capabilities

    This TLV specifies a set of capabilities to be defined as needed
    if an when it becomes advantageous for each end to agree on the
    use of specific protocol extensions.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         AchTlvType = TBD      |        Length = 2             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Capability Number    |E|Req|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Capability Number - To be assigned by IANA as needed by future
      RFCs

      E - the enabled bit

        0 - currently disabled
	1 - currently enabled

      Req - requirement code

        11 - requires that thie capability ben enabled
	10 - requires that this capability be disabled
	01 - prefer that this capability be enabled
	00 - don't care if capability is enabled or disabled

    The Req bits contain a "prefer" and a "don't care" so that a
    difference of preference resolves to "enable".  If one end
    indicated Req=11 and the other indicates Req=10, then
    administrative action may be required.  These values should only
    be used in situations where the network equipment cannot function
    properly with a capability enabled or disabled.

    Absense of this TLV for a given capability indicates no change
    from prior value.  If an unknown capability is recieved, a TLV
    with E=0 and Req=10 SHOULD be returned.  Absense of a prior TLV
    for a given capability MUST be interpreted as E=0 and Req=10.

Is this a reasonable addition?  I hope we don't exceed 8K extensions!

Curtis

---

From: Mach Chen <[email-masked]>
Date: Tue, 09 Mar 2010 01:23:51 +0800

Hi authors,

I just read the draft, in section 2.4(ICC TLV):

 0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         AchTlvType = 3        |       Length = 16             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ICC                                       |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Based on the picture above, the Length should be 6, but not 16, am I right?

Best regards,
Mach

--------------------------------------------------
From: "Loa Andersson" <[email-masked]>
Sent: Sunday, March 07, 2010 1:28 AM
To: <[email-masked]>; <[email-masked]>; "CCAMP" <[email-masked]>; 
<[email-masked]>
Subject: [PWE3] WG Last Call on draft-ietf-mpls-tp-ach-tlv-02.txt

> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 08 Mar 2010 17:51:49 +0000

Mach

Yes - Its a typo that results from incorrectly editing a 13 to a 6.

Will fix in the next version.

Thanks

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 08 Mar 2010 17:59:43 +0000

Just to be clear, it should be

 0                   1                   2                   3
|         AchTlvType = 3        |       Length = 6              |

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 21 Mar 2010 01:36:58 +0000

We could allocate a small number - say 4 or 8 for experimental purposes.

What do others think?

-Stewart

Greg Mirsky wrote:
> range from 0x0000 through 0xffff controlled by IANA? Would we like to 
> leave some smaller range out for experimental use?
>
> Regards,
> Greg
>

---

From: Vishwas Manral <[email-masked]>
Date: Sat, 20 Mar 2010 19:33:23 -0700

Hi Stewart,

I agree we could allocate 8 numbers.

Thanks,
Vishwas

On Sat, Mar 20, 2010 at 6:36 PM, Stewart Bryant <[email-masked]> wrote:
>> range from 0x0000 through 0xffff controlled by IANA? Would we like to leave
>> some smaller range out for experimental use?
>>
>> Regards,
>> Greg
>>
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 21 Mar 2010 18:31:23 +0100

Ho Stewart,

> We could allocate a small number - say 4 or 8 for experimental purposes.

I agree, and for consistency use the same number (and numbers)
as allocated for experimental Channel types in RFC5586.

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Elisa Bellagamba <[email-masked]>
Date: Tue, 23 Mar 2010 21:59:19 +0100

Hello,

>From draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02:

2.4.  MEP and MIP Identifier
   When sending LSP-Ping packets using ACH, there MAY be a need to
   identify the maintenance end point (MEP) and/or the maintenance
   intermediate point (MIP) being monitored.  The MEP/MIP identifiers
   defined in [I-D.swallow-mpls-tp-identifiers] can be carried in the
   ACH TLVs [I-D.ietf-mpls-tp-ach-tlv] for identification.

But in draft-ietf-mpls-tp-ach-tlv-01 there are no sections specifying the MEP-ID.

I've noticed the problem because I was checking the configuration parameters needed for MPLS OAM configuration via LSP-ping for draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-01 and, since I didn't find anything for MEP-ID, I defined a new TLV to be put in the LSP ping message. But I think the best place would be the Ach TLV.

If you agree, we could move section "3.7. MPLS OAM SOURCE MEP-ID TLV for LSP Ping" of draft draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-01 to draft-ietf-mpls-tp-ach-tlv-01. 

Thanks,
Elisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: den 20 mars 2010 19:33
To: [email-masked]
Cc: CCAMP; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [CCAMP] [mpls] WG Last Call on draft-ietf-mpls-tp-ach-tlv-02.txt

Hi Stewart,

Thanks,
Vishwas

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 24 Mar 2010 01:17:13 +0100

Hi,

Some comments on the draft.

I think the current version does not do a good job in explaining what it actually tries to achieve/specify. To be more precise, right now it feels like a random collection of TLVs that might be generally useful but do not form a coherent whole or are serving a common greater purpose. Some text explaining this is necessary I think. Otherwise it is hard to judge whether the draft is ready for last call because I can't really tell whether the draft is complete or not. 

I was also surprised to find the destination TLV is gone. For clarification, could one of the authors explain why it has been removed? I thought it had some value e.g. in a P2MP case where you do not want to address all nodes at equal distance but one of the once at equal distance. In other words in cases where e.g. TTL expiry alone does not do what you really want to do. Or maybe you do that differently or it is not needed?

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Loa Andersson
> Sent: Samstag, 6. März 2010 18:29
> To: [email-masked]; [email-masked]; CCAMP; [email-masked]
> Subject: [CCAMP] WG Last Call on draft-ietf-mpls-tp-ach-tlv-02.txt
> 
> All,
>

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 23 Mar 2010 17:45:35 -0700

Hi Rolf,

Though I am part of the author team I am mailing here in individual capacity.

There are myriad drafts defining different OAM functionalities. There
is a lot of common information elements like security etc which can be
made a TLV and be used by every OAM draft. We do not then need every
draft to define the same.

I/ as well as one of the chairs have raised the same issue as you
regarding the Destination Address TLV. It is still being debated by
the authors.

Thanks,
Vishwas

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 24 Mar 2010 01:57:32 +0100

That was quick. Thanks. However, I am not yet quite satisfied with the answer. My main concern is that I do not understand the fundamental reasoning for the set of TLVs you have chosen. As a random example, say a sequence number TLV might be useful in a more general context. It is not listed, why not? Are the once you have listed all used by solution drafts somewhere at this point or are they a best guess as to which ones might be useful? Most are mapping nicely with the identifiers draft. Would that be a better place for the TLV specs, it at least has a well defined scope. And then make one on security and everything will be covered and nicely scoped as far as I can tell. In any case, if the actual list is still in flux, is a last call at this point sensible or should we wait till the main solution drafts stabilize?

Rolf

> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Mittwoch, 24. März 2010 01:46
> To: Rolf Winter
> Cc: [email-masked]
> Subject: Re: [mpls-tp] [CCAMP] WG Last Call on draft-ietf-mpls-tp-ach-
> tlv-02.txt
> 
> Hi Rolf,
> 
> > I think the current version does not do a good job in explaining what
> it actually tries to achieve/specify. To be more precise, right now it
> feels like a random collection of TLVs that might be generally useful
> but do not form a coherent whole or are serving a common greater
> purpose. Some text explaining this is necessary I think. Otherwise it
> is hard to judge whether the draft is ready for last call because I
> can't really tell whether the draft is complete or not.
> >
> > I was also surprised to find the destination TLV is gone. For
> clarification, could one of the authors explain why it has been
> removed? I thought it had some value e.g. in a P2MP case where you do
> not want to address all nodes at equal distance but one of the once at
> equal distance. In other words in cases where e.g. TTL expiry alone
> does not do what you really want to do. Or maybe you do that
> differently or it is not needed?
> >
> >
> >        Rolf
> >
> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> >
> >
> [email-masked]

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 23 Mar 2010 18:01:00 -0700

Hi Rolf,

Most of the TLV's are currently used in some form.

It is for this reason that Destination address TLV was actually removed.

Thanks,
Vishwas

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Mar 2010 18:04:06 -0700

Dear Rolf,
ACH TLV might be one of several encodings of MSP-TP Identifiers. If ACH TLV
to be merged into the Identifiers document, then, I'd assume, other
encodings should be presented. I think that is not the best solution and
will delay the Identifiers document.
As regarding to selection of covered in the document objects, then, I think
for the second time, authors will welcome suggestions and contributions.

Regards,
Greg

On Tue, Mar 23, 2010 at 5:57 PM, Rolf Winter <[email-masked]>wrote:

> That was quick. Thanks. However, I am not yet quite satisfied with the
> answer. My main concern is that I do not understand the fundamental
> reasoning for the set of TLVs you have chosen. As a random example, say a
> sequence number TLV might be useful in a more general context. It is not
> listed, why not? Are the once you have listed all used by solution drafts
> somewhere at this point or are they a best guess as to which ones might be
> useful? Most are mapping nicely with the identifiers draft. Would that be a
> better place for the TLV specs, it at least has a well defined scope. And
> then make one on security and everything will be covered and nicely scoped
> as far as I can tell. In any case, if the actual list is still in flux, is a
> last call at this point sensible or should we wait till the main solution
> drafts stabilize?
>
> Rolf
>

---

From: <[email-masked]>
Date: Wed, 24 Mar 2010 16:06:24 +0100

Hi,

Looking at the IANA section (section 4), there is a fixed length (3
octets) assigned to the Null TLV in the chart.
Is this correct? Shouldn't the Null TLV be variable in length?

In general (and considering other comments), for me it also feels like
if the draft content is still somehow in the middle of a process...

Regards,
Manuel

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: Saturday, March 06, 2010 9:29 AM
> Subject: [mpls] WG Last Call on draft-ietf-mpls-tp-ach-tlv-02.txt
> 
> All,
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Mar 2010 16:59:35 +0000

> Is this correct? Shouldn't the Null TLV be variable in length?
I have had on list and off list comments about the NULL TLV, and it 
seems that we have two cases, the need to provide 32bit alignment and 
the need to provide padding for various reasons such as forcing a packet 
to be a particular length for diagnostic reasons.

A suggestion WRT alignment is that we dedicate 256 tlv types to this by 
setting the top byte to a particular number.

So the standard structure of a TLV would be

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         AchTlvType = X        |       Length                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                             Value                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

but padding would be

    0              
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |AchTlvType = X |
   +-+-+-+-+-+-+-+-+

If for example X = 0, then TLVs carrying data would be in the range
0x0100 to 0xFFFF.

This is a very compact way of generating an alignment offset, although I 
would propose that we actually made X=0xFFxx so that the TLVs containing 
data were for all practical purposes in sitting in the range 0 to 
0x00FF, and ACH TLV types starting with 0XFF simple mean skip this byte.

As to large padding, we need to decide whether we really need it. The 
best case that I have heard for it is to force a packet size for 
diagnostics, but I suspect that we would need other data in the packet 
and would probably prefer the data was at the front rather than after 
the padding TLV. I therefore think that we would be better served by a 
specialist ACH type for this rather than using general purpose TLV on an 
ACH type intended for another purpose.

What do others think?

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Mar 2010 17:22:00 +0000

> as allocated for experimental Channel types in RFC5586.
I see no reason why they need to be the particular numbers used for ACH types, and if you look at the mail that I posted earlier today, you will see that there is an alternative method of doing padding that would conflict with that alignment.

- Stewart