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

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 21 Dec 2007 13:51:13 -0600

Nitin,
I have the following issues with this draft. I believe these are
fundamental issues and I cannot support adopting this as a WG document
before they are addressed. Where possible, I provided a way to address
the issue. Let me know of your comments. 

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.

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

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.

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

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.

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

Regards,
Mustapha. 

> -----Original Message-----
> From: Nitin Bahadur [mailto:[email-masked]] 
> Sent: Tuesday, December 18, 2007 5:08 PM
> To: [email-masked]
> Subject: [mpls] Feedback for WG DOC status 
> ofdraft-nitinb-lsp-ping-over-mpls-tunnel-01
> 
> 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 [email-masked] Wed Jan 02 09:34:44 2008
Content-Class: urn:content-classes:message
Subject: RE: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
Date: Wed, 19 Dec 2007 12:03:13 -0500
From: Robert Rennison <[email-masked]>
To: "George Swallow" <[email-masked]>
Cc: [email-masked]

George,

I believe that this draft is ready for an MPLS WG last call.

Rob Rennison

ECI Telecom 

(412) 809 4271

> -----Original Message-----
> From: George Swallow [mailto:[email-masked]] 
> Sent: Tuesday, December 18, 2007 5:09 PM
> To: [email-masked]
> Subject: [mpls] draft-ietf-mpls-ldp-interarea-01.txt to WG last call
> 
> Please indicate whether you believe this draft is ready for 
> MPLS WG last
> call.
> 
> Thanks,
> 
> George & Loa
> 
> ==============================================================
> ==========
> George Swallow             Cisco Systems                  
> (978) 936-1398
>                            1414 Massachusetts Avenue
>                            Boxborough, MA 01719
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> mpl_____
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

[email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
> 
> 

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

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 21 Dec 2007 13:51:13 -0600

Nitin,

2. LSP Stitching case:

Regards,
Mustapha.

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Wed, 16 Jan 2008 12:55:11 -0600

Nitin,
thank you for your response. I have added a few more comments inline.

Mustapha. 

> Sent: Friday, December 21, 2007 5:26 PM
> To: AISSAOUI Mustapha; [email-masked]
> Subject: RE: [mpls] Feedback for WG DOC status 
> Mustapha,
>   Thanks for looking at this in detail and raising your 
> concerns. Please see NB> below.
> 
> 
> NB> Totally agree. If someone wants to hide their topology, then they
> can do that with the TTL approach you just outlined above.
> 
> 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.

MA> Where does the requirement to hide partially the topology (since you
are telling Node A there is a tunnel-in-tunnel) come from? Beside the
security issue associated with sending the NIL FEC, what good does it do
to send the NIL FEC information?
 
> > FEC being traced by Node A, i.e., the target FEC stack, is 
> swapped at
> C
> 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. 

MA> You are right, RFC 4379 is not as explicit about this. The last
sentence in the 2nd paragraph of Section 4.5 states the following:
"The FEC Stack TLV from the echo request MAY be copied to the reply".
Given that the stitching node swaps the target FEC stack, it cannot send
back the old target FEC stack. We concluded that this must be the
swapped one and that is why our proposal in draft
draft-hart-pwe3-segmented-pw-vccv-02 is using this interpretation.

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

MA> When stitching LSPs (or PWs), you can only have one *active*
downstream at any given time. It is different from ECMP which can spray
packets over multiple downstreams at all times. That is why the Target
FEC stack TLV is sufficient in the case of stitching.

> 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
> NB> I shall take a look at the same. Thanks for bringing this to my
> attention.
>  
> 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).
  
MA> That is not what I meant. I am saying that only the case of
tunneling a FEC inside another FEC that requires adding the tunneling
FEC information in the DMAP TLV. The stitching case does not and can be
handled with the existing target FEC stack TLV. The ingress processing
of the target FEC stack TLV is already in existing implementations and
it is much easier than using the new FEC Stack Change Sub-TLV.
 
> 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.

MA> As per the previous point, I think you misunderstood what I said.
Sure, you need to send the tunneling FEC information, in addition to
original FEC being traced, but this is only needed when you tunnel a FEC
inside another FEC.

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

MA> I understand your concern about the ingress node processing of the
full FEC stack. However, the processing of the FEC Stack Change Sub-TLV
by the ingress node is still too complicated. My proposal is to make the
FEC Stack Change Sub-TLV optional and limit its use to indicate the FEC
being traced is entering or exiting a tunnel or tunnels. For stitching
operation, the target FEC stack TLV should be used since the traced FEC
does not exist end-to-end.    

> Nitin

---

From: "Nitin Bahadur" <[email-masked]>
Date: Wed, 23 Jan 2008 16:44:54 -0800

Hi Mustapha,

   Thanks for your clarifications. Please see inline for additional
thoughts from my side.

> to send the NIL FEC information?

Having a NIL FEC ensures that intermediate nodes don't get confused if
they receive an echo request for a (inner) FEC about which they have no
clue. In an inter-AS (single provider) case, you might want the trace to
traverse multiple ASes but details of the AS be hidden from the node
performing the trace. 

Let us say, for a moment that there is no NIL FEC concept. In that case,
for a tunneled trace to succeed you need to do one of the foll:
 
a) Perform TTL-hiding so that trace requests never expire inside the
tunnel
b) Nodes inside the tunnel will need to ignore FEC validation.

If you don't perform either, the tunnel node WILL return an error saying
unknown FEC. Option a) is used, but not everyone uses option a). I don't
think operators would unnecessarily want to configure TTL-hiding (just
to support OAM) in an already running network.

Option b) IMO is dangerous. 

If there is an option c) or option d), I am more than willing to
consider it.

> FEC stack TLV is sufficient in the case of stitching.

Thanks for clearing my understanding.
 
> it is much easier than using the new FEC Stack Change Sub-TLV.

Why have 2 mechanisms when one suffices. A single mechanism makes things
simpler.

> by the ingress node is still too complicated. 

I would like to disagree on that. If one implements the FEC stack change
sub-tlv for tunnel tracing, then the stitching comes for free. A stitch
is nothing but a POP followed by PUSH. You need push to indicate start
of tunnel. And you can use POP to indicate end of tunnel.

> My proposal is to make the
> being traced is entering or exiting a tunnel or tunnels. 

Mustapha, I see nothing technically wrong with your proposal. I would
however prefer a single mechanism that can reused rather than having
different ways of doing different things. The proposal of saying that
ingress should drop its initial FEC stack and use the one in the echo
response is a little scary. The advantage with the POP approach is that
the ingress can validate that what is being asked to POP was on the FEC
stack to start off with.

> For stitching