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

From: Mach Chen <[email-masked]>
Date: Wed, 18 Jul 2012 07:23:19 +0000

Hi Greg,

Many thanks for your comments!

Please see my reply inline...

Best regards,
Mach

> 
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Gregory Mirsky
> 发送时间: 2012年7月18日 8:49
> 收件人: [email-masked]
> 主题: Re: [mpls] working group las call on
> draft-ietf-mpls-return-path-specified-lsp-ping-05.txt
> 
> Dear Authors, et al.,
> Please consider my comments to the document as part of the WG LC:
> •       The document is focused on a mechanism to specify return path of
> LSP Ping Echo Request over LSP. However, LSP Ping can be used over PW VCCV
> (RFC 5085). Is extension of ability to specify LSP Ping return path in case of PW
> VCCV within document's scope?

Yes, it should be in the scope.

> •       LSP Ping Echo Reply is optional hence benefit of using Return Path
> TLV when bootstrapping BFD session over an LSP is somewhat limited.
> •       Section 3. Extensions
> “It carries the Forwarding Equivalence Class (FEC) information of the tested
> LSP …” Perhaps “of the LSP under test” or “of the LST being tested” will make
> it clearer whose FEC being used.

OK, thanks for the suggested text.

> •       Section 3.1 Consistent capitalization, e.g. “Reply via specified path”
> vs. “Reply Via Specified Path”.

OK, will check and make them consistent.

> •       Section 3.1 “The Reply Via Specified Path mode is used to notify the
> remote LSR receiving the LSP Ping echo request message to send …” I think
> that more accurate would be “The Reply Via Specified Path mode is used to
> request that the remote LSR receiving the LSP Ping echo request message
> sends …”

OK. 

> •       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."

> •       Section 3.2 Caption seems misplaced. Presented format, from the
> accompanying description, is of the Return Path TLV, not of PSN Tunnel sub-TLV.

Yes, good catch, will fix it.

> •       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).

> •       Section 3.2. When describing A (Alternative path) flag document
> refers to non-default return path though what is the default return path is not
> being defined.

> •       Section 3.2, last para. Document states that only one sub-TLV
> SHOULD be carried in the Reply Path TLV. There are valid scenarios when no
> sub-TLV is necessary but I don’t see any valid scenario hen more than one
> sub-TLV can be included. Would the following text be used “… not more than
> one sub-TLV MUST be carried …” If there are scenarios when more than one
> sub-TLV can be included into the RP TLV, then there should be explanation of
> how such situation managed by a receiver of Echo Request, whether there’s
> implicit priorities among multiple sub-TLVs.

Your suggestion of "… not more than one sub-TLV MUST be carried …" is more accurate, will use it.

> •       Section 4,second para. s/which enable/that enable/
OK.

> •       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. 

Best regards,
Mach

> 
>         Regards,
>                 Greg
> 
> 
> -------- Original Message --------
> Subject: working group las call on
> draft-ietf-mpls-return-path-specified-lsp-ping-05.txt
> Date: Mon, 09 Jul 2012 17:04:06 +0200
> From: Loa Andersson <[email-masked]>
> To: [email-masked] <[email-masked]>
> CC: [email-masked] <[email-masked]>,
> [email-masked]
> <[email-masked]>, Martin
> Vigoureux <[email-masked]>
> 
> Working Group,
> 
> this is to start a working group last call on
> 
> draft-ietf-mpls-return-path-specified-lsp-ping-05.txt
> 
> Please send your comments to the MPLS wg mailing list ([email-masked]).
> 
> This working group last call July 23, 2012.
> 
> Please note that there is an IPR disclosure against this draft.
> 
> /Loa
> for the MPLS working group co-chairs
> --
> 
> 
> 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
> 
> 
> --
> 
> 
> 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: Gregory Mirsky <[email-masked]>
Date: Wed, 18 Jul 2012 22:24:01 -0400

Hi Mach,
You're most welcome.
Couple of notes in-line and tagged by GIM>>.

        Regards,
                Greg

-----Original Message-----
From: Mach Chen [mailto:[email-masked]]
Sent: Wednesday, July 18, 2012 12:23 AM
To: Gregory Mirsky
Cc: [email-masked]
Subject: re: [mpls] working group las call on draft-ietf-mpls-return-path-specified-lsp-ping-05.txt

Hi Greg,

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").

[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?

> *       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.

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.

Best regards,
Mach

> <[email-masked]>,
> Martin Vigoureux <[email-masked]>
>
> Working Group,
>
> [email-masked] Sr Strategy and Standards Manager
> [email-masked] Ericsson Inc                          phone: +46 10 717 52
> 13
>                                               +46 767 72 92
> 13
>
>
> --
>
>
> 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
>
>
>
>