Subject: Re: [mpls] MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-00.txt

From: Xuxiaohu <[email-masked]>
Date: Mon, 1 Apr 2013 08:19:10 +0000

Hi all,

I have reviewed this draft and think it is useful and ready for WG adoption.

Best regards,
Xiaohu

发件人: Lizhong Jin [mailto:[email-masked]]
发送时间: 2013年3月28日 22:31
收件人: Loa Andersson; [email-masked]
抄送: [email-masked]; [email-masked]; Xuxiaohu; [email-masked]; Martin Vigoureux; [email-masked]
主题: Re: MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-00.txt

Hi, all
I reviewed this draft, and think the document is useful, and is ready to be considered for WG adoption. One minor comments, this draft should be an update to RFC4379, and should be reflected at the beginning of the draft. Then does that mean this draft should be moved faster than any other drafts that require sub-tlv allocation.

Regards
Lizhong

On Tue, Mar 12, 2013 at 2:04 AM, Loa Andersson <[email-masked]<mailto:[email-masked]>> wrote:

Dan, Xu, Lizhong and Rajiv,

You have been selected as an MPLS Review team reviewers for
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-00.

Note to authors: You have been CC'd on this email so that you can know
that this review is going on. However, please do not review your own
document.

Reviews should comment on whether the document is coherent, is it
useful (ie, is it likely to be actually useful in operational
networks), and is the document technically sound?  We are interested
in knowing whether the document is ready to be considered for WG
adoption (ie, it doesn't have to be perfect at this point, but should be
a good start).

Reviews should be sent to the document authors, WG co-chairs and
WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
may be sent privately to only the WG chairs.

Are you able to review this draft by April 2, 2013?

Thanks, Loa
(as MPLS WG chair)

/Loa
--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Huawei Technologies (consult)        phone: +46 739 81 21 64<tel:%2B46%20739%2081%2021%2064>

---

From: t.petch <[email-masked]>
Date: Tue, 2 Apr 2013 09:31:51 +0100

Lizhong

Thank you for the review - yes, you are right to point out that  the
start of the draft should state that it updates RFC4379

Tom Petch

----- Original Message -----
From: "Lizhong Jin" <[email-masked]>
To: "Loa Andersson" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Martin Vigoureux"
<[email-masked]>; <[email-masked]>
Sent: Thursday, March 28, 2013 3:30 PM

> Hi, all
> I reviewed this draft, and think the document is useful, and is ready
to be
> considered for WG adoption. One minor comments, this draft should be
an
> update to RFC4379, and should be reflected at the beginning of the
draft.
> Then does that mean this draft should be moved faster than any other
drafts
> that require sub-tlv allocation.
>
> Regards
> Lizhong
>
>
> On Tue, Mar 12, 2013 at 2:04 AM, Loa Andersson <[email-masked]> wrote:
>
> >
> > draft-pac-mpls-lsp-ping-tlvs-**and-sub-tlvs-registry-00.
> >
> > Loa Andersson                        email: [email-masked]
> > Senior MPLS Expert                          [email-masked]
> > Huawei Technologies (consult)        phone: +46 739 81 21 64
> >
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 15 Apr 2013 20:04:14 +0000

Hi,

I have reviewed this draft and found it ready for the WG adoption. No
doubt that it is useful in the context of LSP Pings.

I do have a two Q for the authors and a comment/suggestion -

1. what's the rationale for including section 3.3.2 and 3.3.3>

	I suggest moving them to the appendix (since there is nothing new
	in there).

2. Shouldn't there be some text that discussed any possible challenges
with having reusable sub-TLVs (with exact meaning) that may be defined in
the future, given that RFC4379 implicitly prohibited such a re-usage?

I do think that this draft could benefit from several editorial changes
(especially in section 2 and 3) to make it concise and clear. I have taken
the liberty of suggesting the text for section 1, 2 and 3 along for your
consideration (and moving some of the text into the Appendix).

Of course, this document MUST mention updating RFC4379 at various places
(e.g. header, abstract, introduction).

Cheers,
Rajiv

PS: Suggested text for section 1, 2 and 3

1. Introduction 

   This document revises the structure and allocation policies in the use
of the TLVs
and sub-TLVs of the MPLS LSP Ping Parameters, as defined in [RFC4379].

This document specifies that the future allocations of sub-TLVs (aka
sub-types) will come from a single namespace that is common to all TLVs of
MPLS LSP Ping Parameters, thereby allowing the re-usage of future
sub-TLVs, and mandates the sub-type value greater than 32 to be used for
any future allocations.

The document that specifies any future allocation should state which all
TLVs the sub-TLV may appear under and indicate any other future use which
seems appropriate or inappropriate.

   This document does not change any existing allocations for TLVs and
sub-TLVs (aka Type and Sub-type) of [RFC4379] and maintains their
structure e.g. sub-TLV 1 (or any allocated sub-TLVs) continues to be
dependent on the TLV under which it appears, to ensure the backward
compatibility.

2. Current Sub-TLV Allocation & Registry

2.1 Current Sub-TLV (and TLV) Allocations

Currently, the allocation policy by IANA for all TLVs and sub-TLVs is the
same, as illustrated by the table 2 below. Note that the table is meant to
illustrate the allocation policy as described in RFC4379 section 7.2.

<table showing sub-TLV allocation>

What's not clear in the above allocation policy is that [RFC4379] also
specified the sub-TLVs to be scoped by the TLVs, i.e. A sub-TLV defined
for one TLV was valid for that TLV only.

This has become somewhat confusing, since the practice to re-use sub-TLV
value(s) defined for one TLV for another TLV with the same meaning has
been introduced since the publication of RFC4379.

2.2 Current Sub-TLV (and TLV) Registry Structure

   Currently, all TLVs and sub-TLVs are found in a single registry, as
illustrated in the table 1 below. Note that the table is meant to
illustrate the allocation policy as described in RFC4379 section 7.2 and
other RFCs that updated RFC4379.

We have chosen not to just copy the current registry here, but instead
build a model that shows how the allocation policies work.

<table showing Current TLV and sub-TLV registry Structure>

Please see the appendix for understanding this model row-by-row (row
numbers appear on the right most column).

2.3 Current Sub-TLV Allocation & Structure - Issues

(I) Confusion : A single registry table illustrated above might have been
a good idea early on, but over time, with an increasing number of TLVs,
and with few sub-TLV values shared across TLVs, it has become increasingly
difficult (or confusing) to understand how the allocation policies
interact and the meaning of a sub-TLV value without knowing the parent
TLV. Consider these two examples :

- TLVs Types 1, 16 and 21 reuse sub-TLV 1 with the same meaning.
- sub-TLV 1 appears under TLV Type 1 as LDP IPv4 Prefix, under TLV Type 11
as IPv4 Egress Address P2MP Responder and under TLV Type 20 as Multipath
data. 

One must rely on careful reading of [RFC4379] and other RFCs that updated
it to sort out the confusion.

(II) Large sub-TLV value range - The current name space of sub-TLVs (65
535 potential TLVs times 65 535 sub-TLVs per TLV) is a maximum of 4 294
836 335 sub-TLVs. This is way to large space. There seems no reason why
that number of sub-TLVs should be needed;rather, 65 535 sub-TLVs shared
among all TLVs would seem to have been more than sufficient.

3. New sub-TLV Allocation & Registry Structure

This draft prescribes having one IANA registry for TLVs and another for
sub-TLVs to benefit the future allocations & registration of sub-TLVs. In
other words, the future policy for the registration of sub-TLVs is to have
a single registry regardless of which TLV the sub-TLV appears under. This
would result in registries and allocation policies that are much easier to
understand and comprehend (and avoid confusion).

	For example, a sub-TLV (to be) defined for an IPv6 address can be used
	 wherever such an address is required e.g. in any TLV.

3.1 New TLV Allocation & Registry Structure

As illustrated below, the new TLV registry follows the same pattern as
that of the existing registries.

< table showing TLV allocation >

Please see the Appendix XYZ for the current (LSP Ping) TLV allocations in
the IANA registry so far as of January 2013.

3.2 New sub-TLV Allocation & Registry Structure

As illustrated below, the new sub-TLV registry follows the same pattern as
that of the existing registries with an exception that range 0 to 31 is
not reserved and MUST NOT be assigned lest there is an overlap with
existing definitions. choice of 32 is somewhat greater than the greatest,
existing, defined sub-TLV, 25 for TLV Type 1, and is chosen to be a more
user-friendly, easier to remember, number than, say, 26 or 29.

< table showing sub-TLV allocation>

Please see the Appendix XYZ for the current sub-TLV allocations for TLV
Type=1 in the IANA registry so far as of January 2013.

4. Security Š

///

~~~~~~~~~~~~~

If you consider the above text, then please ignore the below comments (as
I thought that it would be easier to rewrite these sections than add
comments one-by-one):

0) Reference to 'IANA registry' is mentioned at several places, without
including the relevant informative reference. I suggest to include that
and update.

1) Section 2 refers to 'a single table', but doesn't specify what this
single table is. I suggest using 'a single IANA registry table'

2) Section 2 - This could benefit from reorganization of the text quite a
bit. 

 * Section 2.1 Change the title to 'Current Sub-TLV Allocation & Structure'
 * Section 2.2 change the title to 'Current Sub-TLV Allocation & Structure
- Issues' 
* Move section 2.3 into the Appendix

3) The first few paras of section 3.1 well clarify the problem and I would
suggest to move it early on in section 2.

4) Section 2.1 - It would be good to add a reference to section 7.2 of
RFC4379

5) section 2.2 - change title to "Current Model - Allocation policies and
Scope

//
   [RFC4379] also says that the sub-TLVs are scoped by the TLVs, i.e. a
sub-TLV defined for one TLV is valid for that TLV only. Later the
practice to re-define (a block of) sub-TLVs defined for one TLV for
another TLV was introduced.

//

The above para doesn't parse well. Did you mean to say re-use instead of
re-define? Also, it seems to suggest that RFC4379 later introduced the
practice of re-using...

Could it instead be rephrased to read -

   [RFC4379] also suggested that the sub-TLVs were scoped by the TLVs,
i.e. a
sub-TLV defined for one TLV was valid for that TLV only. This has become
incorrect, since the practice to re-use (a block of) sub-TLV values
defined for one TLV for
another TLV has been introduced since the publication of RFC4379.

>Loa Andersson                        email:
>[email-masked] <mailto:[email-masked]>
>Huawei Technologies (consult)        phone:
>+46 739 81 21 64 <tel:%2B46%20739%2081%2021%2064>
>
>
>
>
>
>

---

From: t.petch <[email-masked]>
Date: Tue, 16 Apr 2013 17:48:13 +0100

Rajiv

Thank you for your careful review; some thoughts inline.

Tom Petch

----- Original Message -----
From: "Rajiv Asati (rajiva)" <[email-masked]>
To: "Loa Andersson" <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; "Lizhong Jin" <[email-masked]>;
<[email-masked]>
Sent: Monday, April 15, 2013 9:04 PM

Hi,

<tp>

Don't know - the I-D could just be Section 5 and, having been immersed
in this for two years, would be all I would need right now.  But in
future, trying to sort out what came from where, I would probably value
those sections, along with 3.3.4, to refresh my memory.

</tp.

2. Shouldn't there be some text that discussed any possible challenges
with having reusable sub-TLVs (with exact meaning) that may be defined
in
the future, given that RFC4379 implicitly prohibited such a re-usage?

<tp>
I am unsure what challenges you have in mind.  If a reusable sub-TLV is
imprecisely defined, then it could be (mis-)used in different ways, or
perhaps
even if it were precisely defined.  Is this an IPv4 address, or a 32-bit
dotted decimal Area ID from OSPF?  That debate has taken place on other
lists and I think the key is getting a decent definition to start with,
being reviewed by people with a wide enough background. At present, we
do have a strong wish to reuse, as where the sub-TLVs of TLV Type 1 are
needed in several places, so I incline towards being flexible.

</tp>

I do think that this draft could benefit from several editorial changes
(especially in section 2 and 3) to make it concise and clear. I have
taken
the liberty of suggesting the text for section 1, 2 and 3 along for your
consideration (and moving some of the text into the Appendix).

<tp>Whoops</tp>

Cheers,
Rajiv

1. Introduction

   This document revises the structure and allocation policies in the
use
of the TLVs
and sub-TLVs of the MPLS LSP Ping Parameters, as defined in [RFC4379].

This document specifies that the future allocations of sub-TLVs (aka
sub-types) will come from a single namespace that is common to all TLVs
of
MPLS LSP Ping Parameters, thereby allowing the re-usage of future
sub-TLVs, and mandates the sub-type value greater than 32 to be used for
any future allocations.

<tp>
This seems to me not just editorial. The intent of the I-D is that new
allocations start with 32, not greater than 32; if that is unclear, then
yes, an editorial change is required.
</tp>

The document that specifies any future allocation should state which all
TLVs the sub-TLV may appear under and indicate any other future use
which
seems appropriate or inappropriate.

<tp>
This seems to me not just editorial, making it "all TLVs" is nailing
things down more than I would want.  Currently we have a rigid policy
and the result is complexity; I would not want to preclude people from
seeing a good use that was never anticipated by the first definer of a
sub-TLV.  Any I-D proposing any use is likely to be reviewed on this
list which I trust to catch any misuse.
</tp>

Currently, the allocation policy by IANA for all TLVs and sub-TLVs is
the
same, as illustrated by the table 2 below. Note that the table is meant
to
illustrate the allocation policy as described in RFC4379 section 7.2.

(I) Confusion : A single registry table illustrated above might have
been
a good idea early on, but over time, with an increasing number of TLVs,
and with few sub-TLV values shared across TLVs, it has become
increasingly
difficult (or confusing) to understand how the allocation policies
interact and the meaning of a sub-TLV value without knowing the parent
TLV. Consider these two examples :

- TLVs Types 1, 16 and 21 reuse sub-TLV 1 with the same meaning.
- sub-TLV 1 appears under TLV Type 1 as LDP IPv4 Prefix, under TLV Type
11
as IPv4 Egress Address P2MP Responder and under TLV Type 20 as Multipath
data.

One must rely on careful reading of [RFC4379] and other RFCs that
updated
it to sort out the confusion.

This draft prescribes having one IANA registry for TLVs and another for
sub-TLVs to benefit the future allocations & registration of sub-TLVs.
In
other words, the future policy for the registration of sub-TLVs is to
have
a single registry regardless of which TLV the sub-TLV appears under.
This
would result in registries and allocation policies that are much easier
to
understand and comprehend (and avoid confusion).

Please see the Appendix XYZ for the current (LSP Ping) TLV allocations
in
the IANA registry so far as of January 2013.

As illustrated below, the new sub-TLV registry follows the same pattern
as
that of the existing registries with an exception that range 0 to 31 is
not reserved and MUST NOT be assigned lest there is an overlap with
existing definitions. choice of 32 is somewhat greater than the
greatest,
existing, defined sub-TLV, 25 for TLV Type 1, and is chosen to be a more
user-friendly, easier to remember, number than, say, 26 or 29.

4. Security Š

///

~~~~~~~~~~~~~

If you consider the above text, then please ignore the below comments
(as
I thought that it would be easier to rewrite these sections than add
comments one-by-one):

<tp>
yes, reference needed
</tp>

2) Section 2 - This could benefit from reorganization of the text quite
a
bit.

 * Section 2.1 Change the title to 'Current Sub-TLV Allocation &
Structure'
 * Section 2.2 change the title to 'Current Sub-TLV Allocation &
Structure
- Issues'
* Move section 2.3 into the Appendix

3) The first few paras of section 3.1 well clarify the problem and I
would
suggest to move it early on in section 2.

5) section 2.2 - change title to "Current Model - Allocation policies
and
Scope

//

//

<tp>
mmmmm yes it could be clearer but ..
You are right to point out that we are not redefining sub-TLV Type
values but then we are not reusing them either.  RFC4379 is clear, that
each TLV has its own namespace of sub-TLV Type values.  What we are
doing is reusing the definition of a sub-TLV and assigning it a new
sub-TLV Type value under a different TLV.  The fact that the old sub-TLV
Type value is 'x' and the new sub-TLV Type value is also 'x' is most
convenient for us; perhaps the authors of RFC4379 had this in mind when
they limited the scope of sub-TLV Type values:-)

</tp>