Subject: [mpls] Feedback for WG DOC status of draft-nitinb-lsp-ping-over-mpls-tunnel-01

From: "Nitin Bahadur" <[email-masked]>
Date: Tue, 18 Dec 2007 14:08:20 -0800

WG,

  We had presented draft-nitinb-lsp-ping-over-mpls-tunnel-01 at the
Vancouver IETF. The abstract is enclosed below for reference. We would
like WG feedback on whether the draft is ready to be adopted as a WG
document. If it is not, what needs to be addressed to make it one? 

Thanks
Nitin, George, Kireeti.

Abstract:
This document describes methods for performing lsp-ping traceroute over
mpls tunnels and stitched LSPs.  The techniques outlined in RFC 4379 are
insufficient to perform correct traceroute validation and path discovery
for a LSP that goes over other mpls tunnels. RFC 4379 also does not have
any procedures for tracing stitched LSPs. This document describes new
procedures that can be used in conjunction with the standard procedures
described in RFC 4379 to trace such LSPs.

http://tools.ietf.org/wg/mpls/draft-nitinb-lsp-ping-over-mpls-tunnel-01.
txt

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 18 Dec 2007 16:19:25 -0800

Nitin, George, and Kireeti,

> document. If it is not, what needs to be addressed to make it one? 

I think the draft is ready to be accepted as an MPLS WG document.

Yakov.

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 18 Dec 2007 17:16:45 -0800 (PST)

I believe draft-nitinb-lsp-ping-over-mpls-tunnel-01 is ready to be
adopted as a WG document.

rahul

---

From: "Nitin Bahadur" <[email-masked]>
Date: Fri, 21 Dec 2007 14:25:49 -0800

Mustapha,

  Thanks for looking at this in detail and raising your concerns. Please
see NB> below.

> 1. Hiding/Revealing Topology:
> With reference to Figure 1, the draft suggests that if Node B wanted
to
> hide the RSVP tunnel, then it must include a Downstream FEC Stack
Change
> Sub-TLV with NIL FEC in the DDMAP TLV inside the echo response message
> to Node A. I believe this causes a security issue. You are not
providing
> the full details of the tunneling FEC (RSVP Session FEC) but you are
> still telling Node A that a tunnel-in-tunnel exists between B and D.
> Thus, you are providing some topology information.
> 
> I believe this is not the way operators hide their topology. The way
it
> is done is fully at the control of Node B. If Node B wanted to hide
the
> details of the topology, then it does not propagate the TTL received
in
> the echo request message from A when pushing the label for the RSVP
FEC.
> It will use a TTL=255 on the outer RSVP label. This way, the echo
> request expires at Node D instead of Node C. 

NB> Totally agree. If someone wants to hide their topology, then they
can do that with the TTL approach you just outlined above.

> Thus, I do not believe there is a need to use the NIL FEC at all.

NB> The NIL FEC option is *an option*. If the operator uses the above
approach, NIL FEC will not be used. But, for whatever reason an operator
may choose to propagate the TTL but may not want traceroute to discover
the path. It's for such cases that this has been added. Also, it's not a
MUST in the draft and only a recommendation. A vendor can choose to not
implement the NIL FEC behavior. The NIL FEC was also in response to
security issue which was brought up at previous IETF.

> 2. LSP Stitching case:
> This case consists of swapping FECs and is very different from the
case
> of tunneling a FEC inside another FEC. With reference to Figure 2, the
> FEC being traced by Node A, i.e., the target FEC stack, is swapped at
C
> and does not exist end-to-end.
> 
> Thus, Node A must be informed to use the new swapped FEC as its target
> FEC stack in order to properly trace the segment between C and D. RFC
> 4379 already provides the ability for Node C to return the new target
> FEC stack in the existing Target FEC stack TLV in the echo reply
> message. With this, Node A would know there is a FEC swapping
operation
> at Node C and will be able to build the next echo request message with
> the correct target FEC stack TLV.

NB> I am not sure how you came to that conclusion. RFC4379 does not say
anywhere that a node can return a Target FEC stack in the response. Of
course it doesn't say the opposite too. We did consider using the target
FEC stack in the echo response, but there are issues. Consider the below
figure...

   LDP    eBGP    RSVP
A ---- B ----- C ----- D
       |       |
   LDP |       |eBGP
       E ------F 
           LDP

Router B has 2 downstreams. One of them involves a FEC change and one of
them does not involve a FEC change. How is router B supposed to
communicate that the FEC changes only if you choose path via C and not
if you choose path via E.

The other problem of including a complete FEC stack in response was that
the ingress router (B) would need to do additional work of parsing the
FEC stack in the echo response and then figuring out what changed
(w.r.t. the original FEC stack). The PUSH/POP approach we have taken in
our draft simplifies this very much and it seems less error prone (esp.
in a multi-vendor environment).

> We came to this conclusion when we investigated the extension of VCCV
to
> support tracing of Multi-Segment PW (MS-PW). In this case, there is
also
> a FEC stack swapping at an S-PE node, and there is no need to define a
> new mechanism beyond what is in RFC 4379. The VCCV trace feature for
> MS-PW is described in the following draft:
>
http://www.ietf.org/internet-drafts/draft-hart-pwe3-segmented-pw-vccv-02
> .txt

NB> I shall take a look at the same. Thanks for bringing this to my
attention.
 
> The case of tunneling a FEC in another FEC does not cause the traced
FEC
> stack to change. With reference to Figure 1, Node A is still tracing
the
> LDP FEC for Node E. This is why I believe it is the only case that
> requires the addition of the downstream FEC information in the DMAP
TLV.

NB> If you include the FEC information only in the DSMAP (and not in the
target FEC stack TLV), then the transit node can respond with an error,
as per section 4.4.1 of RFC 4379 (since transit node knows nothing about
LDP FEC, it is a pure RSVP node).

> 3. Use of the FEC Stack Change Sub-TLV:
> Based on the above point (2), I believe the only case that requires
> extensions to RFC 4379 is when tunneling a FEC inside another FEC.
This
> can be done by simply adding the downstream FEC stack information to
the
> DSMAP TLV. I do not think there is a need for "FEC Change" information
> since the FEC being traced by Node A in Figure 1 has not changed, it
is
> still the FEC for Node E.

NB> If the transit RSVP node cannot co-relate 1:1 a target FEC stack
elements and the label-stack elements, then it cannot correctly perform
FEC validation. Hence I do think we need the FEC change information.
Consider the case that the transit RSVP node receives a mis-routed trace
request with LDP FEC (1 FEC in fec-stack) and 2 labels. The 2 labels
signify that something might be wrong (aka misrouted packet). Such
errors cannot be caught until there is a 1:1 mapping.

> I propose we simplify the new DDMAP TLV by adding a Downstream FEC
stack
> sub-TLV instead of the proposed Stack change sub-TLV. This sub-TLV is
> optional and may only be used to indicate the FEC being traced is
> entering or exiting a tunnel or tunnels. For example, Node B will
> include the RSVP FEC followed by the LDP FEC. Node C will do the same.
> Node D will only include the LDP FEC. When Node A is processing the
> DDMAP TLV in the echo reply, it always uses the position of the LDP
FEC
> (the FEC being traced) in the DDMAP as a reference to figure out if it
> is entering, transiting, or exiting a tunnel.

NB> As I mentioned above, we had talked about this and there was grave
concern regarding ingress behavior. The other issue was that it could
significantly increase the size of the echo response. Consider a transit
node with 6 downstreams and a tunnel along each downstream. Now the echo
response would contain 6 copies of the FEC stack (which could be any
size), one per downstream. Adding just the changed information
significantly reduces response size.

Thanks
Nitin