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

["Lizhong Jin" <[e-mail]>]

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

Regards
Lizhong

> -----Original Message-----
> From: Nobo Akiya (nobo) [mailto:[e-mail]]
> Sent: 2014年6月7日 5:15
> To: Loa Andersson; [e-mail]
> Cc: <[e-mail]>; [e-mail];
draft-ietf-mpls-
> [e-mail]
> Subject: RE: [mpls] Still Open - Re: Working group last call on
draft-ietf-mpls-
> lsp-ping-relay-reply
> 
> 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?
[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.

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

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

> 
> 
> Thanks!
> 
> -Nobo
> 
> > -----Original Message-----
> > From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> > Sent: Thursday, June 05, 2014 1:21 AM
> > To: [e-mail]
> > Cc: <[e-mail]>; [e-mail];
> > draft-ietf-mpls- [e-mail]
> > 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).
> >
> > 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 ([e-mail]).
> > >
> > > This working group last call ends June 2, 2014.
> > >
> > > /Loa
> > > for the MPLS wg chairs
> >
> > --
> >
> >
> > Loa Andersson                        email: [e-mail]
> > Senior MPLS Expert                          [e-mail]
> > Huawei Technologies (consultant)     phone: [phone]
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls