[prev in list] [next in list] [prev in thread] [next in thread]
List: nanog
Subject: Re: SRm6 (was:SRv6)
From: Jeff Tantsura <jefftant.ietf () gmail ! com>
Date: 2020-09-17 17:48:59
Message-ID: 792e6e07-83b3-445c-813f-58646ae0c693 () Spark
[Download RAW message or body]
MPLSoUDP is not the technology you should be looking at, SRoUDP (RFC8663) is.
draft-bookham-rtgwg-nfix-arch describes an architecture that makes use of it to \
provide an end2end SR path.
Cheers,
Jeff
On Sep 17, 2020, 9:32 AM -0700, James Bensley <jwbensley+nanog@gmail.com>, wrote:
>
>
> On 17 September 2020 11:05:24 CEST, Saku Ytti <saku@ytti.fi> wrote:
> > On Thu, 17 Sep 2020 at 11:03, James Bensley <jwbensley+nanog@gmail.com>
> > wrote:
> >
> > > MPLSoUDP lacks transport engineering features like explicit paths,
> > FRR LFA and FRR rLFA, assuming only a single IP header is used for the
> > transport abstraction [1]. If you want stuff like TI-LFA (I assume this
> > is supported in SRm6 and SRv6, but I'm not familiar with these, sorry
> > if that is a false assumption) you need additional transport headers or
> > a stack of MPLS labels encapped in the UDP header and then you're back
> > to square one.
> >
> > One of us has confusion about what MPLSoUDP is. I don't run it, so
> > might be me.
> >
> > SPORT == Entropy (so non-cooperating transit can balance)
> > DPORT == 6635 (NOT label)
> > Payload = MPLS label(s)
> >
> > Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
> > another MPLS point-to-point adjacency after the MPLSoUDP
> > abstraction/tunnel.
>
> Nope, we have the same understanding. But the email I was responding to was talking \
> about using MPLSoUDP for service label encapsulation *only*, not transport & \
> services labels:
>
> > > If you want an IPv6 underlay for a network offering VPN services
> >
> > And what's wrong again with MPLS over UDP to accomplish the very same with \
> > simplicity ?
> > MPLS - just a demux label to a VRF/CE
> > UDP with IPv6 header plain and simple
> >
> > + minor benefit: you get all of this with zero change to shipping hardware and \
> > software ... Why do we need to go via decks of SRm6 slides and new wave of \
> > protocols extensions ???
>
>
> Cheers,
> James.
[Attachment #3 (text/html)]
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">MPLSoUDP is not the technology you should be looking at, SRoUDP \
(RFC8663) is.<br /> draft-bookham-rtgwg-nfix-arch describes an architecture that \
makes use of it to provide an end2end SR path.</div> </div>
<div name="messageSignatureSection"><br />
<div class="matchFont">Cheers,
<div>Jeff</div>
</div>
</div>
<div name="messageReplySection">On Sep 17, 2020, 9:32 AM -0700, James Bensley \
<jwbensley+nanog@gmail.com>, wrote:<br /> <blockquote type="cite" \
style="border-left-color: grey; border-left-width: thin; border-left-style: solid; \
margin: 5px 5px;padding-left: 10px;"><br /> <br />
On 17 September 2020 11:05:24 CEST, Saku Ytti <saku@ytti.fi> wrote:<br />
<blockquote type="cite">On Thu, 17 Sep 2020 at 11:03, James Bensley \
<jwbensley+nanog@gmail.com><br /> wrote:<br />
<br />
<blockquote type="cite">MPLSoUDP lacks transport engineering features like explicit \
paths,<br /></blockquote> FRR LFA and FRR rLFA, assuming only a single IP header is \
used for the<br /> transport abstraction [1]. If you want stuff like TI-LFA (I assume \
this<br /> is supported in SRm6 and SRv6, but I'm not familiar with these, sorry<br \
/> if that is a false assumption) you need additional transport headers or<br />
a stack of MPLS labels encapped in the UDP header and then you're back<br />
to square one.<br />
<br />
One of us has confusion about what MPLSoUDP is. I don't run it, so<br />
might be me.<br />
<br />
SPORT == Entropy (so non-cooperating transit can balance)<br />
DPORT == 6635 (NOT label)<br />
Payload = MPLS label(s)<br />
<br />
Whatever MPLS can do MPLSoUDP can, by definition, do. It is just<br />
another MPLS point-to-point adjacency after the MPLSoUDP<br />
abstraction/tunnel.<br /></blockquote>
<br />
Nope, we have the same understanding. But the email I was responding to was talking \
about using MPLSoUDP for service label encapsulation *only*, not transport & \
services labels:<br /> <br />
<br />
<blockquote type="cite">
<blockquote type="cite">If you want an IPv6 underlay for a network offering VPN \
services<br /></blockquote> <br />
And what's wrong again with MPLS over UDP to accomplish the very same with simplicity \
?<br /> <br />
MPLS - just a demux label to a VRF/CE<br />
UDP with IPv6 header plain and simple<br />
<br />
+ minor benefit: you get all of this with zero change to shipping hardware and \
software ... Why do we need to go via decks of SRm6 slides and new wave of protocols \
extensions ???<br /></blockquote> <br />
<br />
Cheers,<br />
James.<br /></blockquote>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic