Subject: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 11 Aug 2017 19:47:07 +0100

Hi all,

SPRING didn't meet in Prague so I presented this work in MPLS. Bruno suggested
that maybe SPRING would be a better venue.

I'm not sure about that, although I do think both WGs should chat about the
ideas.

The essence of this work is nothing more that MPLS-SR encapsulated in UDP per
RFC 7510. What it achieves is a way to obtain the SR functionality that we all
know and love in an IP network.

The approach is, of course, compatible with MPLS-SR. As the draft says...

   This document makes no changes to the segment routing architecture
   and builds on existing protocol mechanisms such as the encapsulation
   of MPLS within UDP defined in RFC 7510.

   No new procedures are introduced, but existing mechanisms are
   combined to achieve the desired result.

This is not intended to be a beauty contest with SRv6. As the draft says...

   The method defined is a complementary way of running SR in an IP
   network that can be used alongside or interchangeably with that
   defined in [I-D.ietf-6man-segment-routing-header].  Implementers and
   deployers should consider the benefits and drawbacks of each method
   and select the approach most suited to their needs.

Thanks,
Adrian

> ________________________________________
> From: [email-masked]
> Sent: 11 August 2017 19:39:59 (UTC+00:00) Dublin, Edinburgh, Lisbon, London
> To: Stewart Bryant; John E Drake; Adrian Farrel
> Subject: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
> 
> A new version of I-D, draft-bryant-mpls-unified-ip-sr-01.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> 
> Name:           draft-bryant-mpls-unified-ip-sr
> Revision:       01
> Title:          A Unified Approach to IP Segment Routing
> Document date:  2017-08-11
> Group:          Individual Submission
> Pages:          16
> URL:
https://www.ietf.org/internet-drafts/draft-bryant-mpls-unified-ip-sr-
> 01.txt
> Status:
https://datatracker.ietf.org/doc/draft-bryant-mpls-unified-ip-sr/
> Htmlized:       https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-bryant-mpls-unified-ip-
> sr-01
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-bryant-mpls-unified-ip-sr-01
> 
> Abstract:
>    Segment routing is a source routed forwarding method that allows
>    packets to be steered through a network on paths other than the
>    shortest path derived from the routing protocol.  The approach uses
>    information encoded in the packet header to partially or completely
>    specify the route the packet takes through the network, and does not
>    make use of a signaling protocol to pre-install paths in the network.
> 
>    Two different encapsulations have been defined to enable segment
>    routing in an MPLS network and in an IPv6 network.  While
>    acknowledging that there is a strong need to support segment routing
>    in both environments, this document defines a converged, unified
>    approach to segment routing that enables a single mechanism to be
>    applied in both types of network.  The resulting approach is also
>    applicable to IPv4 networks without the need for any changes to the
>    IPv4 specification.
> 
>    This document makes no changes to the segment routing architecture
>    and builds on existing protocol mechanisms such as the encapsulation
>    of MPLS within UDP defined in RFC 7510.
> 
>    No new procedures are introduced, but existing mechanisms are
>    combined to achieve the desired result.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Aug 2017 21:11:45 +0200

Hi Adrian,

I see few so to say "challenges" with the proposal

A)

SRv6 SID is 128 bits where first 64 is the locator and remaining 64 is the
function. So to "emulate" this directly with SR-MPLS you need for 1 SRv6
SID stack of 8 labels ! And some use cases of SRv6 already talk about using
few SRv6 SIDs. Please show me the today's hardware which can consume in
single pass and make sense of stack of say 32 mpls labels ... so here goes
your "interchangeability".

B)

One of serious concerns with SRH insertion in transit as expressed by 6man
was MTU. How does this proposal solves this at all if what you are doing
here is taking nicely MTU discovered and negotiated IPv6 packet and adding
mpls stack or tower + UDP + IPv/v6 encap to it ? How would end hosts now
will get any awareness about this ?

C)

One of the very nice applications for SRv6 is spray function with full
multicast address transparency. Please kindly elaborate how are you going
to map IPv4 or IPv6 multicast addresses into MPLS labels ?

- - -

I think while it looks great on slides that now we will have two different
ways to do SR on IP networks if you really focus to specific applications
you will find a lot of them which are not going to be compatible with your
proposal. So maybe instead trying to squeeze the balloon to fit the bottle
we better collectively focus on making the balloon fly ?

Kind regards,
Robert.

On Fri, Aug 11, 2017 at 8:53 PM, Adrian Farrel <[email-masked]> wrote:

> All,
>
> The presentation of this draft in Prague seemed to be well received and we
> got
> some comments that we have stated to act on in this revision.
>
> One, non-technical request was to share the work with the SPRING working
> group,
> and I have just done that.
>
> At the meeting I noted that...
> > The authors think this is in charter for MPLS
> > But polish and discussion is needed before we ask for adoption
>
> As this polish continues, I'd like to ask the list what they think of this
> work.
> Is it going in the right direction? Is it work that you support?
>
> Thanks,
> Adrian
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 11 Aug 2017 15:22:05 -0400

Adrian,

I think this is a straightforward draft that provides valuable
functionality, especially SR within an IP (v4 or v6) network as discussed
in section 6.2. I certainly support it going forward. I don’t personally
have a strong opinion whether MPLS or SPRING is the proper place to pursue
the work, as long as it is pursued. I’m happy to let the WG chairs and ADs
figure that out.

Cheers,
Andy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 11 Aug 2017 21:22:55 +0200

Sorry but forgot one more really useful advantage which your proposal is
lacking ...

D)

In SRv6 when you traverse SR node you move the pointer from one SID to the
next one. This allows you to maintain in the packet the entire history of
functions executed on a given packet. Something which to the best of my
knowledge we never had in the IP networks. Now how could you accomplish the
same or even close to that with SR-MPLS analogy ?

Cheers,
R.

On Fri, Aug 11, 2017 at 9:11 PM, Robert Raszuk <[email-masked]> wrote:

>> The presentation of this draft in Prague seemed to be well received and
>> we got
>> As this polish continues, I'd like to ask the list what they think of
>> this work.

---

From: Eric Gray <[email-masked]>
Date: Fri, 11 Aug 2017 20:16:58 +0000

What he said…

From: mpls [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Friday, August 11, 2017 3:22 PM
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt

Adrian,

I think this is a straightforward draft that provides valuable functionality, especially SR within an IP (v4 or v6) network as discussed in section 6.2. I certainly support it going forward. I don’t personally have a strong opinion whether MPLS or SPRING is the proper place to pursue the work, as long as it is pursued. I’m happy to let the WG chairs and ADs figure that out.

Cheers,
Andy

On Fri, Aug 11, 2017 at 2:53 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
All,

The presentation of this draft in Prague seemed to be well received and we got
some comments that we have stated to act on in this revision.

One, non-technical request was to share the work with the SPRING working group,
and I have just done that.

> But polish and discussion is needed before we ask for adoption

As this polish continues, I'd like to ask the list what they think of this work.
Is it going in the right direction? Is it work that you support?

Thanks,
Adrian

> From: [email-masked]<mailto:[email-masked]>
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat

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

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 12 Aug 2017 00:21:07 +0000

________________________________
徐小虎
M：+86-13910161692
E：[email-masked]<mailto:[email-masked]>
产品与解决方案-网络战略与业务发展部

发件人： Adrian Farrel
收件人： [email-masked]<mailto:[email-masked]>
主题： [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
时间： 2017-08-12 02:47:40

Hi all,

Thanks,
Adrian

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

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 12 Aug 2017 00:23:11 +0000

Adrian and Stewart，

When you submitted the -00 version of this draft with my name being listed in the coauthor list but without my permission, I tolerated it so as to give face to you, although it had caused unnecessary confusion in the IETF, especially among the coauthors of draft-xu-mpls-unified-source-routing-instruction.

This time you submitted -01 version with my name being added into the contributor list but without my permission as well. I have to remind you: don't repeat such impolite actions.

 Xiaohu

发件人： Adrian Farrel

Hi all,

Thanks,
Adrian

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 14 Aug 2017 01:54:51 +0000

The draft only defines procedures for SRoIP E2E, why don’t we envision SRoIP to Interwork with native MPLS-SR.
What I mean is when using the SRoIP procedures the draft uses SRoIP at every hop which is SR capable.
You could envision certain segments to do SRoIP and other segments to have native MPLS-SR capability.

So my question is this in scope of this draft?

On 11/08/2017, 20:47, "spring on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    

    

    
    Thanks,
    Adrian

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 14 Aug 2017 02:58:33 +0000

Wim -

That's been described  here:

https://www.ietf.org/id/draft-xu-mpls-unified-source-routing-instruction-03.txt

--
Uma C.

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Sunday, August 13, 2017 6:55 PM
To: [email-masked]; [email-masked]
Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt

    Hi all,

    

    

    
    Thanks,
    Adrian

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 14 Aug 2017 06:27:17 +0000

Also this draft doesn’t describe this use case afais. What I am taking about is this:
Using MPLS-SR for the SID to G and SID to H iso using SR-UDP SID. Is this envisioned?

     +-----+       +-----+       +-----+        +-----+        +-----+
     |  A  +-------+  B  +-------+  C  +--------+  D  +--------+  H  |
     +-----+       +--+--+       +--+--+        +--+--+        +-----+
                      |             |              |
                      |             |              |
                   +--+--+       +--+--+        +--+--+
                   |  E  +-------+  F  +--------+  G  |
                   +-----+       +-----+        +-----+

          +--------+
          |IP(A->E)|
          +--------+                 +--------+
          |  L(G)  |                 |L(G)   |
          +--------+                 +--------+        +--------+
          |  L(H)  |                 |  L(H)  |        |L(H)|
          +--------+                 +--------+        +--------+
          | Packet |   --->    | Packet |  --->  | Packet |
          +--------+                 +--------+        +--------+

Also, it is a bit odd we have so many drafts on the same topic. 
Btw what about BGP extensions?

On 14/08/2017, 04:58, "Uma Chunduri" <[email-masked]> wrote:

    Wim -

    
    --
    Uma C.
    
    -----Original Message-----
    From: spring [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
    Sent: Sunday, August 13, 2017 6:55 PM
    To: [email-masked]; [email-masked]
    Subject: Re: [spring] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt

    
    
        Hi all,

        

        

        
        Thanks,
        Adrian

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 14 Aug 2017 06:41:22 +0000

Hi Wim,

> -----邮件原件-----
> 发件人: spring [mailto:[email-masked]] 代表 Henderickx, Wim (Nokia
> - BE/Antwerp)
> 发送时间: 2017年8月14日 14:27
> 收件人: Uma Chunduri; [email-masked]; [email-masked]
> 主题: Re: [spring] FW: New Version Notification for
> draft-bryant-mpls-unified-ip-sr-01.txt
> 

In fact, the first use case listed in the Use Cases section talks about the incremental deployment of MPLS-SR. If you believe it's not clear enough, we can add more text to clarify it. Any proposed text is welcome.

> Also, it is a bit odd we have so many drafts on the same topic.

The same feeling:(

> Btw what about BGP extensions?

Since the existing protocols for MPLS-SR are reused without any change, the BGP extensions for MPLS-SR could be reused. As for the BGP extension for tunnel capability advertisement, yes, it works as well. we will add some text to clarify it. Thanks for your valuable comments.

Best regards,
Xiaohu

>     On 11/08/2017, 20:47, "spring on behalf of Adrian Farrel"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>         Hi all,
> 
> https://tools.ietf.org/html/draft-bryant-mpls-unified-ip-sr-01
>         > Htmlized:

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 14 Aug 2017 11:59:19 +0100

Hi Wim,

> native MPLS-SR capability.

Yes, the "mixed mode" is both interesting and useful.

In fact, this comes "for free". Consider the example in Figure 3 where UDP is used to connect two SR domains. Now consider that the domains could be any size, the tunnel could be any length, and the picture could be repeated concatenating multiple instance.

Furthermore, the picture need not be fully symmetrical. That is, one end of the flow could be a "domain" and the other could be a single (ingress or egress) router.

> So my question is this in scope of this draft?

So, yes, definitely in scope.

If you feel this could be usefully described we'll add text, but I suspect it just follows and we only need to add a short note.

But...

> What I mean is when using the SRoIP procedures the draft uses SRoIP at every

Not the case. As shown in Figure 4 and discussed in sections 5.3 and 5.4, there may be transit routers on the path. These may be native IP (i.e.) legacy routers, or SR-capable routers that are simply not explicitly part of the SR path. Only the nodes explicitly mentioned in the SR path become UDP end points and do the SRoIP procedures.

Cheers,
Adrian

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 15 Aug 2017 04:03:34 +0000

Adrian see my other comments on the mailing list which seem to clarify some of the ctxt I am taking about

On 14/08/2017, 03:59, "Adrian Farrel" <[email-masked]> wrote:

    Hi Wim,

    

    

    But...

    
    Cheers,
    Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Aug 2017 05:49:05 +0100

Robert,
 
Thanks for the thoughtful comments.
 
You're right, MPLS-SR is not SRv6 and this is not the document to run a comparison or beauty contest. Nor is this the right document to use to consider making changes or additions to MPLS-SR to make it more like SRv6.
 
We should focus this document on describing how to carry MPLS-SR over UDP and the use cases for that.
 
I think your question about MTU discovery is a good one. We should look into that and reference RFC 4023.
 
Cheers,
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: 11 August 2017 20:23
To: Adrian Farrel
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-bryant-mpls-unified-ip-sr-01.txt
 
Sorry but forgot one more really useful advantage which your proposal is lacking ... 
 
D) 
 
In SRv6 when you traverse SR node you move the pointer from one SID to the next one. This allows you to maintain in the packet the entire history of functions executed on a given packet. Something which to the best of my knowledge we never had in the IP networks. Now how could you accomplish the same or even close to that with SR-MPLS analogy ? 
 
Cheers,
R.

 
A) 
 
SRv6 SID is 128 bits where first 64 is the locator and remaining 64 is the function. So to "emulate" this directly with SR-MPLS you need for 1 SRv6 SID stack of 8 labels ! And some use cases of SRv6 already talk about using few SRv6 SIDs. Please show me the today's hardware which can consume in single pass and make sense of stack of say 32 mpls labels ... so here goes your "interchangeability". 
 
B) 
 
One of serious concerns with SRH insertion in transit as expressed by 6man was MTU. How does this proposal solves this at all if what you are doing here is taking nicely MTU discovered and negotiated IPv6 packet and adding mpls stack or tower + UDP + IPv/v6 encap to it ? How would end hosts now will get any awareness about this ?
 
C) 
 
One of the very nice applications for SRv6 is spray function with full multicast address transparency. Please kindly elaborate how are you going to map IPv4 or IPv6 multicast addresses into MPLS labels ?
 
- - - 
 
I think while it looks great on slides that now we will have two different ways to do SR on IP networks if you really focus to specific applications you will find a lot of them which are not going to be compatible with your proposal. So maybe instead trying to squeeze the balloon to fit the bottle we better collectively focus on making the balloon fly ? 
 
Kind regards,
Robert.

 

Thanks,
Adrian