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

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Lizhong,

Thanks for considering my comments.

Please see-inline.

> -----Original Message-----
> From: Lizhong Jin [mailto:[e-mail]]
> Sent: Sunday, June 08, 2014 5:23 AM
> To: Nobo Akiya (nobo); 'Loa Andersson'; [e-mail]
> Cc: [e-mail]; [e-mail]; draft-ietf-mpls-lsp-
> [e-mail]
> Subject: RE: [mpls] Still Open - Re: Working group last call on draft-ietf-
> mpls-lsp-ping-relay-reply
> 
> 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.	

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.

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

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.

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

Thanks.

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

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

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

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

Agree.

Thanks!

-Nobo

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