Subject: Re: [mpls] Subject: Forwarding discussion in ldp-multi-topology draft

From: Quintin Zhao <[email-masked]>
Date: Tue, 18 Oct 2011 13:14:09 -0400

Eric,

Thanks a lot for your detailed comments and very good suggestions!

I generally agree with you that we don't need discuss the forwarding
mechanism in our draft from now on. The reason we have the section 10 is
that we have multiple choices for the encoding of <MT-id, address prefix>
pair in our previous versions of the draft. Now we have come to the
consensus among the authors that we chose the choice of banding one label
instead of a stack of labels to a <MT-id, address prefix> pair. With this
choice, forwarding mechanism is as same as when non-MPLS multi-topology is
supported and it is just based only on the label, where the label is
associated with an <MD-id, prefix> pair.  What we would like to do in our
next version of the draft, we will remove the section 10 and just have a
short paragraph to explain briefly that LDP-MT support will not require the
data plane changes using the text similar you have suggested here.
"
For the section 3.5, the applications scenario is that when one ISP owns
multiple ASes and the VPN services crossing these ASes are usually setup
using inter-AS VPNs' option A or B or C.  With MPLS multiple topology, the
ISP can configure a new AS with a subset of the routers which are sitting in
the existing ASes. The new AS will be used to provide the VPN services and
there is not inter-AS setup needed anymore. In the IETF79 meeting, Lianyuan
had a presentation to describe this, here is the link for the presentation
slide( page3-page7):
http://www.ietf.org/proceedings/79/slides/mpls-10/mpls-10.htm.

I have also a few other comments and questions and see the places with
[Quintin] in line.

Quintin

----------------------------------------------------------------------

Message: 1
Date: Mon, 17 Oct 2011 11:22:23 -0400
From: Eric Rosen <[email-masked]>
To: [email-masked]
Subject: [mpls] Forwarding discussion in ldp-multi-topology draft
Message-ID: <6871.1318864943@erosen-linux>

I'd like to make a comment on the discussion of forwarding in
draft-ietf-mpls-ldp-multi-topology-00.txt.

The draft is about the control plane mechanism used to bind a label to a
<MT-id, address prefix> pair.  The label is downstream-assigned.  The
interpretation of the label is thus a local matter for the downstream LDP
peer that assigns it.

The draft mentions the possibility of binding  a stack of labels to a
<MT-id, address prefix> pair.  One could also consider the possibility of
binding a stack of labels to an "ordinary" address prefix in a
single-topology environment.  There are two separate issues:

1. defining a signaling mechanism for binding more than one label to a FEC
   element of some sort.

2. defining the encoding of a FEC element that represents a <MT-id, prefix>
   pair

These two issues are orthogonal, and the draft is about issue 2, NOT about
issue 1.  

Note that if we have the mechanism of 1, it could be combined with the
encoding of 2.  But as long as all the assigned labels are
downstream-assigned, their interpretation would be a local matter for the
assigner, and it would not be appropriate to require, e.g., that the top
label be a context label.

Thus I would suggest removing the following paragraph from section 2:

[Quintin] Agree.

   "There are two possible solutions to support MT awared MPLS network
   from MPLS forwarding point of view.  The first one is to map label to
   both ip address and the corresponding topology.  The alternative one
   is to use label stacks.  The upper label maps to the topology, the
   lower label maps to the ip address.  The first option does not
   require change to data plane, and it could use multiple labels for
   the same address on different topologies.  The second option requires
   two lookups on data forwarding plane, and it can use the same label"

It suggests that if a two-label solution is ever used, the top label would
be a" context label" (RFC 5331) specifying the table in which the second
label is looked up.  There is no particular reason to say this.   The
paragraph also suggests that if a context label is not used, the
platform-specific label space must be used.  There's no particular reason to
say that either; one could imagine an environment in which an
interface-specific label space could be used (e.g., each link in only one
topology).  These issues are outside the scope of this draft, and I think
any discussion of them here will only cause confusion in the future.

[Quintin] if the linter-specific label space is used, then we still have the
case that this interface is used by multiple topology, right? How can we
differentiate the different topologies?

It would be okay to say just that this draft does not require or presuppose
any changes to the MPLS data plane.

Similarly, I would suggest omitting section 10 entirely.  The section even
pronounces itself to be outside the scope of the document.  It also has a
few inaccuracies.

   In MT based MPLS network, forwarding will be based not only on label, but
   also on MT-ID associsted with the label.

This is not true as stated.  I think what is meant is that forwarding is
still based only on the label, but the label is associated with an
<MD-id,prefix> pair.

   It also resolves the
   forwarding issue that exists in IGP multi-topology forwarding when
   multiple topologies share an interface with overlay address space.

"overlay" --> "overlapping", I think.

[Quintin] You are right.

When this draft gets reviewed outside the MPLS group, the term "the issue
that exists in IGP multi-topology forwarding" will attract unwanted
attention, as it is not completely clear what that issue is, why it is such
a big problem, or why it needs to be mentioned in this context.

> in this mechanism, label space is not allowed to be overlapping
> among different MTs

I think the most you can say is that: 

- the specified signaling mechanisms allow all the topologies to share the
  platform-specific label space; this is the feature that allows the
  existing data plane techniques to be used;  and

- the specified signaling mechanisms do not provide any way for the data
  plane to associate a given packet with a context-specific label space.
I also have some comments on the applicability section.
  
[Quintin] Will use the texts you suggested here in the next version of the
draft.

Section 3.1 "Simplified Data-plane" is pretty standard "MPLS is good" stuff.
But I'd have thought that the problem with non-MPLS multi-topology is not so
much the fact that it needs multiple FIBs as that there has to be some way
of associating a received packet with a particular topology.

[Quintin] Can you explain more on this "some way" here? With multiple FIBs,
does associating a received packet with a particular topology requires the
data plane change if the existing router has not supported multiple topology
before?

Section 3.5, "Simplified inter-AS VPN solution", suggests that
multi-topology LDP allows inter-AS VPNs to be set up without using options
A, B or C.  I don't really understand what is being proposed here.

[Quintin] reference to the slide.

------------------------------

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

End of mpls Digest, Vol 90, Issue 23
************************************

---

From: Eric Rosen <[email-masked]>
Date: Thu, 20 Oct 2011 16:02:17 -0400

> http://www.ietf.org/proceedings/79/slides/mpls-10/mpls-10.htm.

I took a look at the slides, but I don't really see the merit of this
proposal.  It's not really clear how the topology is to be set up, what the
BGP relationships are, or why anyone would think this is easier or simpler
than the conventional inter-AS L3VPN mechanisms (or other alternatives such
as overlays, carrier's carrier, etc.)  After all, the multi-topology
configuration affects all the intermediate nodes, while the other mechanisms
do not.  But perhaps it's just difficult to understand the proposal from a
few slides.

Whether or not that proposal has merit, I don't think the LDP multi-topology
draft should make unsubstantiated statements like

        "the LSP setup process can be simplified by configuring a set of
        routers which are in different domains into a new single domain with
        a new toplogy ID using the LDP multiple topology"

or

        "the LDP lsp set up can be done easily without the complex inter-as
        VPN solution's option A, option B and option C."

Quintin> if the interface-specific label space is used, then we still have
Quintin> the case that this interface is used by multiple topology, right?
Quintin> How can we differentiate the different topologies?

Correct; some scenarios require use of the platform-specific label space.
My only point is this is a local matter, each LSR can use whatever sort of
label space is suitable for its deployment scenario.  There's no need for
the spec to require that the platform-specific label space be used.

>  With multiple FIBs, does associating a received packet with a particular
>  topology requires a data plane change if the existing router has not
>  supported multiple topology before?

If the association is made by looking at a part of the IP header, I think it
would be fair to say that a data plane change is required.  However, it's
also possible to implement non-MPLS multi-topology by using data link
multiplexing techniques.

---

From: Quintin Zhao <[email-masked]>
Date: Thu, 27 Oct 2011 14:41:10 -0400

Eric，

We did more testing/investigating and have some inputs for the concerns and 
questions you described in you last email. Either in the future version of
this LDP-MT draft or
in the future version of the MPLS MT requirement/applicability draft, 
we will add more explanations and examples details for this inter-AS vpn
scenarios. 

Thanks for your time!

Quintin

Eric>It's not really clear how the topology is to be set up, what the
Eric>BGP relationships are, or why anyone would think this is easier or
simpler
Eric>than the conventional inter-AS L3VPN mechanisms (or other alternatives
such
Eric>as overlays, carrier's carrier, etc.)  After all, the multi-topology
Eric>configuration affects all the intermediate nodes, while the other
mechanisms
Eric>do not.  But perhaps it's just difficult to understand the proposal
from a few slides.

The new AS configured using MPLS MT for inter-AS vpn purpose can have the
topology 
specific routes including the VPN routes and IGP routes maintained within
itself and these 
routes don't need to be propagated into other existing ASes. At the same
time, the BGP routes 
within other ASes using default topology don't need to be propagated into
this new AS.
 
it is true that all the nodes within this new AS need to be configured for
this new topology 
for the inter-AS vpn purpose. In the case that not all of the intermediate
routes can be upgraded to 
support the MT, then the tunneling through method can help the user to do a
phasing upgrade.

Eric>Whether or not that proposal has merit, I don't think the LDP
multi-topology
Eric>draft should make unsubstantiated statements like

Eric>        "the LSP setup process can be simplified by configuring a set
of
Eric>        routers which are in different domains into a new single domain
with
Eric>        a new toplogy ID using the LDP multiple topology"

Eric> or

Eric>        "the LDP lsp set up can be done easily without the complex
inter-as
Eric>        VPN solution's option A, option B and option C."

Agree. We will rephrase this in the new version of the draft to remove the
word "simplified" and "easily" 
and just state that LDP multi-topology is another way to solve the inter-AS
VPN solution. We let users to 
decide which solution is more suitable for their deployment environment.