Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Wed, 30 Jul 2014 19:43:43 +0000

Resending..

On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote:

>> 
>> Minor Issues: 
>> 
>> 1. Since the TTL TLV is defined for both MS-PW and bidirectional co-routed
>> LSP, it should be better to explicitly state this in the abstract section.
>> 
> 
> Sami: Sure will do.
> 
>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", "echo
>> request" and "request" are interchangeably used in the draft, it's better to
>> unify the usage of it to "MPLS echo request" (to align with the usage in
>> RFC4379). For "echo reply", "bidirectional co-routed LSP", they have the
>> similar issue.
>> 
> 
> Sami: Ok, will fix that.
> 
>> 3.Section 3.1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |   Value       |   Reserved    |   Flags                    |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> For the TTL TLV, the value filed should include the "value", "Reserved" and
>> "Flags", so it's better to change the "Value" field to "TTL" field hence to
>> reduce the confusion.
>> 
> 
> Sami: Sure.
> 
>> 4. Section 3.2
>> "This TLV shall be included in the echo request by the originator of
>>  request. The use of this TLV is optional. If a receiver does not
>>  understand the TTL TLV, it will simply ignore the TLV (Type value of
>>  TLV is assumed to be in the range of optional TLV's which SHOULD be
>>  ignored if an implementation does not support or understand them). In
>>  the absence of TTL TLV or if TTL TLV is ignored by a receiver, the
>>  determination of the TTL value used in the MPLS label on the echo
>>  reply is beyond the scope of this document."
>> 
>> What's your mean of "beyond the scope of this document" here? Is it to
>> apply the procedures defined in RFC4379 or just let it to the
>> implementation?I guess you assume to apply the definition in RFC4379,
> 
> Sami: It is out of scope of this document, but for sure procedure in 4379 apply.
>> if
> 
>> so, the TTL of the MPLS label will be more probably set to 255, means the
>> echo reply will be sent to the ingress of the MS-PW or LSP. I am not sure
>> whether this is the right procedure, it seems a security issue. IMHO, it
>> does not make any sense to expect the receiver to send echo reply in this
>> situation, and even sent, the initiator will not receive the reply. The
>> safer way is to drop the whole echo request and record an error log.
> 
> 
> Sami: 
> 
> We are not saying the receiver must send a reply, however if he does the reply
> may be received by the ingress node which might be the wrong node, since 
> the receiver may not set the TTL properly on the reply, keep in mind that this is 
> a receiver with an old implementation and the TLV is optional.
> 
> Please refer to the security section for your security concern.
> 
> Sami:
> 
> 
>> 
>> 5. Section 3.2
>> 
>> "In other words, if the value of the TTL provided by this TLV does not
>> match the TTL
>>  determined by other means, such as Switching Point TLV in MS-PW, then
>>  TTL TLV must be used."
>> Here, it implies that the receiver has to perform TTL matching process,
>> since how to set the TTL is independent of such matching, seems this
>> sentence is redundant and confusion.
>> 
> 
> Sami: Are you familiar with the switching point TLV? and what it includes?
> 
>> 6. Section 4.
>> 
>> "...The value field of the TTL TLV and the TTL field of the MPLS label are
>> set to 2,"
>> 
>> I guess that the MPLS Label is the PW label, right? It's better to add more
>> text to make this more explicit. In addition, how to set the TTL value of
>> the tunnel Label? 255 or any other value?
>> 
> 
> Sami: The tunnel label TTL is irrelevant here, however we will make it explicit that this is a PW label.
> 
>> 5. Section 4.1. Traceroute mode
>>  "In the traceroute mode TTL value in the TLV is successively set to 1,
>>  2, and so on. This is similar to the TTL values used for the label
>>  set on the packet."
>> IMHO, some text may be needed to clarify which "FEC" should be carried,
>> especially for MS-PW trace. Since in Section 4.0, the example says the FEC
>> of segment C-D should be carried, does it mean the FEC of last PW Segment of
>> the segment under test should be carried or the FEC will vary when TTL
>> changed. For example, when perform segment trace (e.g., to trace B-D
>> segment), when TTL is 1, which FEC should be carried?
> 
> Sami: 
> We are not here redefining  a trace route for a MS-PW, we are describing how our extensions will apply.
> Sami:
> 
>> 
>> 6. Section 4.2. Error scenario
>> For this scenario, do you need to define some error codes here?
> 
> Sami: 
> The section describe how to handle the error scenario, there is no need for an error code.
> Sami:
> 
>> 
>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if so,
>> it should be explicitly stated. If not, you should define how the MS-PW
>> trace works (given that the tunnels in both directions may span different
>> hops). 
> 
> Sami: 
> Not sure I get the concern? Again we are not re-defining how MS-PW trace work.
> 
> Thanks,
> 
> Sami
>> 
>> Nits: 
>> 
>> 1. Please check the text for acronyms that have not been expanded in their
>> first use.
>> 
>> 2. I run the idnits tool and found the following nits, please check and
>> fix. 
>>   (See RFCs 3967 and 4897 for information about using normative
>> references
>>    to lower-maturity documents in RFCs)
>> 
>> -- Looks like a reference, but probably isn't: 'RFC2119' on line 121
>> 
>> -- Looks like a reference, but probably isn't: 'RFC4379' on line 258
>> 
>> == Unused Reference: '1' is defined on line 284, but no explicit
>> reference
>>    was found in the text
>> 
>> == Unused Reference: '2' is defined on line 287, but no explicit
>> reference
>>    was found in the text
>> 
>> == Unused Reference: '3' is defined on line 291, but no explicit
>> reference
>>    was found in the text
>> 
>> 3. Section 3.2,
>> 3.1 first para first sentence
>> s/shall/SHALL
>> 3.2 last para, the last second sentence
>> s/must/MUST
>> 
>> 4. The draft quotes the MS-PW and bidirectional co-routed LSP concept, it's
>> better to add related references to this document.
>> 
>> 
>> Best regards,
>> Mach
>> 
>> 
>

---

From: Mach Chen <[email-masked]>
Date: Thu, 31 Jul 2014 03:45:56 +0000

Hi Sami,

Sorry for missing your last reply.

Thanks for considering my comments, and it resolved my comments.

Best regards,
Mach
> -----Original Message-----
> From: Sami Boutros (sboutros) [mailto:[email-masked]]
> Sent: Thursday, July 31, 2014 3:44 AM
> To: Mach Chen
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Loa Andersson
> Subject: Re: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt
> 
> Resending..
> 
> >> 1. Since the TTL TLV is defined for both MS-PW and bidirectional
> >> co-routed LSP, it should be better to explicitly state this in the abstract section.
> >>
> >
> > Sami: Sure will do.
> >
> >> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request",
> >> "echo request" and "request" are interchangeably used in the draft,
> >> it's better to unify the usage of it to "MPLS echo request" (to align
> >> with the usage in RFC4379). For "echo reply", "bidirectional
> >> co-routed LSP", they have the similar issue.
> >>
> >
> > Sami: Ok, will fix that.
> >
> >> 3.Section 3.1
> >> For the TTL TLV, the value filed should include the "value",
> >> "Reserved" and "Flags", so it's better to change the "Value" field to
> >> "TTL" field hence to reduce the confusion.
> >>
> >
> > Sami: Sure.
> >
> >> 4. Section 3.2
> >> What's your mean of "beyond the scope of this document" here? Is it
> >> to apply the procedures defined in RFC4379 or just let it to the
> >> so, the TTL of the MPLS label will be more probably set to 255, means
> >> the echo reply will be sent to the ingress of the MS-PW or LSP. I am
> >> not sure whether this is the right procedure, it seems a security
> >> issue. IMHO, it does not make any sense to expect the receiver to
> >> send echo reply in this situation, and even sent, the initiator will
> >> not receive the reply. The safer way is to drop the whole echo request and
> record an error log.
> >
> >
> > Sami:
> >
> > We are not saying the receiver must send a reply, however if he does
> > the reply may be received by the ingress node which might be the wrong
> > node, since the receiver may not set the TTL properly on the reply,
> > keep in mind that this is a receiver with an old implementation and the TLV is
> optional.
> >
> >> "In other words, if the value of the TTL provided by this TLV does
> >> not match the TTL  determined by other means, such as Switching Point
> >> TLV in MS-PW, then  TTL TLV must be used."
> >> Here, it implies that the receiver has to perform TTL matching
> >> process, since how to set the TTL is independent of such matching,
> >> seems this sentence is redundant and confusion.
> >>
> >
> >> "...The value field of the TTL TLV and the TTL field of the MPLS
> >> label are set to 2,"
> >>
> >> I guess that the MPLS Label is the PW label, right? It's better to
> >> add more text to make this more explicit. In addition, how to set the
> >> TTL value of the tunnel Label? 255 or any other value?
> >>
> >
> >>  "In the traceroute mode TTL value in the TLV is successively set to
> >> 1,  2, and so on. This is similar to the TTL values used for the
> >> label  set on the packet."
> >> IMHO, some text may be needed to clarify which "FEC" should be
> >> carried, especially for MS-PW trace. Since in Section 4.0, the
> >> example says the FEC of segment C-D should be carried, does it mean
> >> the FEC of last PW Segment of the segment under test should be
> >> carried or the FEC will vary when TTL changed. For example, when
> >> perform segment trace (e.g., to trace B-D segment), when TTL is 1, which FEC
> should be carried?
> >
> > Sami:
> >> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if
> >> so, it should be explicitly stated. If not, you should define how the
> >> MS-PW trace works (given that the tunnels in both directions may span
> >> different hops).
> >
> > Sami:
> >> 1. Please check the text for acronyms that have not been expanded in
> >> their first use.
> >>
> >> 2. I run the idnits tool and found the following nits, please check
> >> and fix.
> >> 3.2 last para, the last second sentence s/must/MUST
> >>
> >> 4. The draft quotes the MS-PW and bidirectional co-routed LSP
> >> concept, it's better to add related references to this document.
> >>
> >>
> >> Best regards,
> >> Mach
> >>
> >>
> >

---

From: Mach Chen <[email-masked]>
Date: Thu, 31 Jul 2014 03:59:49 +0000

Hi Himanshu,

I just rechecked my mailbox found that I sent out my comments on March 31, 2014, and received Sami's reply on May 15 and the reply was wrongly filtered into the Junk email folder, sorry for that :-)

Best regards,
Mach

> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Thursday, July 31, 2014 7:15 AM
> To: Sami Boutros (sboutros); Mach Chen
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt
> 
> This draft fills a major shortcoming of the VCCV ping over MS-PW (especially if
> reply mode is in-band).
> I am not sure why this draft is stuck (i.e. taking too long to go through).
> 
> Is there a provisional IANA assignment for the TTL TLV type value?
> 
> Thanks,
> himanshu
> 
> From: mpls [mailto:[email-masked]] On Behalf Of Sami Boutros
> (sboutros)
> Sent: Wednesday, July 30, 2014 3:44 PM
> To: Mach Chen
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt
> 
> Resending..
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 30 Jul 2014 19:15:16 -0400

This draft fills a major shortcoming of the VCCV ping over MS-PW (especially if reply mode is in-band).
I am not sure why this draft is stuck (i.e. taking too long to go through).

Thanks,
himanshu

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Sami Boutros (sboutros)
Sent: Wednesday, July 30, 2014 3:44 PM
To: Mach Chen
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt

Resending..

On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote:

>> not receive the reply. The safer way is to drop the whole echo request and record an error log.
> 
> 
> Sami: 
> 
> keep in mind that this is a receiver with an old implementation and the TLV is optional.
> 
>> perform segment trace (e.g., to trace B-D segment), when TTL is 1, which FEC should be carried?
> 
> Sami:

---

From: Loa Andersson <[email-masked]>
Date: Thu, 31 Jul 2014 14:07:48 +0200

Himanshu,

A request for early allocation need to come from the authors, to
wg-chairs and ADs.

The draft is through IETF Last call and has been updated, given that
ADrian is comfortable it will be on the IESG agenda shortly.

IANA has reviewed it and are OK.

Normally I would not ask for early allocation this late in the process.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 31 Jul 2014 09:14:38 -0400

Thanks Loa.
Early allocation request could have been made much earlier, but that is water under the bridge now.
I would still favor requesting for provisional IANA code allocation now.
This would allow interoperability of the ongoing implementations.

/himanshu

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 8:08 AM
To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt

Himanshu,

A request for early allocation need to come from the authors, to wg-chairs and ADs.

The draft is through IETF Last call and has been updated, given that ADrian is comfortable it will be on the IESG agenda shortly.

/Loa

On 2014-07-31 01:15, Shah, Himanshu wrote:
>>> it's better to unify the usage of it to "MPLS echo request" (to 
>>> align with the usage in RFC4379). For "echo reply", "bidirectional 
>>> "Reserved" and "Flags", so it's better to change the "Value" field 
>>> to "TTL" field hence to reduce the confusion.
>>>
>>
>> Sami: Sure.
>>
>>> 4. Section 3.2
>>> ignored if an implementation does not support or understand them). 
>>> In the absence of TTL TLV or if TTL TLV is ignored by a receiver, 
>>> the determination of the TTL value used in the MPLS label on the 
>>> echo reply is beyond the scope of this document."
>>>
>>> so, the TTL of the MPLS label will be more probably set to 255, 
>>> means the echo reply will be sent to the ingress of the MS-PW or 
>>> LSP. I am not sure whether this is the right procedure, it seems a 
>>> security issue. IMHO, it does not make any sense to expect the 
>>> receiver to send echo reply in this situation, and even sent, the 
>>> initiator will not receive the reply. The safer way is to drop the whole echo request and record an error log.
>>
>>
>> Sami:
>>
>> the reply may be received by the ingress node which might be the 
>> wrong node, since the receiver may not set the TTL properly on the 
>> reply, keep in mind that this is a receiver with an old implementation and the TLV is optional.
>>
>>> not match the TTL  determined by other means, such as Switching 
>>> Point TLV in MS-PW, then  TTL TLV must be used."
>>> add more text to make this more explicit. In addition, how to set 
>>> the TTL value of the tunnel Label? 255 or any other value?
>>>
>>
>>>   "In the traceroute mode TTL value in the TLV is successively set 
>>> to 1,  2, and so on. This is similar to the TTL values used for the 
>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, 
>>> if so, it should be explicitly stated. If not, you should define how 
>>> the MS-PW trace works (given that the tunnels in both directions may 
>>> span different hops).
>>
>> Sami:

--

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 31 Jul 2014 13:15:40 +0000

Hi Loa, Authors,

The code base which I'm familiar with already have shipped implementation of the TTL TLV, and it appears that the Type=0x8001 is being used.

I do not have the knowledge of why this value was used in this implementation without doing early IANA allocation for the TTL TLV code point.

If usage of Type=0x8001 as the TTL TLV does not conflict with any other implementations out there, is it possible to ask IANA to assign this value (0x8001) when the document progresses?

My apologies for causing extra burden on the authors, the Shepherd and the ADs.

But I truly hope that this request can be accommodated.

Thanks!

-Nobo

> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-
> 07.txt
> 
> Himanshu,
> 
> The draft is through IETF Last call and has been updated, given that ADrian is
> comfortable it will be on the IESG agenda shortly.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 31 Jul 2014 14:11:07 +0000

Nobo, and all,
0x8001 = 32769 falls in the "Unassigned" range of TLVs for LSP Ping. I think that it has been considered as safe enough to use by the implementers.
Somehow the relevant IANA registry does not provide any values for experimental use.

My 2c,
       Sasha 
Email: [email-masked]
Mobile: 054-9266302

> From: mpls [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
> Sent: Thursday, July 31, 2014 4:16 PM
> To: Loa Andersson; Shah, Himanshu; Sami Boutros (sboutros); Mach Chen
> The code base which I'm familiar with already have shipped implementation
> of the TTL TLV, and it appears that the Type=0x8001 is being used.
> 
> I do not have the knowledge of why this value was used in this
> implementation without doing early IANA allocation for the TTL TLV code
> point.
> 
> If usage of Type=0x8001 as the TTL TLV does not conflict with any other
> implementations out there, is it possible to ask IANA to assign this value
> (0x8001) when the document progresses?
> 
> > Cc: [email-masked];
> > [email-masked];
> > Subject: Re: [mpls] [RTG-DIR] RtgDir review:
> > draft-ietf-mpls-lsp-ping-ttl-tlv- 07.txt
> >
> > Himanshu,
> >
> > >>> co-routed LSP, it should be better to explicitly state this in the
> > >>> abstract
> > section.
> > >>>
> > >>
> > >> Sami: Sure will do.
> > >>
> > >>> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo
> > >>> request", "echo request" and "request" are interchangeably used in
> > >>> the draft, it's better to unify the usage of it to "MPLS echo
> > >>> request" (to align with the usage in RFC4379). For "echo reply",
> > >>> "bidirectional co-routed LSP", they have the similar issue.
> > >>>
> > >>
> > >> Sami: Ok, will fix that.
> > >>
> > >>> 3.Section 3.1
> > >>> "This TLV shall be included in the echo request by the originator
> > >>> of request. The use of this TLV is optional. If a receiver does
> > >>> not understand the TTL TLV, it will simply ignore the TLV (Type
> > >>> value of TLV is assumed to be in the range of optional TLV's which
> > >>> SHOULD be ignored if an implementation does not support or
> understand them).
> > >>> What's your mean of "beyond the scope of this document" here? Is
> > >>> it to apply the procedures defined in RFC4379 or just let it to
> > >>> the implementation?I guess you assume to apply the definition in
> > >>> RFC4379,
> > >>
> > >> Sami: It is out of scope of this document, but for sure procedure
> > >> in 4379
> > apply.
> > >>> if
> > >>
> > >>> initiator will not receive the reply. The safer way is to drop the
> > >>> whole
> > echo request and record an error log.
> > >>
> > >>
> > >> Sami:
> > >>
> > >> We are not saying the receiver must send a reply, however if he
> > >> does the reply may be received by the ingress node which might be
> > >> the wrong node, since the receiver may not set the TTL properly on
> > >> the reply, keep in mind that this is a receiver with an old
> > >> implementation and
> > the TLV is optional.
> > >>
> > >> Sami: The tunnel label TTL is irrelevant here, however we will make
> > >> it
> > explicit that this is a PW label.
> > >>
> > >>> to 1,  2, and so on. This is similar to the TTL values used for
> > >>> the label  set on the packet."
> > >>> example says the FEC of segment C-D should be carried, does it
> > >>> mean the FEC of last PW Segment of the segment under test should
> > >>> be carried or the FEC will vary when TTL changed. For example,
> > >>> when perform segment trace (e.g., to trace B-D segment), when TTL
> > >>> is 1, which
> > FEC should be carried?
> > >>
> > >> Sami:
> > >> We are not here redefining  a trace route for a MS-PW, we are
> > >> describing
> > how our extensions will apply.
> > >> Sami:
> > >>
> > >>>
> > >> The section describe how to handle the error scenario, there is no
> > >> need
> > for an error code.
> > >> Sami:
> > >>
> > >>>
> > >>> if so, it should be explicitly stated. If not, you should define
> > >>> how the MS-PW trace works (given that the tunnels in both
> > >>> directions may span different hops).
> > >>
> > >> Sami:
> > >>> 1. Please check the text for acronyms that have not been expanded
> > >>> in their first use.
> > >>>
> > >>> 2. I run the idnits tool and found the following nits, please
> > >>> check and fix.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 31 Jul 2014 16:29:36 +0200

Nobo,

If that is what you want, I can initiate the procedure to allocate that
code point.

/Loa

On 2014-07-31 16:20, Nobo Akiya (nobo) wrote:
> Hi Sasha,
>
> I wish that was the case :)
>
> https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#tlvs
>
> 32768-49161
> Standards Action
> This range is for optional TLVs that can be silently dropped if not recognized.
>
> Thanks,
> Nobo
>
>> From: Alexander Vainshtein [mailto:[email-masked]]
>> Sent: Thursday, July 31, 2014 10:11 AM
>> To: Nobo Akiya (nobo)
>> Cc: [email-masked]; [email-masked]; rtg-
>> [email-masked]; [email-masked]; Loa Andersson; Shah, Himanshu; Sami
>> Boutros (sboutros); Mach Chen
>> Subject: RE: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-
>> 07.txt
>>
>> Nobo, and all,
>> 0x8001 = 32769 falls in the "Unassigned" range of TLVs for LSP Ping. I think
>> that it has been considered as safe enough to use by the implementers.
>>> [email-masked]; rtg-
>>> [email-masked]; [email-masked]
>>> The code base which I'm familiar with already have shipped
>>> implementation of the TTL TLV, and it appears that the Type=0x8001 is
>> being used.
>>>
>>> implementation without doing early IANA allocation for the TTL TLV
>>> code point.
>>>
>>> If usage of Type=0x8001 as the TTL TLV does not conflict with any
>>> other implementations out there, is it possible to ask IANA to assign
>>> this value
>>>>> [email-masked]
>>>>>>> co-routed LSP, it should be better to explicitly state this in
>>>>>>> the abstract
>>>> section.
>>>>>>>
>>>>>>
>>>>>> Sami: Sure will do.
>>>>>>
>>>>>>> request", "echo request" and "request" are interchangeably used
>>>>>>> in the draft, it's better to unify the usage of it to "MPLS echo
>>>>>>> "Reserved" and "Flags", so it's better to change the "Value"
>>>>>>> field to "TTL" field hence to reduce the confusion.
>>>>>>>
>>>>>>
>>>>>> Sami: Sure.
>>>>>>
>>>>>>> 4. Section 3.2
>>>>>>> "This TLV shall be included in the echo request by the
>>>>>>> originator of request. The use of this TLV is optional. If a
>>>>>>> receiver does not understand the TTL TLV, it will simply ignore
>>>>>>> the TLV (Type value of TLV is assumed to be in the range of
>>>>>>> optional TLV's which SHOULD be ignored if an implementation does
>>>>>>> not support or
>>> understand them).
>>>>>>> In the absence of TTL TLV or if TTL TLV is ignored by a
>>>>>>> receiver, the determination of the TTL value used in the MPLS
>>>>>>> label on the echo reply is beyond the scope of this document."
>>>>>>>
>>>>>>> LSP. I am not sure whether this is the right procedure, it seems
>>>>>>> a security issue. IMHO, it does not make any sense to expect the
>>>>>>> receiver to send echo reply in this situation, and even sent,
>>>>>>> the initiator will not receive the reply. The safer way is to
>>>>>>> drop the whole
>>>>>> the wrong node, since the receiver may not set the TTL properly
>>>>>> on the reply, keep in mind that this is a receiver with an old
>>>>>> implementation and
>>>> the TLV is optional.
>>>>>>
>>>>>>> "In other words, if the value of the TTL provided by this TLV
>>>>>>> does not match the TTL  determined by other means, such as
>>>>>>> Switching Point TLV in MS-PW, then  TTL TLV must be used."
>>>>>>> process, since how to set the TTL is independent of such
>>>>>>> matching, seems this sentence is redundant and confusion.
>>>>>>>
>>>>>>
>>>>>>> I guess that the MPLS Label is the PW label, right? It's better
>>>>>>> to add more text to make this more explicit. In addition, how to
>>>>>>> set the TTL value of the tunnel Label? 255 or any other value?
>>>>>>>
>>>>>>
>>>>>> Sami: The tunnel label TTL is irrelevant here, however we will
>>>>>> make it
>>>>>>>    "In the traceroute mode TTL value in the TLV is successively
>>>>>>> set to 1,  2, and so on. This is similar to the TTL values used
>>>>>>> for the label  set on the packet."
>>>>>>> when perform segment trace (e.g., to trace B-D segment), when
>>>>>>> TTL is 1, which
>>>> FEC should be carried?
>>>>>>
>>>>>> Sami:
>>>>>> The section describe how to handle the error scenario, there is
>>>>>> no need
>>>> for an error code.
>>>>>> Sami:
>>>>>>
>>>>>>>
>>>>>>> 7. For MS-PW trace, seems that you assume the tunnel is pipe
>>>>>>> mode, if so, it should be explicitly stated. If not, you should
>>>>>>> define how the MS-PW trace works (given that the tunnels in both
>>>>>> Not sure I get the concern? Again we are not re-defining how
>>>>>> MS-PW
>>>> trace work.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Sami
>>>>>>>
>>>>>>> Nits:
>>>>>>>
>>>>>>> 1. Please check the text for acronyms that have not been
>>>>>>> expanded in their first use.
>>>>>>>

--

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 31 Jul 2014 14:20:30 +0000

Hi Sasha,

32768-49161
Standards Action

Thanks,
Nobo

---

From: Loa Andersson <[email-masked]>
Date: Thu, 31 Jul 2014 16:44:47 +0200

Nobo,

dam it - you are not an author of this document, so you can't request
the early allocation. If you think we should do it, tell one of the
authors to send me a mail.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 31 Jul 2014 16:50:50 +0200

Himanshu,

The process is that authors request through a mail to the wg chairs,
chairs initiate this by a mail to IANA and the ADs.

Get an author to send the request to wg-chairs.

/Loa

--

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 31 Jul 2014 14:51:01 +0000

Hi Loa,

Sorry about the confusion. I was requesting for a specific value to be allocated when the document progresses. But you are right, a better approach would be to initiate early IANA allocation to reserve that specific value, which should come from authors.

 I will reach out to the authors to send you an official request for early IANA allocation with specific value (0x8001) for the TTL TLV.

Thanks!

-Nobo

> Sent: Thursday, July 31, 2014 10:45 AM
> To: Nobo Akiya (nobo); Alexander Vainshtein
> Cc: [email-masked]; [email-masked]; Sami Boutros (sboutros); rtg-
> [email-masked]; [email-masked]
> dam it - you are not an author of this document, so you can't request the
> early allocation. If you think we should do it, tell one of the authors to send
> me a mail.
> 
> /Loa
> 
> > If that is what you want, I can initiate the procedure to allocate
> > that code point.
> >
> > /Loa
> >
> >> https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-
> pi
> >> ng-parameters.xhtml#tlvs
> >>
> >>
> >> 32768-49161
> >> Standards Action
> >>> From: Alexander Vainshtein
> [mailto:[email-masked]]
> >>> [email-masked]; [email-masked]; Loa Andersson; Shah, Himanshu;
> >>> Sami Boutros (sboutros); Mach Chen
> >>>> other implementations out there, is it possible to ask IANA to
> >>>> assign this value
> >>>>> The draft is through IETF Last call and has been updated, given
> >>>>> that ADrian is comfortable it will be on the IESG agenda shortly.
> >>>>>
> >>>>>>>> 1. Since the TTL TLV is defined for both MS-PW and
> >>>>>>>> bidirectional co-routed LSP, it should be better to explicitly
> >>>>>>>> state this in the abstract
> >>>>> section.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Sami: Sure will do.
> >>>>>>>
> >>>>>>>> in the draft, it's better to unify the usage of it to "MPLS
> >>>>>>>> echo request" (to align with the usage in RFC4379). For "echo
> >>>>>>>> reply", "bidirectional co-routed LSP", they have the similar issue.
> >>>>>>>>
> >>>>>>>
> >>>>>>> Sami: Ok, will fix that.
> >>>>>>>
> >>>>>>>> 3.Section 3.1
> >>>>>>>>
> >>>>>>>> optional TLV's which SHOULD be ignored if an implementation
> >>>>>>>> does not support or
> >>>> understand them).
> >>>>>>>> What's your mean of "beyond the scope of this document" here?
> >>>>>>>> Is it to apply the procedures defined in RFC4379 or just let it
> >>>>>>>> to the implementation?I guess you assume to apply the
> >>>>>>>> definition in RFC4379,
> >>>>>>>
> >>>>>>> Sami: It is out of scope of this document, but for sure
> >>>>>>> procedure in 4379
> >>>>> apply.
> >>>>>>>> if
> >>>>>>>
> >>>>>>>> means the echo reply will be sent to the ingress of the MS-PW
> >>>>>>>> or LSP. I am not sure whether this is the right procedure, it
> >>>>>>>> seems a security issue. IMHO, it does not make any sense to
> >>>>>>>> expect the receiver to send echo reply in this situation, and
> >>>>>>>> even sent, the initiator will not receive the reply. The safer
> >>>>>>>> way is to drop the whole
> >>>>>>> does the reply may be received by the ingress node which might
> >>>>>>> be the wrong node, since the receiver may not set the TTL
> >>>>>>> properly on the reply, keep in mind that this is a receiver with
> >>>>>>> an old implementation and
> >>>>> the TLV is optional.
> >>>>>>>
> >>>>>>>> "...The value field of the TTL TLV and the TTL field of the
> >>>>>>>> MPLS label are set to 2,"
> >>>>>>>>
> >>>>>>>> to add more text to make this more explicit. In addition, how
> >>>>>>>> to set the TTL value of the tunnel Label? 255 or any other value?
> >>>>>>>>
> >>>>>>>
> >>>>>>>> mean the FEC of last PW Segment of the segment under test
> >>>>>>>> should be carried or the FEC will vary when TTL changed. For
> >>>>>>>> example, when perform segment trace (e.g., to trace B-D
> >>>>>>>> define how the MS-PW trace works (given that the tunnels in
> >>>>>>>> both directions may span different hops).
> >>>>>>>
> >>>>>>> Sami:
> >>>>>>>>     (See RFCs 3967 and 4897 for information about using
> >>>>>>>> normative references
> >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC2119' on
> >>>>>>>> line
> >>>>>>>> 121
> >>>>>>>>
> >>>>>>>> -- Looks like a reference, but probably isn't: 'RFC4379' on
> >>>>>>>> line
> >>>>>>>> 258
> >>>>>>>>
> >>>>>>>> == Unused Reference: '1' is defined on line 284, but no
> >>>>>>>> explicit reference
> >>>>>>>>      was found in the text
> >>>>>>>>
> >>>>>>>> == Unused Reference: '2' is defined on line 287, but no
> >>>>>>>> explicit reference
> >>>>>>>>      was found in the text
> >>>>>>>>
> >>>>>>>> == Unused Reference: '3' is defined on line 291, but no
> >>>>>>>> explicit reference
> >>>>>>>>      was found in the text
> >>>>>>>>
> >>>>>>>> 3. Section 3.2,

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 31 Jul 2014 10:53:13 -0400

Sure. Thanks Loa..

(this is IETF.. we shouldn't get hung up on process thingy... :-))

/himanshu

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 10:51 AM
To: Shah, Himanshu; Sami Boutros (sboutros); Mach Chen
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt

Himanshu,

The process is that authors request through a mail to the wg chairs, chairs initiate this by a mail to IANA and the ADs.

/Loa

On 2014-07-31 15:14, Shah, Himanshu wrote:
> [email-masked]; [email-masked]
>>>> of request. The use of this TLV is optional. If a receiver does not 
>>>> understand the TTL TLV, it will simply ignore the TLV (Type value 
>>>> of TLV is assumed to be in the range of optional TLV's which SHOULD 
>>>> be ignored if an implementation does not support or understand them).

--

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Thu, 31 Jul 2014 14:53:26 +0000

Hi Loa,

(chiming in as a co-author)

Please could you do the needful to allocate the code-point.

Thanks Himanshu and Nobo for initiating this discussion.

Regards,
Siva

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 10:45 AM
To: Nobo Akiya (nobo); Alexander Vainshtein
Cc: [email-masked]; [email-masked]; Sami Boutros (sboutros); [email-masked]; [email-masked]
Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt

Nobo,

dam it - you are not an author of this document, so you can't request the early allocation. If you think we should do it, tell one of the authors to send me a mail.

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 31 Jul 2014 18:23:27 +0100

OK, I'm moving this forward now that we have a new revision (posted yesterday,
and a response from Mach today),

Please note that none of this is magic! To advance a document that is in review
you have to complete the discussion of review comments and post a revision. The
authors and shepherd are responsible for chasing down those comments: you can
come to the AD to handle issues of silence, but the AD cannot micro-manage all
of the documents and it doesn't help to ask why this has taken so long when no
update was posted.

Adrian

> Sent: 31 July 2014 00:15
> Cc: [email-masked]; [email-masked]; draft-ietf-mpls-lsp-ping-ttl-
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-mpls-lsp-ping-ttl-
> [email-masked]; [email-masked]
> > Sami: The tunnel label TTL is irrelevant here, however we will make it
explicit
> that this is a PW label.
> > The section describe how to handle the error scenario, there is no need for
an
> error code.