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

[Xuxiaohu <[e-mail]>]

Hi Wim,

> -----邮件原件-----
> 发件人: Henderickx, Wim (Nokia - BE/Antwerp)
> [mailto:[e-mail]]
> 发送时间: 2017年8月14日 15:03
> 收件人: Xuxiaohu; Uma Chunduri; [e-mail]; [e-mail]
> 主题: Re: 答复: [spring] FW: New Version Notification for
> draft-bryant-mpls-unified-ip-sr-01.txt
> 
> In-line
> 
> On 14/08/2017, 08:41, "Xuxiaohu" <[e-mail]> wrote:
> 
>     Hi Wim,
> 
>     > -----邮件原件-----
>     > 发件人: spring [mailto:[e-mail]] 代表 Henderickx, Wim
> (Nokia
>     > - BE/Antwerp)
>     > 发送时间: 2017年8月14日 14:27
>     > 收件人: Uma Chunduri; [e-mail]; [e-mail]
>     > 主题: Re: [spring] FW: New Version Notification for
>     > draft-bryant-mpls-unified-ip-sr-01.txt
>     >
>     > 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 |
>     >           +--------+                 +--------+        +--------+
> 
>     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.
> 
> WH> if we want to support this use case we should spell this out more explicitly.
> On top this complicates the usage of entropy because with SRoUDP we use the
> source port and when we use native SRoMPLS we loose this. I believe we need
> to encode the entropy label in the packet for the MPLS segment. The next
> question is than who should add this entropy label. Is it the source or is it the
> transit box. In my view it should be added at the source taking RLD/MSD into
> account. On top you can also envision a use case when SRoMPLS needs to map
> back to SRoUDP in which case you should use the entropy label to map to
> SRoUDP sPort entropy.

Very useful comment and suggestion. We will incorporate them in the next revision.

>     > 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.
> 
> WH> my view is that having a router indicate it support MPLSoUDP is not the
> same as a router doing SRoUDP. So, we might want to distinguish between the
> different encapsulation techniques.

Could you please give more detailed explanation on this point?

Best regards,
Xiaohu

>     Best regards,
>     Xiaohu
> 
>     > On 14/08/2017, 04:58, "Uma Chunduri" <[e-mail]>
> wrote:
>     >
>     >     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:[e-mail]] On Behalf Of
> Henderickx,
>     > Wim (Nokia - BE/Antwerp)
>     >     Sent: Sunday, August 13, 2017 6:55 PM
>     >     To: [e-mail]; [e-mail]
>     >     Subject: Re: [spring] FW: New Version Notification for
>     > draft-bryant-mpls-unified-ip-sr-01.txt
>     >
>     >     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"
>     > <[e-mail] on behalf of [e-mail]> wrote:
>     >
>     >         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: [e-mail]
>     >         > 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
>     >
>     >         _______________________________________________
>     >         spring mailing list
>     >         [e-mail]
>     >         https://www.ietf.org/mailman/listinfo/spring
>     >
>     >
>     >     _______________________________________________
>     >     spring mailing list
>     >     [e-mail]
>     >     https://www.ietf.org/mailman/listinfo/spring
>     >
>     >
>     >
>     > _______________________________________________
>     > spring mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/spring
>