On Sun, 31 Mar 2019 at 00:23, Robert Raszuk wrote:
>
> Dear Ron,
>
> > Furthermore, we should engineer for future requirements.
>
> Well let's see if we can meet current requirements first.
>
> Imagine that I have a trusted overlay domain over non trusted and non SR
> aware IPv6 underlay (likely
h some, possibly slight,
modification. For example, perhaps IPv4 Address Family support in OSPFv3
(RFC 5838) could be somehow leveraged to suit SR.
Regards,
Mark.
> Kind regards,
> R.
>
> On Sat, Mar 30, 2019 at 4:07 PM Mark Smith wrote:
>
>> On Sun, 31 M
Hi Robert,
Sorry not to get back to you sooner.
On Mon, 1 Apr 2019 at 01:40, Robert Raszuk wrote:
>
> Hi Mark,
>
>
> Since you correctly observed that now SID can be 32 bit and that is similar
> to the size of IPv4 my fundamental question is why not use something which
> already exists
Hi Tom,
On Sat, 13 Apr 2019 at 08:09, Tom Herbert wrote:
>
> > To clarify, I've been thinking about the idea of a smaller SID size
> > for IPv6 for a while now (since inserting EHs came up), and thought
> > about what would be a generic single size that might suit SR that
> > wasn't the same
Hi Tom,
On Sat, 13 Apr 2019 at 00:26, Tom Herbert wrote:
>
> On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk wrote:
> >
> > Hi Mark,
> >
> > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a
> > > 32 bit alignment,
> > > I'd think 32 bit SIDs would be adequate to perform
EH insertion is not compliant with RFC8200. Equipment doing so cannot claim
compliance with RFC8200.
On Wed., 22 May 2019, 11:08 Rajesh M,
wrote:
> Guys in this draft I see that all the example such as ping, traceroute to
> ipv6 address-> use SRH insertion rather than SRH encapsulation.
>
>
EH" ? To me those are completely different
>> > actions.
>> >
>> > And processing of any EH is explicitly allowed by RFC8200 as long as
>> > dst address in the top v6 header is the processing entity which seems
>> > to be the case here. Such
On Tue., 7 May 2019, 06:14 Stewart Bryant, wrote:
> I agree that implicit payload identity is a bad idea.
>
> If the payload is Ethernet, then the IANA Protocol Number Registry
> suggests that 22 is allocated for that purpose:
>
> 22
>
> XNS-IDP XEROX NS IDP
>
> ["The Ethernet, A Local Area
On Tue., 7 May 2019, 23:39 Joel M. Halpern, wrote:
> That is not what Next-Header means.
> Even with this explanation, it is clear that 59 is NOT the right value
> for the next header.
>
If the SID value isn't a reserved for this purpose, permanent and globally
unique value, how would a
ral if possible rather than optimise for one or a small set of
cases.
Regards,
Mark.
>Ron
>
>
>
> Juniper Internal
>
> > -Original Message-
> > From: Mark Smith
> > Sent: Sunday, May 5, 201
On Mon, 6 May 2019 at 10:48, Ron Bonica
wrote:
>
> Folks,
>
> According to Section 4.4 of draft-ietf-spring-srv6-network-programming-00,
> when processing the End.DX2 SID, the Next Header must be equal to 59.
> Otherwise, the packet will be dropped.
>
> In the words of the draft, "We
On Mon, 6 May 2019 at 11:15, Xiejingrong wrote:
>
> Hi Tom,
>
>
>
> Number 97 is a choice but it has 2 bytes wasting.
>
>
It seems strange to me that as bandwidth is constantly getting
cheaper, people seem to be trying harder and harder to use less of it.
The trade-off is increased code
er the header chain, the less accessible the technology becomes to
> low-cost ASICs.
> >
> > So, the most significant benefit may be in keeping that copy under 128
> bytes.
> >
> >
>
> > Ron
> >
> >
> >
> >
> >
> > Ju
On Thu., 4 Jul. 2019, 06:06 Tom Herbert, wrote:
> On Wed, Jul 3, 2019 at 12:44 PM Ron Bonica wrote:
> >
> > Hi Tom,
> >
> > Thanks for the review.
> >
> > On Friday, I will update draft-bonica-6man-comp-rtg-hdr. It will contain
> a section on mutability. It will say:
> >
> > - the Segments Left
Hi Ole,
On Fri, 30 Aug 2019 at 20:25, Ole Troan wrote:
>
> > End.B6.Insert specified in draft-ietf-spring-srv6-network-programming-01
> > will insert a new SRH in the received IPv6 packet, which results in two
> > SRHs in one IPv6 packet. It is contradict with RFC8200 that says Each
> >
On Sat, 31 Aug 2019 at 14:05, Zafar Ali (zali) wrote:
>
> Dear Chairs and the WG:
>
>
>
> The SRv6 network programming solution and its SRH encapsulation is
> implemented on 12 hardware platforms including Merchant Silicon.
>
> Multiple providers have deployed the SRv6 network programming
+1
The value in using a commodity protocol like RFC 8200 compliant IPv6
for something like SR is that you're gaining from IPv6 being well
understood, widely implemented, widely deployed, widely interoperable,
widely tested, and the major bugs have very likely already been
discovered. It's cheaper
On Sun., 1 Sep. 2019, 10:53 Fernando Gont, wrote:
> On 1/9/19 03:32, Mark Smith wrote:
> > +1
> >
> > The value in using a commodity protocol like RFC 8200 compliant IPv6
> > for something like SR is that you're gaining from IPv6 being well
> > understood, wi
On Mon., 2 Sep. 2019, 07:39 Robert Raszuk, wrote:
> Nick,
>
> How about using ULAs as defined in RFC4193 ?
>
I've analysed uSID in the context of all current IPv6 unicast address
formats in this email.
https://mailarchive.ietf.org/arch/msg/spring/Gsr-nJqzhyYIrj8mG6p3KZ_HZ5E
Short answer is
On Mon., 2 Sep. 2019, 07:30 Andrew Alston,
wrote:
> Robert,
>
>
>
> CRH works just fine with the deep label depth in our testing of it. As I
> stated in my previous emails – There are a number of issues with uSID that
> I can see – and I won’t repeat all of those here again. There are a whole
On Mon., 2 Sep. 2019, 07:56 Robert Raszuk, wrote:
>
> Yes Ron I saw this message from Bob and as you see from the mailer I
> responded with clarification on why this is not 2^112.
>
> While I do not understand why ULAs blocks must be globally unique (to me
> this is analogy of RFC1918 :)
>
RFC
On Mon., 2 Sep. 2019, 17:58 Robert Raszuk, wrote:
> Hi Mark,
>
>
>> The uSID proposal is taking the position that all the bits after the high
>> order prefix are available for any purpose. This is not correct, and would
>> violate a number of standards track RFCs, including the IPv6 Addressing
at this isn't and hasn't
happened.
The only issue is that if you happen to have hierarchical IGP you will not
> be able to summarize them - but I don't think that this would be a
> showstopper to any deployment.
>
> Best,
> R.
>
>
>
>
>
> On Mon, Sep 2, 2019 at 1
Hi Ron,
In an email a while back I think you mentioned that the SID space is
unique in the context of an address, where as this draft is saying
that SIDs have node-local significance, which I think means the same
single SID space across all the addresses of the node.
The reason I'm wondering is
read or type, but tells you nothing link or router specific. )
Regards,
Mark.
> Thank you,
> Joel
>
> On 8/28/2019 7:39 PM, Mark Smith wrote:
> > Hi Ron,
> >
> > In an email a while back I think you mentioned that the SID space is
> > unique in the context of an addres
On Thu, 5 Sep 2019 at 13:02, Ron Bonica
wrote:
>
> Fernando, Zhenqiang,
>
>
>
> You both have valid points. Maybe I am becoming too tolerant of deviations
> from the specification.
>
>
I think by definition RFCs are the authoritative definition of how
protocols and their implementations are to
On Thu, 12 Sep 2019, 00:56 Ron Bonica,
wrote:
> Pablo,
>
>
>
> So, to make uSID work:
>
>
>
>- You have to get a large block (e.g., /32) from your RIR
>- You have to allocate a smaller block (e.g., /48) to each router for
>uSIDs
>- You can’t use more specifics from that block
It's simple because IPv6 doesn't look past the fixed IPv6 header to perform
its forwarding, and matches on the Destination Address to determine if to
perform deeper packet host processing.
You're building much more complicated forwarding services if you're going
to be marching on TLVs etc. past
On Sat, 7 Sep 2019 at 13:05, Fernando Gont wrote:
>
> On 6/9/19 18:32, Chengli (Cheng Li) wrote:
> >
> > But I have a question:
> >
> > Why do these kind of arguments emerge right now instead of 5 years ago?
> > We left the “problem “ for 5 years? And suddenly we notice them? How
> > interesting.
On Wed, 11 Sep 2019, 13:46 Satoru Matsushima,
wrote:
> Hi Aijun,
>
>
>
> But the concept of SRv6+ is more clear than the SRv6(topology/service
> instruction separation;
>
>
> The SR architecture never require such things. See RFC8402:
>
> “Abstract
>
>
>Segment Routing (SR) leverages the
On Wed, 11 Sep 2019, 14:21 Satoru Matsushima,
wrote:
>
> On Wed, 11 Sep 2019, 13:46 Satoru Matsushima,
> wrote:
>
>> Hi Aijun,
>>
>>
>>
>> But the concept of SRv6+ is more clear than the SRv6(topology/service
>> instruction separation;
>>
>>
>> The SR architecture never require such things. See
On Wed, 11 Sep 2019, 06:49 Robert Raszuk, wrote:
> Hi Brian,
>
> > the first discussion should be whether we (as a community) believe we
> should
> > standardise features that only work within a specified domain, or
> continue with
> > the assumption that standardised features must work across
On Sat, 14 Sep 2019, 13:22 Xiejingrong, wrote:
> I agree with Joel, and strongly opposed to the proposal text !
>
> "The value TBD in the Next Header field of an IPv6 header or any extension
> header indicates that the payload content is identified via the segment
> identifier in the IPv6
On Tue, 17 Sep 2019 at 06:34, Brian E Carpenter
wrote:
>
> Pablo,
>
> On 17-Sep-19 07:44, Pablo Camarillo (pcamaril) wrote:
> > Hi Tom,
> >
> > I agree with your suggestion. What do you think of the following text?
> >
> >
> >9. IANA Considerations
> >
> >
> > This document requests
ling MPLS over SR over IPv4. I'm talking about native SR
over IPv4 e.g. "SRv4".
> Thx,
> R.
>
> On Sat, Sep 7, 2019 at 8:05 AM Mark Smith wrote:
>>
>> On Sat, 7 Sep 2019 at 14:58, Huzhibo wrote:
>> >
>> > Hi Robert:
>> >
>>
On Sat, 7 Sep 2019, 15:18 Bernier, Daniel, wrote:
> Hi Fernando,
>
>
>
> Let’s say I have a native *IPv6 application flow* to which I want to
> apply a service policy (i.e. chain of functions), carry metadata through
> TLVs or perform a very simplistic filtering action via the tag field. All
>
d by.
"Be conservative in what you send, ..."
Regards,
Mark.
> Thank you
> Zhibo
> -Original Message-
> From: Mark Smith [mailto:markzzzsm...@gmail.com]
> Sent: Saturday, September 07, 2019 2:04 PM
> To: Huzhibo
> Cc: Robert Raszuk ; Ron Bonica
> ; spring
On Sat, 7 Sep 2019 at 14:58, Huzhibo wrote:
>
> Hi Robert:
>
>
>
> Agree with you.
>
> SRv6 is a completely different technology from SR MPLS. The biggest
> difference is that SRv6's Sid itself has routing capabilities. For example,
> it is aggregatable, it is programmable, it is globally
On Sat, 7 Sep 2019, 09:00 Tom Herbert, wrote:
> On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk wrote:
> >
> > Sander,
> >
> > But this is exactly what both chairs of 6man did with the help of AD
> long time back. You must have missed it !
> >
> > And below is a link precisely written to address
able to forward at line speed.
>> But it’s a matter of how the platform is designed. If the ASIC is not
>> sufficiently capable, of course, it will not forward at line speed.
>> >
>> > In your email, you say that I have been asked several times to report
>> on the state
n your email, you say that I have been asked several times to report on
> the state of Juniper’s SRv6+ implementation. While I cannot provide
> details, you can assume that we wouldn’t be working on this if we thought
> that performance was going to be sub-optimal.
>
> You also suggest that Juniper’s is the only implementat
ghbors
over, the latter (non-forwarding) interfaces.")
> Ron
> Sent from my phone
>
>
> On Sep 18, 2019, at 8:33 PM, Mark Smith wrote:
>
>
>
> On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, wrote:
>>
>> SRv6 does not require TLV processing for normal forw
On Thu, 19 Sep 2019 at 11:16, Tom Herbert wrote:
>
> On Wed, Sep 18, 2019 at 5:33 PM Mark Smith wrote:
> >
> >
> >
> > On Thu, 19 Sep 2019, 09:40 Dirk Steinberg, wrote:
> >>
> >> SRv6 does not require TLV processing for normal forw
On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, wrote:
> Hi All,
>
> in todays SPRING session we have heard concerns about
> MTU efficiency in certain use cases involving SRv6.
>
> It is true that using 128 bit SRv6 SIDs trades scalability
> and flexibility against MTU overhead. There will
On Sun, 22 Sep 2019, 03:02 Voyer, Daniel, wrote:
> Hi Joel,
>
> Sent from my mobile
>
> > On Sep 21, 2019, at 00:54, Joel M. Halpern wrote:
> >
> > I see where the draft defines a set of constraints.
> > The constraint that there be no other extension headers is a fairly
> drastic constraint,
On Sun, 22 Sep 2019, 03:04 Tom Herbert, wrote:
> Some comments:
>
> Most of the constraints listed section 2.2 should be specified as
> normative requirements.
>
> "SR domain link MTU is sufficiently greater than the MTU at the
> ingress edge of the SR domain..." should be the requirement: "The
Supposedly "Segment Routing" is an architecture according to RFC 8402, so
anything that satisfies the architecture can use the term "Segment Routing"..
If SPRING want to play that game, then stop using "IPv6", because a number
of proposals blatantly and purposely don't comply with Internet
On Wed, 11 Dec 2019 at 10:39, Robert Raszuk wrote:
>
> Dear Fernando,
>
> Allow me to make something very clear here.
>
>> And, since we are at it, please let me know if IPv6 is and end to end
>> protocol. And, if it is, how does that e2e-ness work with inserting and
>> removing EHs on the path
at SRm6 would require a local mapping database to decipher those in
> CRH.
>
> On Tue, Dec 10, 2019 at 10:02 PM Mark Smith
> wrote:
>
>> Perhaps we need to update RFC8200 and eliminate the source address field,
>> or at least update it so that it can hold a multicast addre
On Sun, 15 Dec 2019, 03:07 Xiejingrong (Jingrong),
wrote:
> Hi Joel,
>
> Regrading this question:
> Do you have any comments on what appears to be the significant increase
> in complexity on the device performing PSP?
>
> I think the removal of some bytes from an packet header is a common case
>
On Fri, 13 Dec 2019, 07:50 Ron Bonica,
wrote:
> Pablo,
>
> I am not convinced the benefit derived by the ultimate segment justifies
> the price paid by the penultimate segment. Specifically,
>
> - the ultimate segment benefits because it doesn't have to skip over the
> SRH with SL == 0
> - in
philes
under the brand "Confirmation Bias". I figure I should get in on the $2900 USD
Ethernet cables market. Those 1s and 0s know which direction they're going,
and really care if it's the wrong way!)
> Cheers
> R.
>
> On Tue, Dec 17, 2019, 11:59 Mark Smith wrote:
>
>
On Tue, 17 Dec 2019, 21:12 Robert Raszuk, wrote:
> Hi Andrew,
>
> My personal opinion is that with below you are now going way outside of
> what should be discussed on IETF mailing lists. Hope SPRING charis will
> address it. IETF is not the right forum for any vendor implementation
> discussion
y cannot be
referred to as IPv4 or IPv6 addresses. It is confusing and inaccurate if
they are.
> Thanks,
> Ketan
>
> -Original Message-
> From: spring On Behalf Of Mark Smith
> Sent: 16 December 2019 06:36
> To: SPRING WG
> Cc: i-d-annou...@ietf.org
> Subject: Re: [sprin
"The endpoint indicates the destination of the policy. The endpoint
is specified as an IPv4 or IPv6 address and is expected to be unique
in the domain. In a specific case (refer to Section 8.8.1), the
endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6)."
Per Internet
uch
clearer that routes are being described.
Regards,
Mark.
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Mark Smith
> *Sent:* 16 December 2019 12:27
> *To:* Ketan Talaulikar (ketant)
> *Cc:* SPRING WG ; i-d-annou...@ietf.org
> *Subject:* Re: [spring] I-D Action:
&
s,
Mark.
>
>
> Ron
>
>
>
>
>
> *From:* Mark Smith
> *Sent:* Monday, October 14, 2019 4:08 AM
> *To:* Wang, Weibin (NSB - CN/Shanghai)
> *Cc:* Ron Bonica ; Robert Raszuk ;
> SPRING WG List
> *Subject:* Re: [spring] IPv6 Addresses and SIDs
>
&g
On Mon, 2 Dec 2019, 08:35 Bob Hinden, wrote:
> Ron,
>
> > On Nov 30, 2019, at 12:36 PM, Ron Bonica 40juniper@dmarc.ietf.org> wrote:
> >
> > Pablo,
> >
> >
> >
> > Consider the packet (SA,DA) (S3, S2, S1; SL) where:
> >
> >
> >
> > • SA is link-local (fe80)
> > • DA, S3, S2, and
On Sun, 22 Sep 2019 at 23:52, Robert Raszuk wrote:
>
> Hey Mark,
>
>
>>
>> The entire use of the word "insertion" is incorrect if the ID is now only
>> proposing encapsulation/tunnelling to carry transit traffic across the SR
>> domain.
>
>
> That is not what the discussed draft says. The draft
On Mon, 14 Oct 2019 at 09:57, Robert Raszuk wrote:
>
> Hi Ron,
>
> /64 prefix is a pile of addresses ...
It's more than that, there is an addressing model to follow. From RFC 4291,
"2.1. Addressing Model
IPv6 addresses of all types are assigned to interfaces, not nodes.
An IPv6 unicast
On Mon, 14 Oct 2019, 16:45 Wang, Weibin (NSB - CN/Shanghai), <
weibin.w...@nokia-sbell.com> wrote:
> Hi Ron:
>
>
>
> Make sense, If there is a dedicated IPv6 block for SRv6 SID within SRv6
> domain, then trouble situation you described does NOT occur, because the
> IPv6 address covered within
m: spring on behalf of Alexandre Petrescu <
> alexandre.petre...@gmail.com>
> Date: Thursday, 19 December 2019 at 09:44
> To: "spring@ietf.org"
> Subject: Re: [spring] 64-bit locators
>
>
>
> Le 19/12/2019 à 00:13, Mark Smith a écrit :
> [...]
>
On Thu, 19 Dec 2019, 04:16 Ron Bonica,
wrote:
> Folks,
>
>
>
> I am warming to the idea of fix-length,
>
I think fixed length or single size is always a good thing to aim for.
RFC5505, although about host configuration, sums it up the benefits very
well.
"Anything that can be configured can
Hi Pablo,
On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril)
wrote:
>
> Hi Ron,
>
> I guess we are making some progress here but going in some circles. So far we
> have moved from “this violates RFC8200” to “there are no use-cases or
> benefits” to “this is complex for an ASIC” to “what
e with existing deployments.
(I have no affiliation with any vendors, I fight for the users.)
>
> Cheers,
>
> Pablo.
>
>
>
> From: Ron Bonica
> Date: Monday, 24 February 2020 at 16:27
> To: Andrew Alston , Mark Smith
> , Sander Steffann
> Cc: SPRING WG , "Pab
nnot provide the requisite security services. Note that ESP can be
>used to provide only integrity, without confidentiality, making it
>comparable to AH in most contexts.)
> Thanks,
> Jingrong
>
> -Original Message-----
> From: spring [mailto:spring-boun...@ietf.o
5, "IPv1", 1974) didn't have a TTL field,
and I think they only added it because they eventually realised after 4
years that they weren't going to come up with a routing protocol that
didn't have transient loops.
Mark.
> Thx,
> R.
>
>
> On Wed, Feb 26, 2020 at 1:31 AM
On Sat, 29 Feb 2020, 06:55 Warren Kumari, wrote:
> On Fri, Feb 28, 2020 at 9:02 AM Robert Raszuk wrote:
> >
> > > interestingly enough MPLS took the same approach
> >
> > Well not really. As you know, MPLS unicast and multicast have a new
> ethertype.
>
> And this is a critical distinction --
On Thu, 27 Feb 2020 at 07:09, john leddy.net wrote:
>
> The understanding at IETF98 with rfc2460 moving to rfc8200 was that any
> tightening in header processing language was to get to an adopted standard
> and NOT to be used as club to bludgeon innovation by a small group of loud
> hummers.
>
Hi,
"3.1. SID Format" presents the structure of SIDs as fairly arbitrary
and up to the operator to choose:
"This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
where a locator (LOC) is encoded in the L most significant bits of
the SID, followed by F bits of function (FUNCT)
On Thu, 27 Feb 2020 at 18:52, Dirk Steinberg wrote:
>
>
>
> On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont wrote:
>>
>> Hello, Eric,
>>
>> On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
>> > Writing this without any hat,
>> >
>> > Please note that on the logical side, it still have to be "proven"
Hi Joel,
On Thu, 5 Mar 2020, 07:42 Joel M. Halpern, wrote:
> I think I have now inferred what the intended use case is for PSP. I
> really wish folks had stated it in full and explicitly, rather than
> implicitly a piece at a time, on the list.
>
> As noted below after the explanation, I
Hi Robert,
On Wed, 4 Mar 2020, 07:11 Robert Raszuk, wrote:
> Hi Ron,
>
> > MPLS PHP is a clear case of de-encapsulation.
>
> Purely looking at technical aspect that is not true at all.
>
Ron is correct.
> MPLS PHP does not remove label stack. MPLS PHP is just used to pop last
> label.
coped with.
You need to read and consider this Internet Draft. I wish it had existed 20
years ago.
IP Tunnels in the Internet Architecture
https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10
Regards,
Mark.
> Best,
> R.
>
>
>
>
>
> On Tue, Mar 3, 2020 at 10:42 PM
things like "MPLS is not link layer." suggests you think I have no
clue, and that makes this conversation a waste of time.
> I was only talking about MPLS on which topic I think I still have a little
> bit of remaining knowledge.
>
> Thx a lot,
> Robert
>
>
> On Tue
On Sat, 14 Dec 2019 at 09:14, Voyer, Daniel wrote:
>
> I agree 100% with Jingrong,
>
> PSP allows us to bring SRv6 to legacy PE devices that are not capable of
> processing the SRH in the dataplane, but are capable of supporting SRv6 in
> the control plane.
>
> See this example:
> I am
On Thu, 12 Dec 2019 at 05:37, wrote:
>
> Fernando,
>
> - Read the mailing list and you will see that everyone do not share your
> opinion. So at least one person is wrong. I think that it would help if
> everyone, including you, could consider that they/you _may_ be wrong, at
> least to
odified, so removal and insertion of EHs is not permitted. In-flight
removal before the final end-DA, which is the node that performs AH
verification, will cause AH verification to fail.
Regards,
Mark.
> There is no ignoring here.
> There is conscious and careful building on existing stand
This -11 draft was posted at 3:53 am Melbourne, Australia time, and this
declaration of consensus was at 5:35 am Melbourne, Australia time.
Sometimes I'm awake at those hours, but not last night. I did not have an
opportunity to review the changes.
Regards,
Mark.
On Tue, 3 Mar 2020, 05:53
On Tue, 3 Mar 2020 at 08:39, Mark Smith wrote:
>
> This -11 draft was posted at 3:53 am Melbourne, Australia time, and this
> declaration of consensus was at 5:35 am Melbourne, Australia time.
>
> Sometimes I'm awake at those hours, but not last night. I did not have an
> opp
Hi Ron,
On Fri, 28 Feb 2020 at 08:30, Ron Bonica
wrote:
>
> Jinmei,
>
> The current discussion is about Penultimate Segment Popping (PSP) (Section
> 4.16). Normally, when an IPv6 node processes a packet that includes a Routing
> header with Segment Left equal to 1, the node decrements Segments
Original Message-----
> From: spring on behalf of Mark Smith
>
> Date: Thursday, 27 February 2020 at 11:43
> To: "Voyer, Daniel"
> Cc: "Xiejingrong (Jingrong)" , "spring@ietf.org"
>
> Subject: [spring] A permanent change to/violation of RFC8200
On Mon, 24 Feb 2020, 07:47 Sander Steffann, wrote:
> Hi,
>
> > We have published a new update to
> draft-ietf-spring-srv6-network-programming. This revision simplifies the
> counters as per [1], clarifies the upper layer header processing as per [2]
> and removes the reference to the OAM draft
On Tue, 14 Jan 2020, 05:29 Joel M. Halpern, wrote:
> Let me try asking the question a different way. (I hope I understand
> Ron;s question.)
>
> RFC 4443 clearly allows the ICMP source to be the destination address of
> the offending packet. You seem to be saying that sometimes that is okay
>
On Thu, 2 Jan 2020, 08:07 Robert Raszuk, wrote:
> Hi Ron,
>
> Three observations:
>
> A)
>
> I am afraid feature or capability parity between SRv6 and SR-MPLS is far
> from equal. Sure if you consider just TE or VPN applications one could draw
> such a conclusion. However where I see SRv6
On Sun, 29 Dec 2019, 16:10 Miya Kohno, wrote:
> I agree with Robert.
> Modern language is generous about type ([*] as an example). C also has a
> concept of "union", though. .
>
We are talking about network protocols, not programming languages.
A union is an internal data representation
re. Questions like the following
>> must be answered:
>>
>>
>>
>>- From which special purpose prefixes [RFC 6890] can SIDs be drawn?
>>- Can a SID appear in the source address field of an IPv6 packet?
>>
>>
>>
>> So far, the co-authors have
On Sat, 28 Dec 2019 at 09:45, Robert Raszuk wrote:
>
> Hi Mark,
>
> Happy New Year !
>
>>
>> The key point is that RIDs look like IPv4 addresses, but are not. They only
>> have adopted the formatting convention of IPv4 addresses. They're 32 bit
>> quantities. They could have just as easily been
On Thu, 12 Mar 2020, 19:45 , wrote:
> IP addresses have been used outside of the strict "identifiers for
> interfaces".
> Apart from being used for routing, as a locator and as an identifier of
> course.
> Load-balancers / addresses for a service, NAT, NPT66, NAT66, MAP-E/T,
> anycast
expect non-authors of
> an original Internet standard to have to interpret the intent of the original
> authors rather than simply read the text as published, especially in the case
> of an Internet standard.
>
> Respectfully,
>
> Jim
> -Original Message-
> Fro
On Fri, 13 Mar 2020, 02:36 Andrew Alston,
wrote:
> Jim
>
> Given RFC2460 definition of a link I am wondering which “link” a loopback
> interface attaches to in your opinion?
>
>
>
RFC 4291 provides a definition.
"The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
It may
On Fri, 13 Mar 2020, 01:41 Fernando Gont, wrote:
> On 11/3/20 23:34, Brian E Carpenter wrote:
> > On 12-Mar-20 10:44, Fernando Gont wrote:
> >> On 11/3/20 18:30, Brian E Carpenter wrote:
> >> []
> >>>
> >>> However, I can't find anything in RFC 4291 that forbids addresses
> >>> having
On Wed, 18 Mar 2020, 03:39 Darren Dukes (ddukes), wrote:
> Hi Sander, such things as ‘pseudo interfaces’ are local behavior, they're
> implementation specific.
>
Given the protocol lawyering SPRING have been playing with RFC 8200, that's
never going through to fly when RFC 4291 says:
IPv6
On Tue, 17 Mar 2020, 04:39 Sander Steffann, wrote:
> Hi,
>
> > How this relates to NETPGM
> > - SRv6 SIDs are IPv6 addresses.
> > - SRv6 SIDs are not necessarily interface addresses.
>
> This will need some work, because according to
> https://tools.ietf.org/html/rfc4291#section-2.1: "IPv6
On Thu, 28 May 2020, 08:40 Robert Raszuk, wrote:
> /*adjusting subject */
>
> > The scope of CRH is “limited domain” and not the “Internet”.
>
The scope of SR-MPLS is also "limited domain", because, quite obviously,
after 20 years, MPLS isn't yet end-to-end across the Internet, never was
Are you a member of the IESG?
On Thu, 28 May 2020, 08:33 Zafar Ali (zali), wrote:
> Hi,
>
>
>
> The authors of CRH has already have multiple drafts and more CP/ DP
> changes will be required. E.g., it will require
>
>- ISIS changes (draft-bonica-lsr-crh-isis-extensions)
>- To carry VPN
Where are the IPv6+ Internet Drafts?
On Sat, 4 Jul 2020, 18:08 Lizhenbin, wrote:
> Hi Andrew,
>
> Thanks for your paying attention to the website. Please refer to my
> clarification.
>
>
>
> a. SRv6 is the technology based on IPv6. In the past 20+ years IPv6 has
> being deployed. One of the
CII string any
> vendor can use it as it seems fit their marketing strategy.
>
> Likewise others could still use other similar technology marketing or
> product names "IPv6^6", "IPv6NG", "IPv6@5G" etc ...
>
Of those, only 'IPv6@5G' doesn't imply extending IPv
On Tue, 16 Jun 2020 at 07:31, Robert Raszuk wrote:
>
> Hi Ron,
>
> True !
>
> But pls do not take my response as an attempt to derail your shot. It was
> rather a delicate attempt to put it on the right tracks towards the truth
> target.
>
The IPv6 addressing model is 25 years old, going by
On Sat, 9 Oct 2021, 22:40 Robert Raszuk, wrote:
> Hi Brian,
>
> > Which means: 64 bits.
>
> Sorry but what is so magic about /64 here ?
>
> Is this coming from the longest routable IPv6 prefix ? Sort of analogy to
> /24 in the IPv4 world ? Or something else ?
>
> I think LPM and CIDR techniques
1 - 100 of 118 matches
Mail list logo
