Subject: [mpls] 答复: working group las call on draft-ietf-mpls-return-path-specified-lsp-ping-05.txt

From: Mach Chen <[email-masked]>
Date: Fri, 20 Jul 2012 02:57:22 +0000

Hi Greg,

Thanks for your prompt response!

Please see inline...

Best regards,
Mach

[snip]

> > •       Section 3.2 “The Reply Path (RP) TLV is optionally included in
> > an echo request message”. Would the following be more accurate “If the
> > Reply Via Specified Path mode requested, the Reply Path (RP) TLV must
> > be included in an echo reply message”.
> 
> OK. How about "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."
> GIM>> Works well. Can it besplit into two sentences "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." (I was suggested not
> to capitalize "via").

OK.

> 
> [snip]
> > •       Section 3.2 lists Reply Path return codes but I don’t see how
> > these are administered. The field is 2 octets length and only eight
> > values being defined in the document. How remaining 65528 values
> > partitioned and assigned? And I’d suggest to present defined values as
> > u_int16, e.g. 0x0000, 0x0001, etc.
> 
> OK, and will add text to describe the remaining range (e.g., 0x0008-0xffff --
> Reserved for future extensions).
> GIM>> Would you consider a request to IANA to create a new registry to
> administer allocation?

OK, will add a new sub-section to IANA section for this.

> 
> > •       Section 6.2 AFAIK, values from Vendor Private Use, according
> > to RFC 4379, as to common practice, MUST NOT be allocated. I think it
> > would be better to seek allocation for new sub-TLVs from IANA’s
> > Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
> > Parameters registry for TLVs and sub-TLVs.
> 
> There are two registries: one is for Target FEC Stack TLV and it sub-TLVs, which
> is defined in RFC4379 and this draft will not define new rules to it and require
> any allocation from it. For the Reply Path TLV and its sub-TLVs, this draft
> requires to assign a new registry for TLVs and sub-TLVs. They are totally
> different registries.
> 
> The range of new registry defined in this draft is divided into two parts: range
> of 31744-32767 is a normal "Standard action" range for Reply Path TLV and its
> sub-TLVs, the rest MUST be kept as the same as the registry of Target FEC
> Stack TLV. This is because, as explained in the draft, the Reply Path TLV is
> designed to share all existing and new future defined sub-TLVs of Target FEC
> Stack TLV, that means the part overlaps with the "Standard Action" and
> "Specification Required" ranges of Target FEC Stack TLV and sub-TLVs registry
> cannot be allocated to the new defined sub-TLVs of Reply Path TLV, otherwise,
> allocation confliction cannot be avoided. So this draft introduces a "tricky"
> solution, it defines the range of 31744-32767 ( this range for Target FEC Stack
> TLV belongs to Vender Private range and will be allocated to any standard and
> specification required extensions) as the normal range, thus avoid the potential
> allocation conflicting.
> 
> Hope this makes it clearer.
> GIM>> Thank you for detailed explanation. If you decide to follow with the
> proposed schema, then you need to specify how you'd like Type space
> partitioned and administered for new sub-TLV registry. E.g., "0-31743 -
> Unavailable; 31744-32767 - Standards Action; 32768-64511 - Unavailable;
> 64512-65535 - Standards Action".
> But I think that you might re-use sub-TLVs under new TLV. You grandfather
> sub-TLVs from Target FEC TLV list that you need, e.g. FEC 129. Create a buffer
> for future expansion of the Target FEC TLV and allocate yours. For the most
> safety from overlapping might be to allocate new IDs from 32768-49161 range.

How about this?

0-31743 - This range MUST be kept as the same as Target FEC Stack TLV and sub-TLVs[RFC4379].
31744-32767 - Standards Action;
32768-64511 - This range MUST be kept as the same as Target FEC Stack TLV and sub-TLVs[RFC4379].
64512-65535 - Standards Action.

With this, the sub-TLVs(including existing and future defined) of Target FEC Stack TLV can be automatically re-used by Reply Path TLV, and there will not be any overlapping issue. 

Best regards,
Mach