Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps

[Xuxiaohu <[e-mail]>]

Hi Anoop,

It exactly uses the MPLS-in-GRE or other IP-based encapsulations for MPLS.

Anyway, unless it is mandatory to contain a list of IPv6 addresses in the IPv6 data packet for indicating the predefined next-hops of a given explicit source path, it would be better to use a list of SHORTER IDs/labels instead of the 128-bit long IPv6 addresses to indicate those predefined next-hops. IMHO, the existing MPLS label stack mechanism happens to be an ideal candidate for this. People who want to use such mechanism don’t need to know any other applications of MPLS. The only thing that they need to know is that short (MPLS) labels, instead of IPv6 addresses are used in the IPv6 data packet to indicate the predefined next-hops. Therefore, it seems that there is no strong technical motivation to reinvent the wheel for the IPv6 data plane.

Best regards,
Xiaohu

发件人: [e-mail] [mailto:[e-mail]] 代表 Anoop Ghanwani
发送时间: 2013年9月5日 18:42
收件人: Xuxiaohu
抄送: [e-mail]; [e-mail]
主题: Re: [Status] A possible way to make IP fans happy//re: Summary of STATUS BOF and the next steps

Is this any different than MPLS over GRE, where GRE is used to get over non-MPLS-aware parts of a network?

Anoop

On Thu, Sep 5, 2013 at 3:16 AM, Xuxiaohu <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

According to the BoF session at IETF87, it seems that there are a certain number of people who want to see an IPv6-based, rather than MPLS-based source routing mechanism. However, it seems that many people are hesitate to make any change to the existing MPLS and IP data planes.

I wonder whether the following low-cost approach can make those IP fans happy: the predefined next-hops that the explicit source path must traverse are still expressed by the MPLS label stack in the data packets, but the adjacent next-hops are connected via pure IP networks, rather than MPLS networks.  For example, if LSR A wants to send a MPLS VPN packet for LSR Z along an explicit path {B, C, Z}, it would push the node segment label for Z and then the node segment label for C into the existing MPLS label stack, and then transport such MPLS packet over an IP tunnel towards B. Upon receiving such MPLS packet over the IP tunnel, B would look up the corresponding MPLS forwarding table entry for the topmost label (i.e., the node segment label for C) and find the out interface for this packet is an IP tunnel interface with tunnel destination of C, therefore it would pop the topmost label (if the out label of that MPLS forwarding entry is null) and then transport the MPLS packet over an IP tunnel towards C.  Once C receives such MPLS packet over the IP tunnel, C would look up the corresponding MPLS forwarding entry for the current topmost label (i.e., the node segment label for Z) , and then forward this MPLS packet over an IP tunnel towards Z like what B has done.

The above approach has at least the following benefits:


1)    No change to the existing MPLS and IP data plane.

2)    No requirement for the MPLS forwarding capability on all routers=> only those explicit hops need the MPLS forwarding capability.

3)    No requirement for software upgrade on all routers=> only those explicit hops need such software upgrade.

4)    Less MTU collision risk due to the usage of 20-bit long MPLS labels, rather than 128-bit long IPv6 addresses for indicating the predefined next-hops of a given explicit source path.

Best regards,
Xiaohu

发件人: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] 代表 Stewart Bryant
发送时间: 2013年9月4日 18:25
收件人: Mach Chen
抄送: John E Drake; Mark Townsley; Victor Kuarsingh; Roberta Maglione (robmgl); John G. Scudder; Adrian Farrel; Alvaro Retana (aretana); [e-mail]<mailto:[e-mail]>
主题: Re: [Status] Summary of STATUS BOF and the next steps


May I suggest that we use the name "SR" and worry
about what it binds to later.

The higher priority item is the charter text. Does
anyone have any comments on the text proposed
so far, or the text in the BOF proposal:


The Stacked Tunnels for Source Routing (STATUS) Working Group
is chartered to develop a framework and use cases for source-routed
flows in packet switched networks.

IP previously had a source-based routing mechanism made
available through an IP Option. This mechanism has, however,
not been widely used and has a number of issues that make its
use inadvisable, and other mechanisms (such as RFC 1940)
do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding
path of an individual packet or all the packets of a given
Forwarding Equivalence Class (FEC) is a desirable feature
for a number of reasons including Label Switched Path stitching,
egress protection, explicit routing, egress ASBR link selection,
and backup (bypass tunnels, Remote Loop-Free Alternates)
routing. This can be achieved by facilitating source-initiated
selection of routes to complement the route selection
provided by existing routing protocols for both inter- domain
and intra-domain routes.

Historically, distribution of MPLS label binding information
was done by relying on label distribution protocols
such as LDP and RSVP-TE.

The use cases documented by the working group will
indicate the network function that is being facilitated
and indicate which packet data plane is to be used.

The framework developed by the working group will
consider forwarding of IPv4, IPv6, and MPLS using the
existing unicast data planes. Multicast forwarding will
be for future study and the choice of data planes will
be limited to those for which use cases exist. A key
objective of the work will be to ensure that source-
routed packets can be handled seamlessly by existing
deployed equipment. A major objective will be that the
new function does not modify existing data plane behavior
or architectures, and that it can be enabled through only
control and management plane software upgrades at
deployed devices.

Once the working group has established a framework
and there is demonstrable consensus for use cases,
the working group will move forward to specify protocol
solutions for installing forwarding information through
the use of the IGPs (OSPF and IS-IS), or through the
management plane. In the course of developing protocol
extensions, the working group will work closely with
other IETF working groups responsible for the protocols
being modified (such as OSPF, ISIS, and I2RS).

    The working group is chartered for the following work items:

    A framework for the use of the existing MPLS data plane to
    support tunnel-based unicast source routing.

    Develop use cases for tunnel-based unicast source routing
    that demonstrate the need and support for solutions. Care
    should be taken to avoid clustering use cases that might seem
    to imply support for multiple use cases when only some of the
    cluster actually have wide-scale support.

    Develop ISIS and OSPF protocol extensions necessary for
   distribution of MPLS forwarding information.

    The working group will consider management (including
    configuration, reporting, diagnostics, and OAM) and security
    implications of its work and document them in separate
    documents as appropriate.

    The working group is not chartered to make any changes to
    the MPLS or IPv6 data planes. Any proposed changes to the
    data planes are to be specified in the working groups responsible
    for the data planes (that is, the MPLS and 6MAN working groups,
    respectively).

- Stewart

_______________________________________________
status mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/status