Hi Wim, > -----邮件原件----- > 发件人: Henderickx, Wim (Nokia - BE/Antwerp) > [mailto:[email protected]] > 发送时间: 2017年8月14日 15:03 > 收件人: Xuxiaohu; Uma Chunduri; [email protected]; [email protected] > 主题: Re: 答复: [spring] FW: New Version Notification for > draft-bryant-mpls-unified-ip-sr-01.txt > > In-line > > On 14/08/2017, 08:41, "Xuxiaohu" <[email protected]> wrote: > > Hi Wim, > > > -----邮件原件----- > > 发件人: spring [mailto:[email protected]] 代表 Henderickx, Wim > (Nokia > > - BE/Antwerp) > > 发送时间: 2017年8月14日 14:27 > > 收件人: Uma Chunduri; [email protected]; [email protected] > > 主题: 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" <[email protected]> > 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:[email protected]] On Behalf Of > Henderickx, > > Wim (Nokia - BE/Antwerp) > > Sent: Sunday, August 13, 2017 6:55 PM > > To: [email protected]; [email protected] > > 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" > > <[email protected] on behalf of [email protected]> 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: [email protected] > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring > > > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
