Skip to main content

Last Call Review of draft-ietf-mpls-lsp-ping-relay-reply-04

Request Review of draft-ietf-mpls-lsp-ping-relay-reply
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-10-13
Requested 2014-10-02
Authors Luo Jian , Lizhong Jin , Thomas Nadeau , George Swallow
I-D last updated 2014-10-09
Completed reviews Genart Last Call review of -04 by Joel M. Halpern (diff)
Genart Last Call review of -10 by Joel M. Halpern (diff)
Secdir Last Call review of -04 by Sean Turner (diff)
Opsdir Last Call review of -04 by Carlos Pignataro (diff)
Opsdir Last Call review of -10 by Carlos Pignataro (diff)
Rtgdir Early review of -10 by Andrew G. Malis (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Request Last Call review on draft-ietf-mpls-lsp-ping-relay-reply by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 11)
Result Not ready
Completed 2014-10-09
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mpls-lsp-ping-relay-reply-04
    Relayed Echo Reply mechanism for LSP Ping
Reviewer: Joel M. Halpern
Review Date: 8-October-2014
IETF LC End Date: 13-October-2014
IESG Telechat date: (if known)

Summary: This document is not ready for publication as a Proposed Standard

Major issues:

    There is either a major technical flaw in this document, or there 

is a need for significantly better explanation.  The following is what I 

was able to understand from reading the document.

    The procedure in the document calls for a responding or relaying 

LSR to search the response addresses from the top to the bottom (top 

being the originator of the request, bottom being visible originators). 

 The responder then sends the reply to the first usable address it can 

find in the stack.  Usable is variously described as "public routable" 

and as "routable" (in sections 4.2), the converse is described as 

"unroutable" in section 4.3, while section 4.4 uses "routable".

If it means "routable", then this assumes that the private addresses 

used by one AS will not happen to also be used in another AS (which 

would make them routable in that domain, directing the reply to 

completely the wrong place.

If it means "publicly routable", this would seem to fail since routers 

do not know whether routable addresses are public, private, or simply 

not martian.

Minor issues:

    The procedures assume that border routers will know the correct 

address to put in the reply stack.  It is not bovious that even if the 

router has a public address, it will get put on.  The requirement stated 

here is that the address put on be the same one used to originate the 

reply.  Which would seem likely to be na internal address in many cases.

    The procedure for setting k=0 allowing entries to be removed from 

the stack seems fragile.  It relies on routers being able to determine 

that their address will not be needed for relay by the next hop.

Nits/editorial comments:

   Some of the procedure for originating a reply is described in 

section 4.2 on Receiving a request, rather than in seciton 4.3 on 

originating the reply.  (Information such as the address to put on the 

stack, where it goes on the stack, and the handling of the reply packet 

being too large all belong in 4.3.)