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

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

Hi Adrian -
By no means I was wondering about the delay in review process.
Sorry if it came off that way.
I was surprised about the overall time and the number of revisions that it went through.

/himanshu

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, July 31, 2014 1:23 PM
To: Shah, Himanshu; '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

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

> -----Original Message-----
> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: 31 July 2014 00:15
> To: Sami Boutros (sboutros); Mach Chen
> Cc: [email-masked]; [email-masked]; draft-ietf-mpls-lsp-ping-ttl- 
> [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
> 
> -----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]; draft-ietf-mpls-lsp-ping-ttl- 
> [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:
> 
> >>
> >> 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
> >>
> >>
> >
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls