Hi,
This text is OK if one wants to implement this draft.
My concern was about the consistency of the IANA registration so that if
someone defines a new TLV type 1 based on RFC4379, IANA will know that it
must update also the registry for TLV type 21. If you see no such problem, I
have no concerns
Roni
-----Original Message-----
From: Mach Chen [mailto:mach(_dot_)chen(_at_)huawei(_dot_)com]
Sent: 29 August, 2013 1:05 PM
To: Roni Even; draft-ietf-mpls-return-path-specified-lsp-
ping(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org
Subject: RE: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-
ping-12
Hi Roni,
How about this:
" No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
are made directly for TLV Type 21, sub-TLVs in these ranges are
copied from the assignments made for TLV Type 1 and kept the same
as that for TLV Type 1. All sub-TLVs in these ranges (include existing
and future defined) defined for TLV Type 1 apply to TLV Type 21.
Assignments of sub-..."
Best regards,
Mach
-----Original Message-----
From: Roni Even [mailto:ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com]
Sent: Thursday, August 29, 2013 5:21 PM
To: Mach Chen;
draft-ietf-mpls-return-path-specified-lsp-ping(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org
Subject: RE: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-ping-12
Hi,
I am not sure you responded to my latest email.
Having the policy for TLV type 1 here is not enough in my view since I
only look at RFC4379 and create a new TLV type I will not know that I
have to register it also for the type 21 if it will not be mentioned
As for the vendor specific see my other email Roni
-----Original Message-----
From: Mach Chen [mailto:mach(_dot_)chen(_at_)huawei(_dot_)com]
Sent: 29 August, 2013 11:33 AM
To: Roni Even; draft-ietf-mpls-return-path-specified-lsp-
ping(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org
Subject: RE: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-
ping-12
Hi Roni,
Thanks for your detailed review and comments!
Please see my reply inline...
From: Roni Even [mailto:ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com]
Sent: Wednesday, August 28, 2013 9:06 PM
To:
draft-ietf-mpls-return-path-specified-lsp-ping(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org
Subject: Gen-ART LC review of
draft-ietf-mpls-return-path-specified-lsp-ping-12
I am the assigned Gen-ART reviewer for this draft. For background
on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call
comments you may receive.
Document: draft-ietf-mpls-return-path-specified-lsp-ping-12
Reviewer: Roni Even
Review Date:2013-8-28
IETF LC End Date: 2013-9-4
IESG Telechat date:
Summary: This draft is almost ready for publication as a standard
track
RFC.
Major issues:
Minor issues:
I am not clear on the sub-TLV in section 6.2 1. If a new sub-TLV
is defined for TLV type 1 do they need also to be added to TLV type
21.
This should be clear, and if there is some relation I think it
should be reflected in the IANA registry for TLV type 1
Yes, type 21 TLV intends to reuse existing and future defined
sub-TLVs for type TLV 1. And in Section 3.3, it has already stated
this, it
says:
"The Target FEC sub-TLVs defined in [RFC4379] provide a good way to
identify a specific return path. The Reply Path TLV can carry any
sub-TLV defined for use in the Target FEC Stack TLV that can be
registered."
So, for Section 6.2, to make it cleaner and more explicit, how about
this
change:
Old:
" No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
are made directly for TLV Type 21, sub-TLVs in these ranges are
copied from the assignments made for TLV Type 1. Assignments of
sub-..."
New:
" No assignments of sub-TLVs in the range of 0-16383 and 32768-49161
are made directly for TLV Type 21, sub-TLVs in these ranges are
copied from the assignments (including existing and future
allocations)
made for TLV Type 1. Assignments of sub-..."
2. For the vendor or private use why a difference policy than the
rest of the sub-TLV registry
This document does not make any changes to the "Vendor and Private
use"
definition, range and policy as defined in RFC4379. In RFC4379, it's
policy is
defined different from other ranges.
Nits/editorial comments:
1. In section 3.4 I assume that "TC" is traffic class. It will be
good to expand and have reference.
OK, will fix it when all last call comments received.
Best regards,
Mach