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

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

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