Hi,
> On this basis, I'm objecting to the adoption of
> draft-filsfilscheng-spring-srv6-srh-compression as a WG draft, and
> respectfully suggest that the spring wg does not adopt any draft in future
> which allows for different C-SID lengths but doesn't encode C-SIDs as
> {length,value} tuple
Hi,
> Just for my own understanding here.
>
> A) Are you asking to add new TLV to IPv6 SRH say called "C-SID Length" (and
> make SRH mandatory if used with C-SIDs) which would define the C-SID length ?
Yes, that would be a step in the right direction.
> B) Are you asking to define a comple
>> On 24.10.21 17:36, Nick Hilliard wrote:
>> The issue is a good deal deeper than just debugging. As long as there's an
>> option to specify a variable length parameter without being able to specify
>> the length in the protocol, then the protocol is fundamentally ambiguous and
>> its interp
Hi,
> Hi Ron, my read of section 4.1.1 of the draft is the dest opt in your example
> packet would be processed at every segment endpoint.
That seems very counter-intuitive…
Sander
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/l
Hi Andrew,
> As I have repeatedly stated in spring and will state so again here. In
> certain circumstances the use of C-SID breaks the checksums as relates to
> transit nodes. RFC8200 lays out specific processing rules for upper-layer
> checksums, and expressly deals with scenarios where th
Hi Mark,
> Right. I've done that. However, it is a convention, nothing more. In
> OSPF and BGP the RID is not an IPv4 address even if it looks like one,
> and is never used as an IPv4 address.
>
> SIDs are used as IPv6 addresses. When SIDs are used as IPv6 addresses,
> they must be compliant with
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 [3].
I still oppose the segment popping flavours in section
Hi Robert,
> Regardless if folks agree or not with that SRv6 is a new data plane. SRv6 !=
> IPv6 that's obvious.
>
> It also does not attempt to *extend* IPv6. It reuses some IPv6 elements and
> makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but that's
> it. With that in min
Hi Robert,
> No worries ... three IPv6 musketeers have already presented themselves well
> to this discussion. This was just one more demo of it. No need to apologize -
> at least me :)
>
> And while you can call someone's opinion the way you like - the fact that
> SRv6 builds on top of IPv6 d
Hi John,
> I would suggest that people read RFC 7282 - "On Consensus and Humming in the
> IETF"...
>
> My question is: How do you reach Consensus when the complaint is about how
> many milliseconds it takes to shoot down a proposal?
>
> Is this about the proposal or the vendor involved?
Defin
> Definitely the proposal. That a vendor seems to have an inappropriate amount
> of influence on the IETF process is just an additional concern.
PS: that the vendor is Cisco in this instance is not relevant. Any vendor doing
this would be equally bad. Any major vendor has played inappropriate ga
Hi John,
> So you are saying that other than the PSP issue, you support moving the
> document forward?
Yes. As long as it doesn't violate existing RFCs and with that potentially
causes trouble for implementations that expect those RFCs to be followed I'm
fine with it. It's not something I wou
Thank you for writing this down so well. This is exactly how I feel about this
issue too, but you are much better at staying polite :)
Cheers!
Sander
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi,
I have been thinking about SRv6 and the whole discussion around header removal
at one of the SR nodes. While I strongly see the current network programming
PSP function as a violation of RFC8200, one of the possible options is of
course to update RFC8200 to allow some things that are curren
Hi Andrew,
> This is certainly an interesting idea - and I'd probably need to give this a
> whole lot more thought before commenting properly, but the first thought that
> comes to mind is - would we be able to standardize a way to instruct like
> this.
>
> What I would not want to see is ever
Hi,
> In the bearer of srv6 traffic, srv6 domain is only one part of the whole
> packet journey. Because the srv6 domain is trusted by single operator, it is
> no necessary for the outer IPv6 header (for performing SRH function) to
> inherit all IPv6 extension headers specially designed for the
Hi,
> Please take a look at draft-herbert-6man-eh-attrib-00, I think it is
> very much in line with what you're thinking.
>
> The basic idea is that we create a new "Attribution" Hop-by-Hop
> option. The option serves two purposes:
>
> 1) If the source host sets the option in a packet then it is
Hi,
> I love your definition of "compromise": "You do what we tell you to do".
It's called "respecting the feedback from the working group"
Cheers,
Sander
signature.asc
Description: Message signed with OpenPGP
___
spring mailing list
spring@ietf.org
> ===
> D) formal decision to advance this document
> ===
> I'm listed as a contributor on this document (among 23 contributors).
> Even though I have zero specific write/modification privilege on the text in
> this document, and I'm not part of the authors email alias, thi
Hi Bruno,
>> Wait, what?! There is no "we needed to advance this document" in the IETF
>> or any other consensus based forum...
>
> By advance this document, I meant start the WG LC. Which is about collecting
> comments on the document.
I think you are confused. This document has been in WG L
Hi,
> My overall conclusion is that there is support and rough consensus to move
> this document to the next stage.
Declare consensus immediately after a new version is published and people
haven't even had the change to read it?
NO, just NO
Sander
signature.asc
Description: Message signed
Hi,
I am shocked by the declaration of consensus on
draft-ietf-spring-srv6-network-programming by Martin Vigoureux. There was much
discussion going on about one aspect of the draft, and there was clearly no
consensus amongst the participants. There are still questions that haven't been
answere
Hi Nick,
> At the very least, the consensus judgement needs to be rolled back. I
> respectfully suggest that Martin needs to recuse himself from any further
> involvement with this draft, and that he should consider whether his actions
> are compatible with continuing to be an AD.
Thank you,
Hi Ted,
> Without any comment on this particular instance, it is generally a good idea
> to go through an appeal of a specific decision first. My experience is that
> people do reconsider their actions in the light of appeals fairly frequently,
> and it is generally better to explore the option
Hi,
> I have no information about the situation but I do not understand why an AD
> would be declaring consensus in any case -
> that is normally the responsibility of WG chairs. see RFC 2418 section 3.3
The only active/available WG chair was a co-author of this draft.
Cheers,
Sander
Hi Bruno,
> Good.
> How do you propose that we get an evaluation and formal answer from the IESG
> on this point?
> My proposal is to ask while asking the IESG review on
> draft-ietf-spring-srv6-network-programming.
I think it's important that the answer can be used to improve the draft, so
wh
Hi,
> I guarantee you there is case the performance penalty is more than 90%, only
> if the box send the IPv6 packet with RH or EH to the slow path (just to be
> compatible with RFC8200)!
> And I think that's common even for not very old box.
So you are saying that we're going through all thes
Hi Mark,
> I think it serves a very important purpose, which is why I raised it.
>
> SRv6 SRH says IPv6 addresses can be assigned to nodes, contrary to RFC 4291.
> What is the Interface Identifier portion of the address called in that case,
> and where is it specified?
>
> There needs to be an
Hi,
> I believe the /20 example was what Softbank seems to be using for their (very
> large?) network and use-cases. It’s an example of how much IPv6 space they’ve
> got from ARIN. A millionth of that for SRv6 indicates a /40 (if I’ve got my
> maths right). Now, I don’t claim to be aware of Sof
Hi,
> So what is it that you and Andrew see in the net-pgm draft or the SRv6
> proposal that lead you to believe such a change in the IPv6 assignment or
> allocation sizes are required by RIRs?
Well, your example mentions that a /40 is used for SRv6 in a very large setup.
A regular business en
Hi,
> In this context, we are talking about allocations for the provider's
> infrastructure.
No, we’re not. Allocations are the superblocks that RIRs delegate to an LIR.
Before being allowed to use address space an LIR has to make assignments from
that allocation. It is that assignment policy
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 addresses of all types
are assigned to interfaces, not nodes.". I think
Hi,
> Hi Sander, such things as ‘pseudo interfaces’ are local behavior, they're
> implementation specific.
Then suggest another way to comply with RFC 4291.
Cheers,
Sander
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinf
Hi,
>>Having said that, the text about motivating PSP reads:
>> PSP allows, for example, for an egress PE to receive a packet
>> with a segment in the DA of the outer header without any need to
>> process the SRH.
>>is a very weak and confusing explanation. Given
Hi,
> * Appellants:
>
> Fernando Gont
> Andrew Alston
> Sander Steffann
Just to confirm: this was written and sent with my knowledge and approval. I
fully support this appeal.
Cheers,
Sander
___
spring mailing list
spring
Hi,
> The sole purpose of a Routing header is to steer a packet along a specified
> path to its destination. It shouldn’t attempt to do any more than that.
>
> The CRH does not attempt to deliver service function information to service
> function instances. However, it is compatible with:
>
>
Hi James,
> This separation of architecture is not new; see
> https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/ in the SPRING WG.
My apologies, I didn't mean to imply that all SPRING drafts did not specify a
good architecture. The ones that don't have gotten me frustrated, and that
fr
Hi Robert,
> Your below list looks like custom made set of RFP requirements to eliminate
> any other vendor or any other solution to solve the problem at hand rather
> then rational list of requirements.
My main customer (an ISP in NL) would fit exactly in the list that Ron sent.
They want a s
Hi,
> That CRH is simple is a bit like claiming that MPLS is simple just because
> the header has few fields.
> I think you would be hard pressed to substantiate that any solution here is
> particularly simpler than any other. But you are welcome to try.
As a user I usually find:
Fewer fields -
Hi,
> The slight hostility I detect in your replies, I suspect has more to do with
> the particular employer hat I also wear as opposed to the chair hat.
Sigh. Who calls a WG chair to order when making unsubstantiated accusations in
reply to a simple request?
I find Ole's behaviour to become ve
Hi,
> Take a step back, assume SRm6 is also adopted, there will be two solutions
> for the community to choose; there will be interop issues between the two
> solutions. The vendors will have to support both to make different customers
> happy, more money will be spent and will be finally payed
Hi Wim,
> I agree that if you look into the details RFC8663 from a data-plane operation
> is very similar to CRH. It uses a tag and derives a destination ipv6 address
> from it.
> On top it if you look at the requirements, the following is possible with
> RFC8663
>
> • It can steer the p
Hi Wim,
> It does work across domains that are not directly connected, but that
> scenario is not well described I have to admit. The operation is as I said
> very similar to CRH.
> Think of the MPLS tag as the same as the SID tag in CRH. From a data-plane
> all packets on the wire will use v
Hi Wim,
> WH> in the same way as you get CRH across the Internet. It is a tag
> encapsulated in an IPV6 header. It uses ipv6 encap based on RFC4023.
That assumes that there is always a router that adds an encap to an existing
packet. I want to look beyond that and allow for end nodes participat
Hi Wim,
> WH> Sander RFC8663 is supported in linux and various implementations. You
> can do the encap in the same way as you have done with CRH w/o a router doing
> the encap.
You misunderstand. I don't want any encap overhead, I just want IPv6 packets...
Cheers,
Sander
__
Hi Wim,
> WH> Why would it matter if I add the sids in an Extension Header, versus
> through a Next header. As long as we achieve the same goal why would you
> care?
I don't understand what you mean. If you're talking about encapsulation, I care
because of the overhead. If you're talking abou
Hi Wim,
> Wh> Nothing is put in the payload when using RFC8663. The SID list is put in
> a next header field as per RFC 4023, whereas in CRH you put them in an EH,
> but the payload is intact. I have not done the exact calculation on the wire,
> but they are almost the same in size wrt overhead
Hi Wim,
> WH> We are either all encapsulating or not, but in essence the point is that
> the difference is you put the sids in the extension header versus next
> header. Lets leave it like this. All in all what I am saying is RFC8663
> allows you to do what you intend with CRH.
No, I can't. Yo
Hi,
> WH> what you are saying I only want a CRH solution and you are not open to
> anything else, because the SIDs are not in the right place.
No, that is not what I said. Please stop twisting my words. I want to steer a
packet without needing to encapsulate it. Why is that so hard to understan
Hi,
> draft says:
>
> Is designed to operate within a network domain.
Source and destination are in the same domain. Who says that the domain is
contiguous? Let's change the example to main and branch offices. Same
administrative domain, while still traversing the internet.
Cheers,
Sander
_
Hi!
Someone just reminded me of my age… I am of the generation of simple Lego
blocks, and still prefer the classical plain bricks to the modern ones where
they create special bricks just for one or two models. I guess that preference
also applies to my preferences in protocol design :)
Cheers!
Hi Gunter,
> A powerful property of RFC8663: No need for kernel access by applications
That assumes that there won't be an API at some point in the future. That's not
a good argument against any protocol.
Cheers,
Sander
signature.asc
Description: Message signed with OpenPGP
_
Hi Andrew,
> What I find so bizarre is –
>
> You have an multiple operators – who have clearly said – we want this – we
> see advantage of this. Yet still the obstructionism and denialism continues.
> The “not invented here” syndrome seems to run deep – and email after email
> is patently ig
Hi Robert,
> There can be a lot of acronymous or names invented but under the hood it 16,
> 32 or 20 bit opaque bit string in both CRH and SR-MPLS which is mapped to a
> rewrite string. No more no less.
So far so good
> And rfc8663 precisely automated such rewrite to UDP encapsulation.
And th
> And this is an important difference: some of us don't want
> encapsulation/tunneling, we want something that can be part of a
> non-encapsulated packet. There are use-cases where CRH used with
> encapsulating is the best solution, and there are cases where the packet
> itself can be steered w
Hi Wim,
> Sander, can you describe your use case. So far the only thing that people has
> asked CRH to do is steering and as mentioned we have solutions for those. If
> there are others, please share them..
Well, a routing header is obviously for steering, but not only encapsulated
payloads ne
Hi Joel,
On 07-07-2020 18:24, Joel Halpern wrote:
> The Design team will be
> Co-Chaired by:
> Cheng Weiqiang of China Mobile and
> Sanders Steffann of SJM Steffann Consultancy
Minor typo in my first name (Sander) but no harm done :)
> The other members of the team are:
> Ron Bonica
Hi,
> Ron,
>
>>
>>
>> Folks,
>>
>> Sections 4.4 through 4.12 of draft-ietf-spring-srv6-network-programming-00
>> define a set of SIDs that have the following things in common:
>>
>> - they are consumed by the egress node (SL == 0)
>> - they tell the egress node how to forward the payload int
Hi Reji,
> SRv6+ confirms to the V6 architecture, explains the rationale behind the
> design and is non ambiguous to start with. Till now there has not been any
> valid shortcomings brought forth with the Srv6+ design. I saw a mention that
> SRv6+ needs to distribute the SID to address binding
Hi Ole,
> I think you have repeatedly made your point.
Yes he has, and he makes a good point that should be heard. Your argument of
"RFCs aren't the law, and we can ignore parts of them if it suits us" just
isn't true. RFCs are based on consensus, and ignoring the outcome of that
consensus whe
Hi Ole,
> I don’t see a need to continue this debate on meta issues, but since you
> framed this as criticism of me in the chair role I found it required to
> reply.
I expect the chair to uphold a previously reached consensus and put the
requirement of justifying deviating from it with the on
Hi Ole,
> Proposals are judged on their merits.
> There is no protocol police.
There is existing consensus, and changing that requires consensus on the
changes. The onus is on those wanting the change, yet you demand the ones
referring to the existing consensus to defend themselves. That is n
Hi Robert,
> All SRv6 existing specs can progress just fine with that last mode of
> insertion being removed if rough consensus in 6man would not get reached.
My problem is that Fernando is being told to defend the existing RFC. That is
wrong. It is up to the SRv6 proposers to argue and defend
Hi,
> What consensus has been reached that you are referring to?
The consensus on the text of RFC8200.
Cheers, sander
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Ole,
> I don’t see a need to continue this debate on meta issues, but since you
> framed this as criticism of me in the chair role I found it required to reply.
Following up now that I had some rest :)
I consider you a friend, and I respect you a lot. Which is why the way you were
approachi
Hi,
I noticed this bit of your message, and it made me think.
> With regards to your points about its all already developed – are you really
> telling me that because the authors chose to go and spend ages developing
> something while taking zero cognizance of the consensus in the community on
> [ZA] Please refer to section 3 of SRv6 deployment draft,
> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01#section-3.
> It provides some details on the Significant industry collaboration that led
> to SRv6 standardization. SRv6 standardization went through the ri
Hi,
> That was my point in the email thread “Regaining Focus on SRv6 and SRv6+”;
>
> • SRH has been around since 5 years with now 22 versions the last call
> is done, it’s on its way to become an RFC
> • ISIS/SRv6 is out there since 2015 with lots of iterations
>
> After all these y
Hi,
> If you say you are an operator, and ask us to disclose on where, for what,
> scale and use case, please describe yours at first in very detail.
ISP in The Netherlands, between 50k and 100k customers three datacenters,
multiple interconnect locations, currently using MPLS for L2VPN (as lit
Hi Robert,
>> Because many problems are identified in the current work
>
> Please kindly enumerate technical problems which got identified. It will be
> actually very helpful list.
>
>> It's not needs/requirements, it's mostly the lack of a KISS approach
>
> Not all vendors are falling into th
Hi,
> No. And that is why I want SRv6+ to move forward, to avoid getting trapped in
> the SRv6 walled garden.
>
> The way IETF works (at least in vast majority of WGs) is that if you do not
> like a specific element of a solution or if something is missing from any
> solution during WG process
Hi Wim,
> WH> Would you be ok with this?
> https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07, support segment
> routing over IPv4 and/or IPv6.
No, I don't want to have to manage both MPLS and tunnels. That only adds
complexity.
Cheers,
Sander
signature.asc
Description: Message sign
Hi Andrew,
> There is a phrase that I have heard – and perhaps it applies here – perhaps
> we need to put our guns down – and find a way to in which we can move forward
> that while it probably will not satisfy everyone, will be in the interests of
> the market in general by avoiding a total st
Hi Robert,
> Your line of thinking is correct but please no more additional levels of
> abstraction. Why not just use normal routable prefix on the node as part of
> the instruction ?
How large a prefix do you envision is needed per node? What size are we talking
about (roughly)?
Cheers,
Sand
Hi,
> Hi Ron, to follow up on what was said at the mic.
>
> The current community analysis, comparing existing solutions (SRv6 and
> SR-MPLS for IPv6) with SRm6, had the following result:
> - a lot of differences (Architecture, Dataplane, Controlplane) and hence
> engineering cost
A different
Hi Bertrand,
> If this is not an IETF Business (like suggested by Andrew Alton), I do
> suggest this irrelevant threat to be abandon/drop from the IETF SPING mailing
> list.
I disagree that is not IETF business. I think it is very much IETF business
when participants in the IETF knowingly mi
Hi Ole,
> If I own and manage three routers, R1 -- R2 -- R3.
> You are saying that if R1 sends a packet to R3, it is not allowed to off-load
> some functions to R2?
> Going to be difficult to do stuff like service chaining then.
This bit I don't mind that much, but what about:
R1 -- R2 -- [open
Hi,
> This email starts a two weeks Working Group Last Call on
> draft-ietf-spring-srv6-network-programming [1].
>
> Please read this document if you haven't read the most recent version, and
> send your comments to the SPRING WG list, no later than December 20.
I think there are plenty of alr
Hi Robert,
> To your specific first question this is very popular deployment model ...
> just look at SDWANs. So Internet is just a L3 transport for all routers in
> your administrative domain or global WAN. Spot on. I do sincerely hope that
> whatever the result be of this debate all features
Hi Ole,
>> I don't think there is much room for interpretation here, but anyway I
>> should ask: are you suggesting that I have attacked or been attacking
>> the process?
>
> I would rather say taking advantage of the process.
>
> By reiterating the same assertive arguments again and again you c
Hi Ole,
> I am not suggesting that header insertion is the _best_ approach. That I
> tihnk has to be evaluated on a per use case basis.
> I just want to see if we can reach agreement that it's a solution candidate,
> that given the deployment restrictions is technically sound.
If the mechanisms
81 matches
Mail list logo
