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.
> 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.
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
