Subject: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 17 Oct 2012 21:34:30 +0100

Hi,

I've done my usual AD review of your draft prior to issuing IETF last
call and passing the I-D for IESG evaluation. The main purpose of the
review is to catch issues that might come up in later reviews and to
ensure that the document is ready for publication as and RFC.

I found Section 4 very good. It completely explains to me what is 
going on in the protocol extension, and covered all the corner cases
I could think of. On the other hand, Section 3 made me generate a
really (really, really) long list of relatively minor issues. This 
list is so long that I think you need to provide a new revision
before we issue the IETF last call. I will put the I-D into "Revised
I-D Needed" state and wait for the revision.

As always, all my comments are up for discussion and negotiation.

Thanks for the work,
Adrian

===

Consistency of references for bidirectional LSP. In Section 1 you have
   In this document, term bidirectional LSP includes the co-routed
   bidirectional LSP defined in [RFC3945]
In Section 2 you have:
   The co-routed bidirectional LSP is defined in [RFC3471]
   and [RFC3473]

---

Section 1
s/(BFD)[RFC5880], [RFC5884]session/(BFD) [RFC5880], [RFC5884] session/
s/In this document, term bidirectional LSP/In this document, the term
bidirectional LSP/

---

Section 3.1

OLD
   The recommended value of the Reply via Specified Path mode is 5 (This
   is to be confirmed by the IANA).

       Value    Meaning
       -----    -------
           5     Reply via Specified Path
NEW
   The value of the Reply via Specified Path mode is 5 (This has been 
   allocated by IANA using early allocation and is to be confirmed by 
   IANA).

       Value    Meaning
       -----    -------
           5     Reply via Specified Path
END

---

Section 3.2

OLD
   The Reply Path (RP) TLV is an optional TLV, if the Reply via
   Specified Path mode requested, the Reply Path (RP) TLV MUST be
   included in an echo request message.  It carries the specified return
   paths that the echo reply message is required to follow.  The format
   of Reply Path TLV is as follows:

NEW
   The Reply Path (RP) TLV is an optional TLV within the LSP Ping 
   protocol.  However, if the Reply via Specified Path mode requested as
   described in Section 3.1, the Reply Path (RP) TLV MUST be included in
   an echo request message and its absence is treated as a malformed
   echo request as described in [RFC4379].  Furthermore, if a Reply Path
   (RP) TLV is included in an echo request message, a Reply Path (RP)
   TLV MUST be included in the corresponding echo reply message sent by
   an implementation that is conformant to this specification.
   
   The Reply Path (RP) TLV carries the specified return path that the 
   echo reply message is required to follow.  The format of Reply Path 
   TLV is as follows:
END

---

Section 3.2

OLD
   Reply Path TLV Type field is 2 octets in length, and the type value
   is TBD by IANA.
NEW
   Reply Path TLV Type field is 2 octets in length, and the type value
   is 21. (This has been allocated by IANA using early allocation and is
   to be confirmed by IANA).
END

---

Section 3.2

OLD
   Reply Path return code is 2 octets in length.  It is defined for the
   egress LSR of the forward LSP to report the results of Reply Path TLV
   processing and return path selection.  When sending echo request,
   these codes MUST be set to zero.  Reply Path return code only used
   when sending echo reply, and it MUST be ignored when processing echo
   request message.  This document defines the following Reply Path
   return codes:
NEW
   The Reply Path return code field is 2 octets in length.  It is 
   defined for the egress LSR of the forward LSP to report the results
   of Reply Path TLV processing and return path selection.  This field 
   MUST be set to zero in a Reply Path TLV carried on an echo request 
   message and MUST be ignored on receipt.  This document defines the 
   following Reply Path return codes for inclusion in a Reply Path TLV 
   carried on an echo reply:
END

---

Section 3.2

   Value         Meaning
   ------        ----------------------
   0x0000        No return code

What does "No return code" mean? I thought it might have been the value
that you should return if the TLV has been successfully processed but 
you seem to have 0x0003 for this. So, how is 0x0000 used?

---

Section 3.2

   0x0006        The Reply mode in echo request was not set to 5 (Reply
                 via Specified Path) although Reply Path TLV exists
   0x0007        Reply Path TLV was missing in echo request

Surely these are malformed echo requests and will be handled with 
normal echo replies with return code value 1.

---

Section 3.2

   The A bit and B bit set MUST NOT both be set, otherwise, an echo
   reply with the RP return code set to "Malformed RP TLV was received"
   SHOULD be returned.

What other options are there? I.e. why "SHOULD" not "MUST"?

---

Section 3.2

OLD
   The Reply Paths field is variable in length, not more than one sub-
   TLV MUST be carried, which describes the specified path that the echo
   reply message is required to follow.  When the Reply Mode field is
   set to "Reply via Specified Path" in an LSP echo request message, the
   Reply Path TLV MUST be present.  The Reply Path TLV SHALL only be
   used in the reply mode defined in this document (Reply via Specified
   Path).
NEW
   The Reply Paths field is variable in length and MUST contain zero or
   one sub-TLV.  The sub-TLV, if present, describes the specified path
   that the echo reply message is required to follow. 
END

---

Section 3.2
   
   When the Reply Mode field is set to "Reply via Specified Path" in an 
   LSP echo request message, the Reply Path TLV MUST be present.  

I think this is a duplication of a previous statement and can be removed

---

Section 3.2
   
   The Reply Path TLV SHALL only be 
   used in the reply mode defined in this document (Reply via Specified
   Path).

Why do you need this?  And can it be enforced?
It is very unusual to restrict the use of information in this way. I
understand that you do not have any other use in mind, but is there a 
need to make this constraint.

---

Section 3.3

   In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs
   is specified for Vendor Private Use, and MUST NOT be allocated.  This
   document changes that rule to make it not applicable to Reply Path
   TLV and redefines the rule as in Section 6.2 .  If an implementation
   recognizes any specific Vendor Private types as defined in [RFC4379],
   and uses the sub-TLV type specified in this document, care must be
   taken to ensure that the implementation does not confuse the two
   usages.

I don't think this draft changes the registry for 4379, does it?
This needs a little more care to separate the two uses clearly. How 
about...

OLD
   Each of the FEC sub-TLVs (include existing and future defined) for
   the Target FEC Stack TLV[RFC4379] is applicable to be a sub-TLV for
   inclusion in the Reply Path TLV for expressing a specific return
   path.  For these shared sub-TLVs, they share the same registry with
   the Target FEC Stack TLV for the range of 0-31743 and 32768-64511.

   In addition, this document defines three new sub-TLVs: IPv4 RSVP
   Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV and Static Tunnel sub-TLV.
   These sub-TLVs are only designed for Reply Path TLV, hence this
   document calls them dedicated sub-TLVs to Reply Path TLV.  For these
   dedicated sub-TLVs, this document will create a new registry (Section
   6.1), the sub-TLV type MUST be allocated from the new registry.
   Detailed definition is in the following sections.

   In [RFC4379], the range of 31744-32767 and 64512-65535 for sub-TLVs
   is specified for Vendor Private Use, and MUST NOT be allocated.  This
   document changes that rule to make it not applicable to Reply Path
   TLV and redefines the rule as in Section 6.2 .  If an implementation
   recognizes any specific Vendor Private types as defined in [RFC4379],
   and uses the sub-TLV type specified in this document, care must be
   taken to ensure that the implementation does not confuse the two
   usages.
NEW
   The FECs defined in [RFC4379] provide a good way to identify a
   specific return path.  The FEC sub-TLVs (including existing and
   future sub-TLVs) of the Target FEC Stack TLV [RFC4379] have sub-TLV
   types assigned from a registry with ranges as follows:

      0-16383       Standards Action mandatory TLV
      16384-31743   Specification Required, Experimental RFC needed
      31744-32767   Vendor Private Use, MUST NOT be allocated
      32768-49161   Standards Action optional TLV
      49162-64511   Specification Required, Experimental RFC needed
      64512-65535   Vendor Private Use, MUST NOT be allocated

   The Reply Path TLV can carry and sub-TLV defined for use in the
   Target FEC Stack TLV that can be registered.  Thus the ranges
   0-31743 and 32768-64511 are shared by the registries, with the new
   Reply Path Sub-TLVs registry "borrowing" values from the Target FEC
   Stack TLV registry.

   Allocations from the ranges 31744-32767 and 64512-65535 are not
   recorded in the registry for Target FEC Stack TLVs, so these ranges
   are safely made available in the Reply Path Sub-TLVs registry (see 
   Section 6.1) to record sub-TLVs that are specific to the Reply Path
   TLV.  This document defines three sub-TLVs specific to the Reply Path
   TLV: IPv4 RSVP Tunnel sub-TLV, IPv6 RSVP Tunnel sub-TLV, and Static 
   Tunnel sub-TLV. 

   Note that an implementation that supports specific Vendor Private 
   for sub-TLVs of the Target FEC Stack must take care to not confuse 
   those values with the same values allocated from the Reply Path Sub-
   TLVs registry.
END                                                        

---

Section 3.3

   2.  Specify a more generic tunnel FEC as return path

It is clear that 3.3.1 and 3.3.2 define a FEC that is more general than 
the FECs in 4379. What is not clear is the use case. I think you need 
some text in this document to say what you should do with one of these 
FECs since it possibly identifies a set of LSPs.

---

Section 3.3.1

OLD
   The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
   the recommended type value is TBD.
NEW
   The IPv4 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
   the recommended type value is TBD1.
END

---

Section 3.3.1

It is slightly weird that the bit field in this section allocates the
first two bits while the field in section 3.2 allocates the last two
bits.  This is not significantly important, but is odd.

---

Section 3.3.2

OLD
   The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
   the type value is TBD.
NEW
   The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and
   the type value is TBD2.
END

---

Section 3.3.3

RFC 6370 seems to also include an "LSP_Num". So your 3.3.3 case is the 
MPLS-TP static equivalent of 3.3.1. But you are missing:

- the MPLS-TP static equivalent of 3.3.2 (i.e. v6 identifiers)
- the MPLS-TP equivalent of the 4379 RSVP LSP FECs

Do you need them?

---

Section 3.3.3

OLD
   The sub-TLV type value is TBD.
NEW
   The sub-TLV type value is TBD3.
END

---

Section 3.4

OLD
   The Reply TC TLV Type field is 2 octets in length, and the type value
   is TBD.
NEW
   The Reply TC TLV Type field is 2 octets in length, and the type value
   is TBD4.
END

---

Section 4

   The procedures defined in this document currently only apply to
   "ping" mode.  The "traceroute" mode is out of scope for this
   document.

I think this should show up in the Introduction and possibly the
Abstract.

---

Section 6

Please consider whether you want registries for the bit fields you 
define in this document.

---

Section 6.1

OLD
   TBD     Reply TC TLV                      this document (sect 3.4)
NEW
   TBD4    Reply TC TLV                      this document (sect 3.4)
END

---

Section 6.4

OLD
   TBD     Reply TC TLV                      this document (sect 3.4)
NEW
   TBD4    Reply TC TLV                      this document (sect 3.4)
END

---

Section 6.2.1

OLD
   Sub-type      Value Field             Reference
   -------       -----------             ---------
   TBD           IPv4 RSVP Tunnel        this document (sect 3.3.1)
   TBD           IPv6 RSVP Tunnel        this document (sect 3.3.2)
   TBD           Static Tunnel           this document (sect 3.3.3)
NEW
   Sub-type      Value Field             Reference
   -------       -----------             ---------
   TBD1          IPv4 RSVP Tunnel        this document (sect 3.3.1)
   TBD2          IPv6 RSVP Tunnel        this document (sect 3.3.2)
   TBD3          Static Tunnel           this document (sect 3.3.3)
END

---

Section 6.3

OLD
   IANA is now requested to assign the previously assigned a new reply
   mode code point (5 - Reply via specified path) from the "Multi-
   Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
   Parameters" registry, the "Reply Mode" sub-registry on a permanent
   basis.
NEW
   IANA has made an early allocation (5 - Reply via specified path) from
   the "Multi-Protocol Label Switching (MPLS) Label Switched Paths 
   (LSPs) Ping Parameters" registry, the "Reply Mode" sub-registry. IANA
   is requested to make this allocation permanent.
END

---

From: Mach Chen <[email-masked]>
Date: Thu, 18 Oct 2012 08:55:46 +0000

Adrian,

Many thanks for your detail review and comments!

Please see my response inline...

Best regards,
Mach

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Adrian
> Farrel
> 发送时间: 2012年10月18日 4:35
> 收件人: [email-masked]
> 抄送: [email-masked]; [email-masked]
> 主题: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping
> 
> Hi,
> 
OK, will consistently refer to [RFC3945] instead.

> s/In this document, term bidirectional LSP/In this document, the term

OK.

>    is to be confirmed by the IANA).

OK.

>    echo reply message is required to follow.  The format of Reply Path

OK.

>    to be confirmed by IANA).

OK.

>    carried on an echo reply:

OK.

>    Value         Meaning

It should be named as "Reserved".

> normal echo replies with return code value 1.

Yes, indeed, will remove this two codes.

> What other options are there? I.e. why "SHOULD" not "MUST"?

Actually, there is no other options, MUST should be more precise.

> I think this is a duplication of a previous statement and can be removed

Yes.

> need to make this constraint.

This is for resolving one last call comment: how to handle the situation that a Reply Path TLV is carried but the reply mode is not set to 5, this should not be allowed (implicitly) so far and the echo request should be a Malformed message. 

I personally do not prefer to add this constraint, because we cannot guarantee that it will never be used in other modes in the future. I am OK to remove it. 

> This needs a little more care to separate the two uses clearly. How

I think it does not change the registry for 4379, but it does changes rule that RFC4379 specifies to TLVs and sub-TLVs. RFC4379 specifies that the range of 31744-32767 and 64512-65535 for sub-TLVs is specified for Vendor Private Use, this draft changes this. 

But I agree with your suggestion below :-)

>    The Reply Path TLV can carry and sub-TLV defined for use in the

Should the "carry and sub-TLV" be "carry the sub-TLV"?

> FECs since it possibly identifies a set of LSPs.

There is another draft (http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00#section-4.2 ) discusses the usage of the generic Tunnel sub-TLV. How about add the following text:

One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD session on an MPLS Tunnel that has primary and secondary LSPs, especially when Make-Before-Break (MBB) is deployed. The usage is discussed in the Section 4.2 of [I-D.chen-mpls-bfd-enhancement].

>    the recommended type value is TBD1.

OK.

> bits.  This is not significantly important, but is odd.

Will change it and make them consistent. 
>    The IPv6 RSVP Tunnel sub-TLV Type field is 2 octets in length, and

OK.

> - the MPLS-TP equivalent of the 4379 RSVP LSP FECs

No, we do not need them, MPLS-TP has not v6 identifiers, and the MPLS-TP equivalent of the 4379 RSVP LSP FECs belongs to the existing sub-TLVs of Target FEC TLV and are already defined in TP related RFC.

>    The sub-TLV type value is TBD3.
OK.

>    The Reply TC TLV Type field is 2 octets in length, and the type value

OK.

> I think this should show up in the Introduction and possibly the

OK.

>    TBD4    Reply TC TLV                      this document (sect 3.4)
OK

>    TBD4    Reply TC TLV                      this document (sect 3.4)
OK.

>    Sub-type      Value Field             Reference

OK.

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

---

From: t.petch <[email-masked]>
Date: Thu, 18 Oct 2012 16:05:58 +0100

Last November, I commented

"In retrospect, RFC4379 should have split the sub-TLV range into common
to all
TLV, and TLV-unique, which, in effect, is what my idea on 1024 is, post
factum.
I would expect others to comment on this as and when they realise what
it says,
so I would leave it for a while and see what comes up."

and I think that this has now come up.

Adrian says below
"> I think it does not change the registry for 4379, but it does changes
rule that RFC4379 specifies to TLVs and sub-TLVs."

and proposes that what in RFC4379 is
"The valid range for TLVs and sub-TLVs is 0-65535.  Assignments in the
   range 0-16383 and 32768-49161 are made via Standards Action as
   defined in [IANA]; assignments in the range 16384-31743 and
   49162-64511 are made via "Specification Required" as defined above;
   values in the range 31744-32767 and 64512-65535 are for Vendor
   Private Use, and MUST NOT be allocated."

becomes
"> >       0-16383       Standards Action mandatory TLV
> >       64512-65535   Vendor Private Use, MUST NOT be allocated"
which
a) seems to me to be not quite the same ie updates RFC4379
b) does not seem to solve the problem

(and there is no reference for RFC5226, but then that is usual for an
MPLS-TP RFC:-(

Tom Petch

----- Original Message -----
From: "Mach Chen" <[email-masked]>
To: <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, October 18, 2012 9:55 AM

> > 收件人:
[email-masked]
> > 主题: [mpls] AD review of
draft-ietf-mpls-return-path-specified-lsp-ping
> This is for resolving one last call comment: how to handle the
situation that a Reply Path TLV is carried but the reply mode is not set
to 5, this should not be allowed (implicitly) so far and the echo
request should be a Malformed message.
>
> I personally do not prefer to add this constraint, because we cannot
guarantee that it will never be used in other modes in the future. I am
OK to remove it.
> I think it does not change the registry for 4379, but it does changes
rule that RFC4379 specifies to TLVs and sub-TLVs. RFC4379 specifies that
the range of 31744-32767 and 64512-65535 for sub-TLVs is specified for
Vendor Private Use, this draft changes this.
> There is another draft
(http://tools.ietf.org/html/draft-chen-mpls-bfd-enhancement-00#section-4
.2 ) discusses the usage of the generic Tunnel sub-TLV. How about add
the following text:
>
> One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD
session on an MPLS Tunnel that has primary and secondary LSPs,
especially when Make-Before-Break (MBB) is deployed. The usage is
discussed in the Section 4.2 of [I-D.chen-mpls-bfd-enhancement].
> No, we do not need them, MPLS-TP has not v6 identifiers, and the
MPLS-TP equivalent of the 4379 RSVP LSP FECs belongs to the existing
sub-TLVs of Target FEC TLV and are already defined in TP related RFC.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Oct 2012 00:11:49 +0100

Hi Mach,

This looks good.

> Should the "carry and sub-TLV" be "carry the sub-TLV"?
Yes. Too many fingers error.

Otherwise I agree all your proposed changes and answers.

I'll look for the revised I-D and advance when I see it. Don't forget the
cut-off date!

Cheers,
Adrian

> -----Original Message-----
> From: Mach Chen [mailto:[email-masked]]
> Sent: 18 October 2012 09:56
> To: [email-masked]; draft-ietf-mpls-return-path-specified-lsp-
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: 答复: [mpls] AD review of
> This is for resolving one last call comment: how to handle the situation that
a
> Reply Path TLV is carried but the reply mode is not set to 5, this should not
be
> allowed (implicitly) so far and the echo request should be a Malformed
message.
> 
> I personally do not prefer to add this constraint, because we cannot guarantee
> that it will never be used in other modes in the future. I am OK to remove it.
> 
> >
> > ---
> >
> > Section 3.3
> >
> I think it does not change the registry for 4379, but it does changes rule
that
> RFC4379 specifies to TLVs and sub-TLVs. RFC4379 specifies that the range of
> 31744-32767 and 64512-65535 for sub-TLVs is specified for Vendor Private Use,
> this draft changes this.
> 
> There is another draft (http://tools.ietf.org/html/draft-chen-mpls-bfd-
> enhancement-00#section-4.2 ) discusses the usage of the generic Tunnel sub-
> TLV. How about add the following text:
> 
> One usage of this generic RSVP Tunnel sub-TLV is for bootstrapping BFD session
> on an MPLS Tunnel that has primary and secondary LSPs, especially when Make-
> Before-Break (MBB) is deployed. The usage is discussed in the Section 4.2 of
[I-
> D.chen-mpls-bfd-enhancement].
> 
> >
> > ---
> >
> > Section 3.3.1
> >
> > OLD
> No, we do not need them, MPLS-TP has not v6 identifiers, and the MPLS-TP
> equivalent of the 4379 RSVP LSP FECs belongs to the existing sub-TLVs of
Target
> FEC TLV and are already defined in TP related RFC.
> 
> >
> > ---
> >
> > Section 3.3.3
> >
> > OLD

---

From: Mach Chen <[email-masked]>
Date: Fri, 19 Oct 2012 01:30:09 +0000

Hi Tom,

Thanks for your comments!

Please see my reply inline...

Best regards,
Mach
> -----邮件原件-----
> 发件人: t.petch [mailto:[email-masked]]
> 发送时间: 2012年10月18日 23:06
> 收件人: Mach Chen; [email-masked];
> 主题: Re: [mpls] 4p84: AD review of

This above is actually proposed in RFC4379, this draft proposes to changes the rule for Reply Path TLV as follows:
   0-31743 - Reserved, and MUST NOT be allocated.
   31744-32767 - Allocated via Standards Action.
   32768-64511 - Reserved, and MUST NOT be allocated.
   64512-65531 - Allocated via Standards Action.
   65531-65535 - Experimental Use, and MUST NOT be allocated.

So the "common" range are 0-31743 and 32768-64511, and the dedicated ranges are 31744-32767 and 64512-65531 (they are originally defined as "Vendor Private Use", and now redefined as dedicated code ranges for a LSP Ping TLV ). And according to the guidance of RFC5226, there are only 4 code points (65531-65535) left for the Vendor Private Use(It's now called "Experimental Use" according some expert's suggestion).

So IMHO, the current rule is actually very close to your suggestion, the only difference is that the common range is not 1024.

> (and there is no reference for RFC5226, but then that is usual for an

We actually consider the guidelines in RFC5226, especially for the design of the "Experimental Use" range. Do you suggest to add an explicit reference to RFC5226? I am fine to do that. How about add the following text at the beginning of Section 6.2:

"According to the guidelines defined in [RFC5226], the sub-TLV range of Reply Path TLV are partitioned as following:"

Hope this resolved your comments!

Best regards,
Mach
> Tom Petch

Sniped

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Oct 2012 02:40:03 +0100

Whoa, no I don't propose a change to 4379 in this document.
If the WG wants to make a change to the 4379 registry, that is fine by me, but I
really don't think it should be sneaked (is the American word "snuck"?) through
on this draft.

>> to all TLV, and TLV-unique, which, in effect, is what my idea on 1024 is,
post
>> it says, so I would leave it for a while and see what comes up."
> 

Sort of. Yes.
Certainly this I-D wants some TLV-specific sub-TLVs

> rule that RFC4379 specifies to TLVs and sub-TLVs."

That quote is from Mach, not me.

> (and there is no reference for RFC5226, but then that is usual for an

Again, I was not proposing to change 4379 here, I was attempting to report what
I believed 4379 says using the shortcut of copying from the I-D I was reviewing.

I believe the only difference between the quoted text and my table is:
- the statement of mandatory
- the 2 statements of Experimental RFC required

I just checked the registy at
http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameter
s.xml#mpls-lsp-ping-parameters-7 and it seems to agree with me.

Cheers,
Adrian

---

From: Mach Chen <[email-masked]>
Date: Fri, 19 Oct 2012 02:46:02 +0000

Adrian,

Cool! I will try to submit the update before the deadline!

Thanks,
Mach

> -----邮件原件-----
> 发件人: Adrian Farrel [mailto:[email-masked]]
> 发送时间: 2012年10月19日 7:12
> 收件人: Mach Chen;
> 主题: RE: [mpls] AD review of draft-ietf-mpls-return-path-specified-lsp-ping
> 
> Hi Mach,
> 
> This looks good.
> 
> guarantee
> session

---

From: t.petch <[email-masked]>
Date: Fri, 19 Oct 2012 12:00:39 +0100

----- Original Message -----
From: "Mach Chen" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, October 19, 2012 2:30 AM

> Thanks for your comments!

You are too kind!

> This above is actually proposed in RFC4379,

Yes, my mistake; I had forgotten that RFC4379 redefined Specification
Required from the usual RFC5226 usage

>     this draft proposes to changes the rule for Reply Path TLV as
follows:
> So the "common" range are 0-31743 and 32768-64511, and the dedicated
ranges are 31744-32767 and 64512-65531 (they are originally defined as
"Vendor Private Use", and now redefined as dedicated code ranges for a
LSP Ping TLV ). And according to the guidance of RFC5226, there are only
4 code points (65531-65535) left for the Vendor Private Use(It's now
called "Experimental Use" according some expert's suggestion).
>
> So IMHO, the current rule is actually very close to your suggestion,
the only difference is that the common range is not 1024.

I think I understand.

But I do think that you are creating a new registry
MPLS-LSP-Ping Parameters - sub-TLVs for Reply Path TLV (Type 21)
(yuk - too cumbersome a name)

The allocation rules are different for sub-TLVs for other TLVs and I do
not see how IANA can fit that in without making it a distinct
(sub-)registry.  (I am not clear from the shepherd write-up whether or
not this has been run past IANA yet; if it has been then no problem -
else, obviously they will see it at IETF Last Call but it would be
better to fix it before then).

Arguably, this is an update to RFC4379 since that RFC did not
countenance there being different rules for the sub-TLVs of different
TLVs and as RFC4379 stands, would not allow what is now proposed, IMO.

Since you are using, I assume, the terms as defined in RFC5226, as
opposed to the variants defined in RFC4379, then I do think that you
need a reference to RFC5226.

And when you replied to Adrian
>    The Reply Path TLV can carry and sub-TLV defined for use in the
and said
Should the "carry and sub-TLV" be "carry the sub-TLV"?
I would think it should be carry any sub-TLV, which is somewhat
different.

Tom Petch

> We actually consider the guidelines in RFC5226, especially for the
design of the "Experimental Use" range. Do you suggest to add an
explicit reference to RFC5226? I am fine to do that. How about add the
following text at the beginning of Section 6.2:
>
> "According to the guidelines defined in [RFC5226], the sub-TLV range
of Reply Path TLV are partitioned as following:"

---

From: Loa Andersson <[email-masked]>
Date: Fri, 19 Oct 2012 19:20:18 +0200

Tom,

Speaking as the document shepherd for draft-ietf-mpls-return-
path-specified-lsp-ping:

The authors of draft-ietf-mpls-return-path-specified-lsp-ping have
requested assignments of TLV's and sub-TLV's based on how the "TLV
and sub-TLV" sub-registry of "Multi-Protocol Label Switching (MPLS)
Label Switched Paths (LSPs) Ping Parameters" registry has been set
up, i.e they have done exactly what they should do.

Thus, the comments on how this registry is structured should not have
any effect on how we progress 
draft-ietf-mpls-return-path-specified-lsp-ping.

Speaking as a MPLS working group co-chair:

I find your comments useful, the structure of the IANA registry is
not entirely intuitive. It was defined in RFC4379 and has been extended
several times, including by this draft. It is not reasonable to require
that draft-ietf-mpls-return-path-specified-lsp-ping is used to mend what
is not really broken, and I think we can progress the draft (modulo
Adrian's comments and comments we get in the IETF last call.

Speaking as an individual contributor:

If someone wants to write a draft to improve the set up and structure
of the registry/sub-registry that would be a good thing, that should be
discussed in the working group(s). I would be interested to contribute
to such a draft/work.

/Loa

-- 

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: t.petch <[email-masked]>
Date: Fri, 19 Oct 2012 19:02:36 +0100

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Mach Chen" <[email-masked]>; <[email-masked]>;
<[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, October 19, 2012 6:20 PM

Tom,

<tp>
Loa

I may be misunderstanding what is being proposed in this I-D (still:-(

When I look at the current IANA page for
MPLS - LSP - Ping Parameters - TLVs and sub-TLVs
it sets out ranges and allocation procedures for TLVs and sub-TLVs and
this currently applies to all TLVs and their sub-TLVs.

If I have understood what this I-D proposes, then the ranges and
allocation procedures for TLVs 1 to 20 remain unaltered, but a different
set of ranges and allocation procedures come into play for the new,
pre-allocated TLV, TLV 21.

If so, then two thoughts.  First, I would expect IANA to have to set up
a new section on the website, for the sub-TLVs of TLV 21, simply because
of this change to ranges and allocations.

Second, this would seem to me to be an update to RFC4379 (if you say
that it is not, then I will take your word for it).

Tom Petch

/Loa

--

---

From: Mach Chen <[email-masked]>
Date: Mon, 22 Oct 2012 01:45:18 +0000

Tom,

Thanks for your reply!

Many thanks,
Mach
> 发送时间: 2012年10月19日 19:01

I personally agree.

OK.

> I would think it should be carry any sub-TLV, which is somewhat

Agree.

Many thanks,
Mach