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

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

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

> -----Original Message-----
> From: Lizhong Jin [mailto:[e-mail]]
> Sent: Sunday, June 08, 2014 9:56 PM
> 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,
> 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
>