Subject: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-lsp-ping-relay-reply

From: Loa Andersson <[email-masked]>
Date: Thu, 05 Jun 2014 07:20:42 +0200

Working Group,

draft-ietf-mpls-lsp-ping-relay-reply is in a working group last
call that was intended to be closed last Monday (June 2nd).

Hopwever, there has not be a single response!

I cn't make up my mind how to interprete this - either the wg have
lost interest in the draft (which would surprise me greatly) or
everybody thinks the draft is perfect (which would also be a surprise).

I will therefore extend the wglc until June 16 and invite also positive
responses (e.g. "I think this document is ready for publication!").

/Loa
for the wg chairs

On 2014-05-19 11:49, Loa Andersson wrote:
> Working Group,
>
> This is to initiate a working group last call on
> draft-ietf-mpls-lsp-ping-relay-reply.
>
> There are two IPR disclosures against this document. The author has
> stated that he is unaware of any other IPRs that relate to this
> document.
>
> Please send your comments to the mpls wg mailing list ([email-masked]).
>
> This working group last call ends June 2, 2014.
>
> /Loa
> for the MPLS wg chairs

-- 

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

---

From: [email-masked]
Date: Thu, 5 Jun 2014 14:57:09 +0800

support

Loa Andersson <[email-masked]> 
发件人:  "mpls" <[email-masked]>
2014-06-05 13:20

收件人
"[email-masked]" <[email-masked]>
抄送
"<[email-masked]>", "[email-masked]" 
<[email-masked]>, 
"[email-masked]" 
<[email-masked]>
主题
[mpls] Still Open - Re: Working group last call on 
draft-ietf-mpls-lsp-ping-relay-reply

Working Group,

/Loa
for the wg chairs

-- 

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 6 Jun 2014 21:15:25 +0000

Hi Loa, Authors,

I have some comments and questions (and my apologies if questions have already been answered before).

Section 3.2:

   The K bit may be set by ASBRs whose address would be
   kept in the stack if necessary.

This is the only statement that I found regarding how responder is to decide the setting of the K bit. I read it as "Set K bit if I'm likely to be a relay point". I understand the motive behind this bit, but realistically it seems a bit difficult to use, i.e. unless responder has some topology awareness, it's just simpler to just to set the K bit. Can you provide more thoughts on exactly how you intended to use this bit?

On a related note, I did not find any texts around usage of K bit and Unspecified Address Type, which probably should be considered invalid. If you agree, it would be good to add texts to enforce this.

Section 4.2:

   , and
   the address entry of the replying LSR MUST be added at the bottom of
   the stack.

The loop prevention paragraph in section 4.4 has a strict check that received source IP address must be found in the address stack of the Relay Node Address Stack TLV. In that case, above statement in section 4.2 should be tightened that source IP address of transmitted packet must be used as the "address entry of the replying LSR". Otherwise valid reply may be dropped by a relay node.

Section 4.2:

   If the replying LSR is configured to hide its routable address
   information, the address entry added in the stack SHOULD be a blank
   entry with Address Type set to unspecified.  The blank address entry
   in the receiving Echo Request SHOULD be treated as an unroutable
   address entry.

What's the point of adding a blank entry (i.e. Unspecified Address Type)? I suppose the purpose of this is to let the initiator know the responder is intentionally hiding it's local address, but is that really necessary? If so, what's the point of initiator preserving this blank entry in the Relay Node Address Stack TLV in the next Echo Request, just to be deleted by the next responder node?

Section 4.4:

I didn't see any texts describing what the source IP address of the packet sent by receiver of Relayed Echo Reply. I'm guessing that we cannot copy received source IP address as the source IP address of transmitting Echo Reply or further Relayed Echo Reply, since that will break the loop prevention proposed in Section 4.4. However, if we are not preserving the source IP address from the original responder node, then there's an impact to traceroute implementations as they usually print out received source IP addresses (which no longer will be responder addresses).

Initiator could do:

    If (Relay Node Address Stack TLV) {
        Print last address in the stack
    } else {
        Print source IP address
    }

But if the last address in the stack was Unspecified, then traceroute result now can become weaker than it used to be.

Alternatively you could do:

(1) Preserve the source IP address in received Relayed Echo Reply to transmitting Echo Reply or Relay Echo Reply.
(2) Add one more condition in the loop prevention check. If the first routable address in the Relay Node Address Stack TLV is self, then drop.

Not sure if RPF check would be a concerning point, but if not, above should work and traceroute will remain the same as today. And if you go via this, then source IP address will always be what would have been placed in the Relay Node Address Stack TLV by the responder. In that case, the purpose of Unspecified Address Type becomes questionable.

General:

The document does not say that Proxy Ping is outside the scope, however I think a bit of additions are needed to make this work with Proxy Ping. For example, first address in the Relay Node Address Stack TLV should be Proxy sender, and Proxy receiver (i.e. Echo Request sender) will need to follow the Relay Node Address Stack TLV update procedure just like receiver of Echo Request.

General:

Any reason why TTL is not copied from received Relay Echo Reply to transmitting Echo Reply or Relay Echo Reply?

Thanks!

-Nobo

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Thursday, June 05, 2014 1:21 AM
> To: [email-masked]
> Cc: <[email-masked]>; [email-masked]; draft-ietf-mpls-
> [email-masked]
> Subject: [mpls] Still Open - Re: Working group last call on draft-ietf-mpls-
> lsp-ping-relay-reply
> 
> Working Group,
> 
> draft-ietf-mpls-lsp-ping-relay-reply is in a working group last call that was
> intended to be closed last Monday (June 2nd).
> 
> I cn't make up my mind how to interprete this - either the wg have lost
> interest in the draft (which would surprise me greatly) or everybody thinks
> the draft is perfect (which would also be a surprise).
>

---

From: "Lizhong Jin" <[email-masked]>
Date: Sun, 8 Jun 2014 17:22:43 +0800

Hi Nobo,
Thank you for the detail review. See inline below.

Regards
Lizhong

> From: Nobo Akiya (nobo) [mailto:[email-masked]]
> Sent: 2014年6月7日 5:15
> To: Loa Andersson; [email-masked]
> Subject: RE: [mpls] Still Open - Re: Working group last call on
draft-ietf-mpls-
> This is the only statement that I found regarding how responder is to
decide
> the setting of the K bit. I read it as "Set K bit if I'm likely to be a
relay point". I
> understand the motive behind this bit, but realistically it seems a bit
difficult
> to use, i.e. unless responder has some topology awareness, it's just
simpler
> to just to set the K bit. Can you provide more thoughts on exactly how you
> intended to use this bit?
[Lizhong] In a network with multiple ASs, and only ASBRs or border nodes are
the potential relay nodes. This maybe the most common case. The original
thought is to let all ASBRs to be relay node, and the initiator could
discover the ASBR list. So it is suggested to let ASBR (or border node) to
set K bit as a node wide configuration. But we did not restrict other nodes
to set K bit.

> 
> On a related note, I did not find any texts around usage of K bit and
> Unspecified Address Type, which probably should be considered invalid. If
> you agree, it would be good to add texts to enforce this.
[Lizhong] The usage and protocol operation of K bit and Unspecified Address
Type is described in section 4.2. I did not quite get this comment, could
you give more detail.

> The loop prevention paragraph in section 4.4 has a strict check that
received
> source IP address must be found in the address stack of the Relay Node
> Address Stack TLV. In that case, above statement in section 4.2 should be
> tightened that source IP address of transmitted packet must be used as the
> "address entry of the replying LSR". Otherwise valid reply may be dropped
by
> a relay node.
[Lizhong] accepted. Should be tightened that the address added in Relay Node
Address Stack TLV MUST be the source IP address of Relay Echo Reply or Echo
Reply message.

> What's the point of adding a blank entry (i.e. Unspecified Address Type)?
I
> suppose the purpose of this is to let the initiator know the responder is
> intentionally hiding it's local address, but is that really necessary? If
so, what's
> the point of initiator preserving this blank entry in the Relay Node
Address
> Stack TLV in the next Echo Request, just to be deleted by the next
responder
> node?
[Lizhong] not only deleted by the next responder, if the replying LSR is a
relayed node, and reply with unspecified address, then the  unspecified
address will not be deleted by the compress process. As a result, the
relayed echo reply will not be successfully sent back to initiator. Security
concern is the main motivation of setting Unspecified Address Type, since
Ping with Relayed Echo Rely could trace every node across domains. If trace
is only used for trouble shooting, in many cases, these hiding LSR will not
influence success of the trouble shooting if they are not relayed node.

> 
> 
> Section 4.4:
> 
> I didn't see any texts describing what the source IP address of the packet
> sent by receiver of Relayed Echo Reply. I'm guessing that we cannot copy
> received source IP address as the source IP address of transmitting Echo
> Reply or further Relayed Echo Reply, since that will break the loop
prevention
> proposed in Section 4.4. However, if we are not preserving the source IP
> address from the original responder node, then there's an impact to
> traceroute implementations as they usually print out received source IP
> addresses (which no longer will be responder addresses).
> 
> Initiator could do:
> 
> But if the last address in the stack was Unspecified, then traceroute
result
> now can become weaker than it used to be.
> 
> (1) Preserve the source IP address in received Relayed Echo Reply to
> transmitting Echo Reply or Relay Echo Reply.
> (2) Add one more condition in the loop prevention check. If the first
routable
> address in the Relay Node Address Stack TLV is self, then drop.
> 
> Not sure if RPF check would be a concerning point, but if not, above
should
> work and traceroute will remain the same as today. And if you go via this,
> then source IP address will always be what would have been placed in the
> Relay Node Address Stack TLV by the responder. In that case, the purpose
of
> Unspecified Address Type becomes questionable.
[Lizhong] The initiator should print last address in the stack, we should
add this in the text. It could say weaker than legacy traceroute from
address displaying point of view. But traceroute is now working in a
multi-domain case. Hiding address should be allowed if desired, under the
condition that trouble shooting could still be possible. Then we could say
the new traceroute is stronger than legacy from trouble shooting point of
view.  

> 
> 
> General:
> 
> The document does not say that Proxy Ping is outside the scope, however I
> think a bit of additions are needed to make this work with Proxy Ping. For
> example, first address in the Relay Node Address Stack TLV should be Proxy
> sender, and Proxy receiver (i.e. Echo Request sender) will need to follow
the
> Relay Node Address Stack TLV update procedure just like receiver of Echo
> Request.
[Lizhong] right, but it seems draft-relay-reply moves faster than
draft-proxy-lsp-ping. It would be more reasonable to add the suggested text
to draft-proxy-lsp-ping, right? I could talk this with author of
draft-proxy-lsp-ping and chair. Thanks.

> 
> 
> General:
> 
> Any reason why TTL is not copied from received Relay Echo Reply to
> transmitting Echo Reply or Relay Echo Reply?
[Lizhong] this is a missing part, and should be added. I think copy is the
right behavior. Thanks.

Regards
Lizhong

> > Cc: <[email-masked]>; [email-masked];
> > draft-ietf-mpls- [email-masked]
> > Subject: [mpls] Still Open - Re: Working group last call on
> > draft-ietf-mpls- lsp-ping-relay-reply
> >
> > Working Group,
> >
> > draft-ietf-mpls-lsp-ping-relay-reply is in a working group last call
> > that was intended to be closed last Monday (June 2nd).
> >
> > I will therefore extend the wglc until June 16 and invite also
> > positive responses (e.g. "I think this document is ready for
publication!").

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 8 Jun 2014 14:04:47 +0000

Hi Lizhong,

Thanks for considering my comments.

Please see-inline.

> From: Lizhong Jin [mailto:[email-masked]]
> Sent: Sunday, June 08, 2014 5:23 AM
> To: Nobo Akiya (nobo); 'Loa Andersson'; [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-mpls-lsp-
> [email-masked]
> Subject: RE: [mpls] Still Open - Re: Working group last call on draft-ietf-
> mpls-lsp-ping-relay-reply
> 
> Hi Nobo,
> > to just to set the K bit. Can you provide more thoughts on exactly how
> > you intended to use this bit?
> [Lizhong] In a network with multiple ASs, and only ASBRs or border nodes
> are the potential relay nodes. This maybe the most common case. The
> original thought is to let all ASBRs to be relay node, and the initiator could
> discover the ASBR list. So it is suggested to let ASBR (or border node) to set
> K bit as a node wide configuration. But we did not restrict other nodes to set
> K bit.	

There's a slight conflict then. If the intention of the K bit is to let the initiator discover ASBRs, then we should have a text that says ASBRs SHOULD set the K bit and non-ASBRs MUST NOT set the K bit. Otherwise non-ASBRs setting the K bit can give wrong information to the initiator. However, if the intention has become more loose (i.e. any node who wants to remain in the TLV as the relay node), then perhaps a short text would be helpful. Something like:

   Having the K bit set on the relay node address entry causes that
   entry to be preserved in the Relay Node Address Stack TLV for the
   entire traceroute operation.  A responder node MAY set the K bit to
   ensure its relay node address entry remains as one of the relay nodes
   in the Relay Node Address Stack TLV.  Some nodes (ex: ASBR) could be
   configured to always set the K bit, or the module handling MPLS echo
   requests could discover its K bit use through topology awareness.
   How a node determines to set the K bit is outside the scope of this
   document.

> > Unspecified Address Type, which probably should be considered invalid.
> > If you agree, it would be good to add texts to enforce this.
> Type is described in section 4.2. I did not quite get this comment, could you
> give more detail.

What I meant was, do we ever want a relay node address entry that has K bit set _and_ is Unspecified Address Type? It seems that will just waste space in the Relay Node Address Stack TLV (and on the wire). I was just asking if there's any reason why K bit & Unspecified combination is not restricted.

> > Address Stack TLV. In that case, above statement in section 4.2 should
> > be tightened that source IP address of transmitted packet must be used
> > as the "address entry of the replying LSR". Otherwise valid reply may
> > be dropped
> by
> > a relay node.
> [Lizhong] accepted. Should be tightened that the address added in Relay
> Node Address Stack TLV MUST be the source IP address of Relay Echo Reply
> or Echo Reply message.

Thanks.

> > suppose the purpose of this is to let the initiator know the responder
> > is intentionally hiding it's local address, but is that really
> > necessary? If
> so, what's

Ok, based on your answers above and below, blank entry makes sense. Although I don't see the point of allowing a blank entry have a K bit set.

> 
> >
> >
> > Section 4.4:
> >
> > I didn't see any texts describing what the source IP address of the
> > packet sent by receiver of Relayed Echo Reply. I'm guessing that we
> > cannot copy received source IP address as the source IP address of
> > transmitting Echo Reply or further Relayed Echo Reply, since that will
> > break the loop
> prevention
> > proposed in Section 4.4. However, if we are not preserving the source
> > IP address from the original responder node, then there's an impact to
> > traceroute implementations as they usually print out received source
> > IP addresses (which no longer will be responder addresses).
> >
> > Initiator could do:
> >
> > work and traceroute will remain the same as today. And if you go via
> > this, then source IP address will always be what would have been
> > placed in the Relay Node Address Stack TLV by the responder. In that
> > case, the purpose
> of
> [Lizhong] The initiator should print last address in the stack, we should add
> this in the text. It could say weaker than legacy traceroute from address
> displaying point of view. But traceroute is now working in a multi-domain
> case. Hiding address should be allowed if desired, under the condition that
> trouble shooting could still be possible. Then we could say the new
> traceroute is stronger than legacy from trouble shooting point of view.

Ok in that case, please add texts for:
- Source IP address in Echo Reply and Relay Echo Reply are to be of the address of the node sending those packets (i.e. not copied from received Relay Echo Reply).
- Traceroute address output module will need to conditionally print the address in the Relay Node Address Stack TLV.

> 
> >
> >
> > General:
> >
> > The document does not say that Proxy Ping is outside the scope,
> > however I think a bit of additions are needed to make this work with
> > Proxy Ping. For example, first address in the Relay Node Address Stack
> > TLV should be Proxy sender, and Proxy receiver (i.e. Echo Request
> > sender) will need to follow
> the
> > Relay Node Address Stack TLV update procedure just like receiver of
> > Echo Request.
> [Lizhong] right, but it seems draft-relay-reply moves faster than draft-proxy-
> lsp-ping. It would be more reasonable to add the suggested text to draft-
> proxy-lsp-ping, right? I could talk this with author of draft-proxy-lsp-ping
> and chair. Thanks.

Ah right, I forgot that Proxy has not become RFC yet. Yes I think that'll be a good idea to make sure to raise this point to Proxy authors and chairs so that it gets on some "todo list".

> [Lizhong] this is a missing part, and should be added. I think copy is the right
> behavior. Thanks.

Agree.

Thanks!

-Nobo

> > > > There are two IPR disclosures against this document. The author
> > > > has stated that he is unaware of any other IPRs that relate to
> > > > this document.
> > > >

---

From: "Lizhong Jin" <[email-masked]>
Date: Mon, 9 Jun 2014 09:55:51 +0800

Hi Nobo,
Thanks for the quick reply. See inline below.

Regards
Lizhong

> Sent: 2014年6月8日 22:05
> To: Lizhong Jin; 'Loa Andersson'; [email-masked]
draft-ietf-mpls-
> > Cc: [email-masked]; [email-masked];
> > draft-ietf-mpls-lsp- [email-masked]
> > draft-ietf- mpls-lsp-ping-relay-reply
> >
> > Hi Nobo,
> > > to just to set the K bit. Can you provide more thoughts on exactly
> > > how you intended to use this bit?
> > [Lizhong] In a network with multiple ASs, and only ASBRs or border
> > nodes are the potential relay nodes. This maybe the most common case.
> > The original thought is to let all ASBRs to be relay node, and the
> > initiator could discover the ASBR list. So it is suggested to let ASBR
> > (or border node) to set K bit as a node wide configuration. But we did
not
> restrict other nodes to set
> > K bit.
> 
> There's a slight conflict then. If the intention of the K bit is to let
the initiator
> discover ASBRs, then we should have a text that says ASBRs SHOULD set the
> K bit and non-ASBRs MUST NOT set the K bit. Otherwise non-ASBRs setting
> the K bit can give wrong information to the initiator. However, if the
> intention has become more loose (i.e. any node who wants to remain in the
> TLV as the relay node), then perhaps a short text would be helpful.
> Something like:
> 
[Lizhong] accepted. Thanks.

> 
> >
> > >
> > > On a related note, I did not find any texts around usage of K bit
> > > and Unspecified Address Type, which probably should be considered
> invalid.
> > [Lizhong] The usage and protocol operation of K bit and Unspecified
> > Address Type is described in section 4.2. I did not quite get this
> > comment, could you give more detail.
> 
> What I meant was, do we ever want a relay node address entry that has K
bit
> set _and_ is Unspecified Address Type? It seems that will just waste space
in
> the Relay Node Address Stack TLV (and on the wire). I was just asking if
> there's any reason why K bit & Unspecified combination is not restricted.
[Lizhong] got it. You are right, the entry with Unspecified Address Type
SHOULD NOT set K bit. Will add this to the text.

> > > source IP address must be found in the address stack of the Relay
> > > Node Address Stack TLV. In that case, above statement in section 4.2
> > > should be tightened that source IP address of transmitted packet
> > > must be used as the "address entry of the replying LSR". Otherwise
> > > valid reply may be dropped
> > by
> > > a relay node.
> > [Lizhong] accepted. Should be tightened that the address added in
> > Relay Node Address Stack TLV MUST be the source IP address of Relay
> > Echo Reply or Echo Reply message.
> 
> Thanks.
> 
> >
> > >
> > >
> > > Section 4.2:
> > >
> > > suppose the purpose of this is to let the initiator know the
> > > responder is intentionally hiding it's local address, but is that
> > > really necessary? If
> > so, what's
> > [Lizhong] not only deleted by the next responder, if the replying LSR
> > is a relayed node, and reply with unspecified address, then the
> > unspecified address will not be deleted by the compress process. As a
> > result, the relayed echo reply will not be successfully sent back to
> > initiator. Security concern is the main motivation of setting
> > Unspecified Address Type, since Ping with Relayed Echo Rely could
> > trace every node across domains. If trace is only used for trouble
> > shooting, in many cases, these hiding LSR will not influence success of
the
> trouble shooting if they are not relayed node.
> 
> Ok, based on your answers above and below, blank entry makes sense.
> Although I don't see the point of allowing a blank entry have a K bit set.
[Lizhong] right, and as the previous comment, will add the restriction in
the text. Thanks.

> > > transmitting Echo Reply or further Relayed Echo Reply, since that
> > > will break the loop
> > prevention
> > > proposed in Section 4.4. However, if we are not preserving the
> > > source IP address from the original responder node, then there's an
> > > impact to traceroute implementations as they usually print out
> > > received source IP addresses (which no longer will be responder
> addresses).
> > >
> > > Initiator could do:
> > >
> > [Lizhong] The initiator should print last address in the stack, we
> > should add this in the text. It could say weaker than legacy
> > traceroute from address displaying point of view. But traceroute is
> > now working in a multi-domain case. Hiding address should be allowed
> > if desired, under the condition that trouble shooting could still be
> > possible. Then we could say the new traceroute is stronger than legacy
> from trouble shooting point of view.
> 
> - Source IP address in Echo Reply and Relay Echo Reply are to be of the
> address of the node sending those packets (i.e. not copied from received
> Relay Echo Reply).
> - Traceroute address output module will need to conditionally print the
> address in the Relay Node Address Stack TLV.
[Lizhong] accepted, thanks.

> > > Proxy Ping. For example, first address in the Relay Node Address
> > > Stack TLV should be Proxy sender, and Proxy receiver (i.e. Echo
> > > Request
> > draft-proxy- lsp-ping. It would be more reasonable to add the
> > suggested text to draft- proxy-lsp-ping, right? I could talk this with
> > author of draft-proxy-lsp-ping and chair. Thanks.
> 
> Ah right, I forgot that Proxy has not become RFC yet. Yes I think that'll
be a
> good idea to make sure to raise this point to Proxy authors and chairs so
that
> it gets on some "todo list".
[Lizhong] good.

> > [Lizhong] this is a missing part, and should be added. I think copy is
> > the right behavior. Thanks.
> 
> Agree.
> 
> Thanks!
> 
> -Nobo
> 
> >
> > Regards
> > Lizhong
> >
> > >
> > >
> > > Thanks!
> > >
> > > -Nobo
> > >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 10 Jun 2014 12:19:38 +0000

Hi Loa,

Lizhong has agreed to address my comments, and I'm happy (i.e. yes/support) for this document to progress once the new version is posted.

Thanks!

-Nobo

> Sent: Sunday, June 08, 2014 9:56 PM
> > > initiator could discover the ASBR list. So it is suggested to let
> > > ASBR (or border node) to set K bit as a node wide configuration. But
> > > we did
> not
> > discover ASBRs, then we should have a text that says ASBRs SHOULD set
> > the K bit and non-ASBRs MUST NOT set the K bit. Otherwise non-ASBRs
> > setting the K bit can give wrong information to the initiator.
> > However, if the intention has become more loose (i.e. any node who
> > wants to remain in the TLV as the relay node), then perhaps a short text
> would be helpful.
> > Something like:
> >
> > the Relay Node Address Stack TLV (and on the wire). I was just asking
> > if there's any reason why K bit & Unspecified combination is not restricted.
> > > >    the address entry of the replying LSR MUST be added at the
> > > > bottom
> of
> > > >    the stack.
> > > >
> > > > Node Address Stack TLV. In that case, above statement in section
> > > > 4.2 should be tightened that source IP address of transmitted
> > > > packet must be used as the "address entry of the replying LSR".
> > > > Otherwise valid reply may be dropped
> > > by
> > > > a relay node.
> > > [Lizhong] not only deleted by the next responder, if the replying
> > > LSR is a relayed node, and reply with unspecified address, then the
> > > unspecified address will not be deleted by the compress process. As
> > > a result, the relayed echo reply will not be successfully sent back
> > > to initiator. Security concern is the main motivation of setting
> [Lizhong] right, and as the previous comment, will add the restriction in the
> text. Thanks.
> 
> >
> > >
> > > >
> > > >
> > > > Section 4.4:
> > > >
> > > > I didn't see any texts describing what the source IP address of
> > > > the packet sent by receiver of Relayed Echo Reply. I'm guessing
> > > > that we cannot copy received source IP address as the source IP
> > > > address of transmitting Echo Reply or further Relayed Echo Reply,
> > > > since that will break the loop
> > > prevention
> > > > source IP address from the original responder node, then there's
> > > > an impact to traceroute implementations as they usually print out
> > > > (1) Preserve the source IP address in received Relayed Echo Reply
> > > > to transmitting Echo Reply or Relay Echo Reply.
> > > > work and traceroute will remain the same as today. And if you go
> > > > via this, then source IP address will always be what would have
> > > > been placed in the Relay Node Address Stack TLV by the responder.
> > > > In that case, the purpose
> > > of
> > - Source IP address in Echo Reply and Relay Echo Reply are to be of
> > the address of the node sending those packets (i.e. not copied from
> > received Relay Echo Reply).
> > - Traceroute address output module will need to conditionally print
> > the address in the Relay Node Address Stack TLV.
> > > > however I think a bit of additions are needed to make this work
> > > > with Proxy Ping. For example, first address in the Relay Node
> > > > Address Stack TLV should be Proxy sender, and Proxy receiver (i.e.
> > > > Echo Request
> > > > Relay Node Address Stack TLV update procedure just like receiver
> > > > of Echo Request.
> > > suggested text to draft- proxy-lsp-ping, right? I could talk this
> > > with author of draft-proxy-lsp-ping and chair. Thanks.
> >
> > > [Lizhong] this is a missing part, and should be added. I think copy
> > > is the right behavior. Thanks.
> >
> > Agree.
> >
> > Thanks!
> >
> > -Nobo
> >
> > >
> > > Regards
> > > Lizhong
> > >
> > > >
> > > >
> > > > Thanks!
> > > >
> > > > -Nobo
> > > >
> > > > > I cn't make up my mind how to interprete this - either the wg
> > > > > have lost interest in the draft (which would surprise me
> > > > > greatly) or everybody thinks the draft is perfect (which would
> > > > > also be a
> surprise).
> > > > >
> > > > > > There are two IPR disclosures against this document. The
> > > > > > author has stated that he is unaware of any other IPRs that
> > > > > > relate to this document.
> > > > > >

---

From: Loa Andersson <[email-masked]>
Date: Tue, 17 Jun 2014 06:53:51 +0200

Working Group,

This working group has been closed, there have been comments. Could the
authors please address comments and post a new version of the dcoument.

/Loa
for the wg chairs

--

---

From: "Lizhong Jin" <[email-masked]>
Date: Tue, 17 Jun 2014 14:04:01 +0800

Hi Loa, all,
Thanks for the comments. We will post a new version soon.

Regards
Lizhong

> From: Loa Andersson [mailto:[email-masked]]
> Sent: 2014年6月17日 12:54
> To: [email-masked]
> Cc: [email-masked]; <[email-masked]>; VIGOUREUX,
> MARTIN (MARTIN); [email-masked]
> Subject: Closed -- Re: Still Open - Re: Working group last call on
draft-ietf-
publication!").