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

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

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

Regards
Lizhong

> -----Original Message-----
> From: Nobo Akiya (nobo) [mailto:[e-mail]]
> Sent: 2014年6月8日 22:05
> To: Lizhong Jin; '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 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.
[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.
> > > 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.
[Lizhong] got it. You are right, the entry with Unspecified Address Type
SHOULD NOT set K bit. Will add this to the text.

> 
> >
> > >
> > >
> > > 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.
[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
> > > 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.
[Lizhong] accepted, thanks.

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

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