Subject: [CCAMP] 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: 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