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

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

In-line

On 14/08/2017, 00:30, "spring on behalf of Xuxiaohu" <[e-mail] on behalf of [e-mail]> wrote:

    
    
    > -----邮件原件-----
    > 发件人: Henderickx, Wim (Nokia - BE/Antwerp)
    > [mailto:[e-mail]]
    > 发送时间: 2017年8月14日 15:18
    > 收件人: Xuxiaohu; Uma Chunduri; [e-mail]; [e-mail]
    > 主题: Re: 答复: 答复: [spring] FW: New Version Notification for
    > draft-bryant-mpls-unified-ip-sr-01.txt
    > 
    > More in-line
    > 
    > On 14/08/2017, 09:11, "Xuxiaohu" <[e-mail]> wrote:
    > 
    >     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?
    > 
    > WH> I see 2 use case when you indicate MPLSoUDP you can just act as an
    > egress and terminate the tunnel and be agnostic on entropy behaviour, transit
    > behaviour, etc. If you do SRoUDP all the above should be part of your
    > capabilities when you indicate this in the encapsulation capabilities. Hence I
    > believe it might be better to distinguish this in the signalling.
    
    Did you mean the tunnel egress router should advertise whether it could reuse the entry field contained in the UDP tunnel header when reencapsulating (see the below text quoted from -03 version of draft-xu*) in the SRoUDP case, in addition to advertising that it could decapsulate MPLSoUDP packet?
    
    "...To avoid re-performing hash on the whole packet when re-encapsulating
       the packet with an IP-based tunnel header, it's RECOMMENDED that the
       entropy value contained in the packet (e.g., the UDP source port
       value) is kept when stripping the IP-based tunnel header (e.g., the
       UDP tunnel header).  As such, the entropy value could be directly
       copied to the entropy field (e.g., the source port of the UDP tunnel
       header) when re-encapsulating the packet with an IP-based tunnel
       header (e.g., UDP tunnel header).  ..."
    
WH3> no I am trying to distinguish between a regular MPLSoUDP and SRoUDP endpoint

    Best regards,
    Xiaohu
    
    
    >     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
    >     >
    > 
    > 
    
    _______________________________________________
    spring mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/spring