Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

f DPI, exactly as a new Ethertype would. Regards Brian -- tony On Fri, Mar 31, 2023 at 9:00 PM Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote: On 01-Apr-23 06:18, Ron Bonica wrote: > On second thought, if we had the new ethertype, we wouldn’t need the new

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

On 01-Apr-23 06:18, Ron Bonica wrote: On second thought, if we had the new ethertype, we wouldn’t need the new /16! They serve the same function However, a new special-purpose prefix is rather trivial to deploy compared with a new Ethertype. Brian  

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

On 30-Mar-23 21:00, Tony Przygienda wrote: +1 Joel AFAIS it's same effort to upgrade something to process SRH or to process new ethertype properly. And in a sense upgrade to something that drops ether type SRv6 if it's not supposed to be processed is no upgrade today, routers as per today

Re: [spring] [Int-area] FW: New Version Notification for draft-raviolli-intarea-trusted-domain-srv6-00.txt

Robert, On 30-Mar-23 01:10, Robert Raszuk wrote: Nope, that is completely not what I have in mind, Please remember that transit nodes are not SRv6 aware in closed or open domain, So my site A (car) can be using SRv6 via any IPv6 transit uplink Only if the SRv6-carrying IPv6 packet is

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Dirk, I'm not picking on your message particularly, because the comment below could be made on many of the messages on this thread: On 11-Oct-22 04:51, Dirk Steinberg wrote: Well, an IPv6 packet with an SRH first of all is a legal IPv6 packet. Dropping of IP packets which are not malformed by

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

On 10-Oct-22 11:49, Robert Raszuk wrote: Hi Brian, Easily avoided by another layer of encapsulation, surely? Personally I would want to do that, and to use an encrypted encapsulation, to make sure that the SR domain is not penetrated. I am not even sure what you call SR domain ... In

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

o forwarding IPv6 packets with SRH (or any other extension header) and the other thing is to on purpose recommending killing it at interdomain boundary as some sort of evil. Cheers, R. On Sat, Oct 8, 2022 at 9:51 PM Brian E Carpenter mailto:b

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Robert, If there is any spec which mandates that someone will drop my IPv6 packets only because they contain SRH in the IPv6 header I consider this an evil and unjustified action. The Internet is more or less opaque to most extension headers, especially to recently defined ones, so I don't

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

On 29-Sep-22 16:06, Gyan Mishra wrote: ... We should qualify the IANA request to make the /16 non internet routable identical to ULA addressing. If that is what we desire then why don’t we make it standard BCP to always use ULA for the operators SRV6 domain. I don't believe that a /48

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Hi, I think this draft is just about ready. A few comments: shall we specify that it MUST NOT be in the DFZ I think the "DFZ" concept is too vague these days and will distract from the main message. (Also, this is informational, so we can't say MUST NOT.) So it would be good to tighten up

Re: [spring] Requesting comments on draft-krishnan-6man-sids-00.txt

I find this draft useful and its suggestion of a dedicated prefix would clear up some ambiguity. I think it would need to be standards track to make that prefix assignment. I think section 4.1 "Open Issues to be Addressed with C-SIDs" needs to be actioned by SPRING so that it can be removed from

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

with dynamic routing protocols or only from a centralized controller? Regards, Greg On Sun, Oct 24, 2021 at 2:20 PM Brian E Carpenter mailto:brian.e.carpen...@gmail.com>> wrote: On 25-Oct-21 09:23, Eliot Lear wrote: > > On 24.10.21 21:59, Nick Hilliard wrote: >> Elio

Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

On 25-Oct-21 09:23, Eliot Lear wrote: On 24.10.21 21:59, Nick Hilliard wrote: Eliot Lear wrote on 24/10/2021 18:17: 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

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

part of that "funny" bottom 64 bits? And if any part of the bottom 64 bits must be used, how one can guarantee that CIDR still works in that domain? > > Regards, > Greg > > On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter > mailto:brian.e.carpen...@gmail.com>&g

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On 20-Oct-21 05:02, Tom Herbert wrote: > > > On Tue, Oct 19, 2021, 12:10 AM Mark Smith <mailto:markzzzsm...@gmail.com>> wrote: > > Hi Brian, > > On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter > mailto:brian.e.carpen...@gmail.com>> wrote: &g

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi, After reading a lot of messages, I'm going to offer my considered opinion as a direct response to Joel's OP. Firstly, I don't believe that in the end this draft raises any concerns that are *significantly* different than those raised when RFC 8986 was in draft. As Ted Hardie mentioned,

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Ted, On 18-Oct-21 20:22, Ted Hardie wrote: > Hi Brian, > > Thanks for the additional clarification.  I've cut below to the meat of what > I understand to be your question: > > > On Sat, Oct 16, 2021 at 10:19 PM Brian E Carpenter > mailto:brian.e.carpen...@gmail.com&

Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

On 18-Oct-21 13:35, Tom Herbert wrote: > > > On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter <mailto:brian.e.carpen...@gmail.com>> wrote: > > On 18-Oct-21 09:39, Tom Herbert wrote: > > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith <mail

Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

ource address has interesting implications. >> >> Regards, >>     Brian Carpenter >>     (via tiny screen & keyboard) >> >>   >> >> On Sun, 17 Oct 2021, 18:58 Mark Smith, > <mailto:markzzzsm...@gmail.com <mailto:markzzzsm...@gmail.com>

Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression)

On 18-Oct-21 09:39, Tom Herbert wrote: > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith wrote: >> >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, wrote: >>> >>> Mark Smith wrote: >>> > In fight changing DAs also will break AH protection of the IPv6 >>> header. >>> >>> AH is dead. It's been

Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

ples supplied stands. Using this as a source address has interesting implications. > > Regards, >     Brian Carpenter >     (via tiny screen & keyboard) > >   > > On Sun, 17 Oct 2021, 18:58 Mark Smith, <mailto:markzzzsm...@gmail.com>> wrote: > > On Sun, 17

Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

> I can't find anywhere that an interface identifier of zero is forbidden However, when I assign such an address to a Linux box, it is unpingable, so I'm guessing it breaks neighbor discovery. Regards Brian Carpenter On 17-Oct-21 13:31, Brian E Carpenter wrote: > Thanks for this

Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Thanks for this draft. Question: where you show "Source address 2001:db8:a:1100::" is that intended to be the complete address, because it looks like a prefix? I can't find anywhere that an interface identifier of zero is forbidden, but it's unusual, and can only exist once in a given subnet.

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Ted, On 15-Oct-21 23:39, Ted Hardie wrote: > On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter > mailto:brian.e.carpen...@gmail.com>> wrote: > > On 14-Oct-21 22:41, Ted Hardie wrote: > > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter > mailto:

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On 14-Oct-21 22:41, Ted Hardie wrote: > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter > mailto:brian.e.carpen...@gmail.com>> wrote: > > > > Including semantics *of any kind* in an IP address is a very fundamental > change to the concept of IP.<https:/

Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Joel, On 13-Oct-21 20:37, Joel M. Halpern wrote: >> 1) Does the placement of a list of sids in the IPv6 DA field change the >> IPv6 architectural description of that field. That's why I recently asked for a set of examples of the resulting "addresses". I don't understand enough of SRV6 to

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Could somebody provide a copious set of *example* IPv6 addresses that conform to draft-filsfilscheng-spring-srv6-srh-compression? I means the actual addresses in standard IPv6 address notation (RFC5952) or just as 0x hex numbers. BTW, is there running code for srv6-srh-compression?

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On 10-Oct-21 10:04, Robert Raszuk wrote: > > Please kindly correct me if I am wrong, but where do you see that SRv6 is > mandated to use "IPv6 Interface IDs" ? I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that doesn't apply to SRV6, then it's impossible to claim that

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On 10-Oct-21 09:26, Robert Raszuk wrote: > > Hi Brian,  > > > >> Which means: 64 bits. > > > > Sorry but what is so magic about /64 here ? > > It is mandated by the current IPv6 addressing architecture. > > > Really ? Where ? I am looking at RFC4291 and nowhere I can

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

This would all be much simpler if the SRV6 community explicitly dropped the claim to be implementing standard IPv6. Whether the IETF wants to standardise something at layer 3 that isn't IPv6 is a separate question. It is pretty obvious that if spring adopts this draft and if it comes to IETF

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On 10-Oct-21 00:39, Robert Raszuk wrote: > Hi Brian,  > >> Which means: 64 bits. > > Sorry but what is so magic about /64 here ? It is mandated by the current IPv6 addressing architecture. Despite many discussions, there has never been consensus to change it. So if /64 is not the boundary

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On 09-Oct-21 06:03, Vasilenko Eduard wrote: > Hi Tom, > > It is not related to CSID. Because it is not important how IP address is > prepared, it should be IP address at the time of writing to DA field. And it > is. > >   > > You are asking more general question: what was the legal reason to

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

I'm less interested in the definition of an "interface" than I am in the bits in an Interface Identifier (i.e. the bottom 64 bits of an address). There is a formal update of the addressing architecture on this very point. https://www.rfc-editor.org/rfc/rfc7136.html#section-5 says: ...the

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On 05-Oct-21 23:09, Robert Raszuk wrote: > Tony, > > I am afraid you missed my point :(  > > Any IP address can be split into routable part and non routable part (or > perhaps to be more correct globally routable part and locally routable part).  > > So I am not contradicting myself at all

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On 05-Oct-21 10:15, Robert Raszuk wrote: > Hi Ron, > > Your below example has nothing to do with Internet Standard violation.  > > You are free to define new ethertype and new IP header format any time you > wish to do so.  > > Obviously it can not be called IPv6 any more as it is not

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

ttempted analysis of this issue at https://www.rfc-editor.org/rfc/rfc8799.html#name-the-scope-of-protocols-in-l (which is not, of course, an IETF document). Brian > > --- tony > > > > > > On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter <mailto:brian.e.carp

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Ron, The first sentence cites RFC8402 which unambiguously describes SR as a limited domain protcol (limited to an "SR domain", that is.) So within such a domain, this describes using 128 bit quantities called Segment Identifiers that in some cases, but apparently not in the formats defined

Re: [spring] Last Call: (SRv6 Network Programming) to Proposed Standard

Section 4 of [RFC8200] because the destination address of the incoming > packet is the > address of the node executing the behavior. > > > > -Original Message- > From: Brian E Carpenter > Sent: viernes, 21 de agosto de 2020 0:06 > To: last-c...@ietf.org

Re: [spring] Last Call: (SRv6 Network Programming) to Proposed Standard

IMHO there is still a logical defect in the description of the PSP flavor at https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-17#section-4.16.1 The description of the PSP flavor considers the packet to have (Segments Left == 0 and Destination Address == the PSP node's

Re: [spring] Limited domains ...

On 28-May-20 10:39, Robert Raszuk wrote: ... > Maybe we should just drop right here this "limited domain" restriction/scope > for any solution being discussed here ?  In that case we should definitely never have adopted draft-ietf-6man-segment-routing-header, whose first reference is RFC8402,

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

On 28-May-20 09:50, Robert Raszuk wrote: > Andrew, > > I don't think this is about killing innovation. After all no one is saying > you can not use it in your network.  > > WG acceptance calls Adoption is not acceptance. At least half the messages on this topic are written as if we were in

Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

On 28-May-20 07:18, Zafar Ali (zali) wrote: > WH> My position remains that RFC8663 is a valid alternative and is available; > I am against WG adoption of CRH. > > The industry widely supports RFC8663. Can you remind us which major operators rely on RFC8633 today? After all, the RFC is only 5

Re: [spring] How CRH support SFC/Segment Endpoint option?

On 25-May-20 09:08, Tom Herbert wrote: > On Sun, May 24, 2020 at 3:23 AM Robert Raszuk wrote: >> >> Hi Ron, >> >> I have one small question on the Destination Option Header you keep >> referencing to carry for example VPN demux instructions. >> >> As DOH follows Fragment Header it is indeed

Re: [spring] How CRH support SFC/Segment Endpoint option?

Hi Robert, On 24-May-20 22:22, Robert Raszuk wrote: > Hi Ron, > > I have one small question on the Destination Option Header you keep > referencing to carry for example VPN demux instructions.  > > As DOH follows Fragment Header it is indeed inspected before CRH.  > > So please kindly clarify

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

On 22-May-20 03:35, Zafar Ali (zali) wrote: > There is a clear need for documenting a genuine use-case & architecture for > CRH beyond SPRING, before adoption. Why? We are only deciding whether to pass editorial control of the draft to the WG. If the WG wants to add text about the use

Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

On 22-May-20 05:26, Ketan Talaulikar (ketant) wrote: ...> It is the 6man charter that precludes it from defining a new Source Routing solution.. > “It is not chartered to develop major changes or additions to the IPv6 > specifications.” If this addition was major, that would be true. But adding

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

ink that I am being pretty > pedantic here – but considering the context and the claims floating around > about what other RFC’s say and don’t say – perhaps its time to start > examining this whole thing with a fine tooth comb so that we can end up with > a better result that works for every

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

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 semantic meanings rather than being pure locators. It goes >> against one of my desig

Re: [spring] Draft-ietf-spring-network-programming ipv6 addressing architecture - was draft-ietf-6man-segment-routing-header-26 violating RFC4291, IPv6 Addressing Architecture?

On 12-Mar-20 09:53, Andrew Alston wrote: > Hi Spring WG > >   > > On the basis of the below – I must conclude that the issues relating the > SID/IPv6 semantics have indeed not been dealt with by the spring working > group in the context of the network programming draft – and I would now like

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

On 12-Mar-20 05:06, Alexander Vainshtein wrote: > Darren, > > Lots of thanks for the clarification. > >   > > However, I have several issues with your response: > > 1.   The SRH draft is a 6MAN document. I am not sure if the provision for > new documents defining new SID types and their

Re: [spring] Dispute process (Was: Resignation request)

On two specific points: On 11-Mar-20 12:55, Nico Williams wrote: > Q: How many appeals have there been, and how many have succeeded? Officially, the history is at: https://www.ietf.org/standards/process/appeals/ https://www.iab.org/appeals/ I think a lot of the responses are midway

Re: [spring] Dispute process (Was: Resignation request)

Nico, On 11-Mar-20 07:45, Nico Williams wrote: > On Tue, Mar 10, 2020 at 12:11:47PM -0500, Pete Resnick wrote: >> On 10 Mar 2020, at 10:41, Nico Williams wrote: >> >>> ...the process we have for >>> dealing with complaints is heavily biased against plaintiffs -- which is >>> probably as it should

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

> If we argue this behavior as not violating "extension headers cannot be > removed from a packet until it has arrived at its ultimate destination" That is not, perhaps unfortunately, what RFC 8200 says. Regards Brian Carpenter On 05-Mar-20 17:08, Ketan Talaulikar (ketant) wrote: > Hi

Re: [spring] PSP and a logical application of RFC8200

t; I have just made this change to the draft. > This is the only change for revision 12. > > Many thanks, > Pablo. > > -Original Message- > From: Brian E Carpenter > Date: Tuesday, 3 March 2020 at 22:17 > To: "Pablo Camarillo (pcamaril)" , >

Re: [spring] PSP and a logical application of RFC8200

does not contravene section 4 of [RFC8200]* > > *because the current destination address of the incoming packet* > > *is the address of the node executing the PSP behavior.* > > ** > >   > > Additionally, please find some replies inline to the comments from Bru

Re: [spring] PSP and a logical application of RFC8200

t; > Many thanks, > Pablo. > > -----Original Message- > From: ipv6 on behalf of Brian E Carpenter > > Date: Monday, 2 March 2020 at 20:34 > To: "Darren Dukes (ddukes)" , 6man WG > , SPRING WG List > Subject: Re: PSP and a logical application of RF

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-11.txt

The explanations added to section 4.16.1 "PSP: Penultimate Segment Pop of the SRH" certainly help. However, there is still no explanation of how this section is reconciled with RFC 8200. Whether the reader agrees with that reconciliation or not is a separate matter, but I fail to see how this

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Martin, On 03-Mar-20 07:53, Martin Vigoureux wrote: > WG, > > as I had indicated in a previous message I am the one evaluating > consensus for this WG LC. > > I have carefully read the discussions on the list. I acknowledge that > disagreements were expressed regarding what a particular piece

Re: [spring] PSP and a logical application of RFC8200

Darren, Regardless of whether you accept Fernando's comment about the intention of RFC 8200, there is also the fact that the description of the PSP flavor cheats by considering the packet to have (Segments Left == 0 and Destination Address == the PSP node's address). In fact that is *never*

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

On 01-Mar-20 07:25, Robert Raszuk wrote: > Hi John, > > I respectfully will disagree with your assessment.  > > Reason #1 - IPv6 can be encapsulated in IPv6 - RFC2473. This is base of SRv6 > operation. If this would be deprecated, moved to historic or made illegal - > games over. But if this

Re: [spring] Suggest some text //RE: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Hi Jingrong, Thanks for your suggestion. > so that the tunnel endpoint > router (C) doesn't have to deal with SRH. Actually, why does this matter? RFC8200 already handles this case: If, while processing a received packet, a node encounters a Routing header with an unrecognized Routing

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Bruno, Thanks for this. Please view what follows with a non-proportional font. Here's my understanding of the scenario we are talking about: A >B-->C | ^ | | \ / X>Y>Z The normal path is

Re: [spring] "penultimate segment" [Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming]

On 28-Feb-20 15:06, Stefano Salsano wrote: > Brian, > > Il 2020-02-28 02:47, Brian E Carpenter ha scritto: >> Stefano, >> >> The problem is that the draft simply doesn't explain (or refer to an >> explanation) of what this "penultimate segment" is. Ther

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

d in the section title, but it has been > removed from the definition of the behavior. > > Could you please see the latest version of the draft? > > Thanks, > Pablo. > > -Original Message- > From: Brian E Carpenter > Date: Wednesday, 26 February 2020 at 21:57 >

[spring] "penultimate segment" [Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming]

ns by "pop" and by "penultimate segment". If it turns out that we are in case 2) or 3) above, problem solved. Regards Brian Carpenter On 28-Feb-20 00:42, Stefano Salsano wrote: > Brian, > > Il 2020-02-27 03:29, Brian E Carpenter ha scritto: >> Stefano, >> On 27-Feb-20

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Stefano, On 27-Feb-20 14:42, Stefano Salsano wrote: > Il 2020-02-27 02:14, Brian E Carpenter ha scritto: >> Eric, >> >> On 27-Feb-20 12:18, Eric Vyncke (evyncke) wrote: >>> Writing this without any hat, >>> >>> Please note that on the logical side,

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Eric, On 27-Feb-20 12:18, Eric Vyncke (evyncke) wrote: > Writing this without any hat, > > Please note that on the logical side, it still have to be "proven" that this > idea is strictly forbidden by RFC 8200. The draft uses an undefined term ("pop") but it does *explicitly* state in a

Re: [spring] 6man w.g. last call for

To be clear about one of the points in the review, MAY NOT is not allowed by RFC2119 because it is totally ambiguous in English (since it can mean either "must not" or "might not"). In any case the phrase "MAY or MAY NOT" is not of any normative value. It presumably simply means "MAY" in all

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

Comment at the end: On 21-Dec-19 06:30, Pablo Camarillo (pcamaril) wrote: > Inline. > > Thanks. > > -Original Message- > From: Brian E Carpenter > Date: Thursday, 19 December 2019 at 22:39 > To: "Pablo Camarillo (pcamaril)" , "spring@ietf.org&

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

On 20-Dec-19 22:18, Robert Raszuk wrote: > Hi Brian, > > Right, but the language in the PSP sub-section does not talk about > decapsulation. > > > Sure as in a way there is no decapsulation there. This is Segment N-1 node > not Final Segment End node. If there is no decapsulation and

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

On 20-Dec-19 12:01, Robert Raszuk wrote: >>   And where is it forwarded to, since we are already at the DA? > > PSP operates at the n-1 segment end of the SR path so naturally after > swapping DA it is forwarded to the segment end. Note that we are all along > operating on the encapsulated

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

Sorry, I am still confused, see in line: On 20-Dec-19 00:53, Pablo Camarillo (pcamaril) wrote: > Brian, > > Inline. > > Thank you, > Pablo. > > -Original Message- > From: Brian E Carpenter > Date: Saturday, 14 December 2019 at 21:04 > To: "

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

Hi Pablo, See in line: On 14-Dec-19 22:34, Pablo Camarillo (pcamaril) wrote: > Brian, > > Many thanks for having another look to the draft. Please see inline [PC]. > > Thank you, > Pablo. > > -Original Message- > From: spring on behalf of Brian E Carpente

Re: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-06.txt

So, I've tried to look at this with fresh eyes, and thanks for the various updates and clarifications. (I'm still not on the SPRING list so please leave me in CC.) I remain a bit puzzled. First, a quote from the SRH specification (draft-ietf-6man-segment-routing-header-26): > 4.2. Transit Node

Re: [spring] SRH scratch space (was Re: Question about SRv6 Insert function)

Robert, On 11-Dec-19 09:18, Robert Raszuk wrote: > Hi Erik, > > What you are proposing IMHO is not needed.  > > Each SR node (Segment Endpoint) is effectively applying new IPv6 encap so is > already doing an insertion of new SRH That isn't "insertion" in the sense of draft-voyer. It's

Re: [spring] Question about SRv6 Insert function

Bruno, On 11-Dec-19 06:17, bruno.decra...@orange.com wrote: > Fernando, > >> From: Fernando Gont [mailto:ferna...@gont.com.ar] >> Sent: Monday, December 9, 2019 9:54 PM >> >> On 5/9/19 09:46, bruno.decra...@orange.com wrote: >> [] Since there have been plenty of attempts to do EH

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

> I went to look in the Security Considerations section, but, well, the > document doesn't seem to have one?... So why on earth is this document in WGLC? It cannot possibly be sent to the IESG without that section. (And "7. Basic security ..." seems very unlikely to pass muster even if

Re: [spring] PHP - Deep Listening

ew.als...@liquidtelecom.com>; Bob Hinden > <mailto:bob.hin...@gmail.com>; Ole Troan <mailto:otr...@employees.org>; > Sander Steffann <mailto:san...@steffann.nl>; Fernando Gont > <mailto:fg...@si6networks.com>; Brian E Carpenter > <mailto:brian.e.c

Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

On 08-Dec-19 00:47, Robert Raszuk wrote: > Besides the pseudocode says it black and white "S14.1. If (updated SL == 0) As I already pointed out, "updated SL" is undefined in the text and may in fact simply mean "Segments Left" after executing S14. Pseudocode really should be

Re: [spring] Penultimate Segment Popping and RFC8200 (Was Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping))

gt; *From:*spring *On Behalf Of *Suresh Krishnan > *Sent:* 07 December 2019 12:50 > *To:* Fernando Gont ; SPRING WG > *Cc:* Ron Bonica ; int-...@ietf.org; > Andrew Alston ; rtg-ads ; > Bob Hinden ; Ole Troan ; Brian E > Carpenter > *Subject:* [spring] Penultimate Se

Re: [spring] We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Andrew, I am a bit confused (not unusual). Can you get back to basics on my questions below? On 07-Dec-19 11:23, Andrew Alston wrote: > Ole - so - let me understand something. > > The definition of consensus - among other things - say that all outstanding > objections have been addressed

Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

Ron, You wrote: > Isn't this [the Opaque header] also creating an opportunity for IETF WGs to > bypass IANA, creating their own registry, likely run badly? More than that, it's creating an opportunity for operators to bypass IETF standards as well as IANA. Isn't that the essence of this

Re: [spring] draft-ietf-spring-srv6-network-programming: NH=59 action item closure

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 the following new IANA registries: > > > >9. IANA Considerations >

Re: [spring] Beyond SRv6.

Robert, > But what is most important that common hardware reads just entire > header then starts processing. So it really makes much more sense to > encode SR SIDs and related functions and their parameters in the same > EH rather then scatter them around. Sorry to get all philosophical, but it

Re: [spring] Question about SRv6 Insert function

Hi Zhenqiang, On 10-Sep-19 22:14, li zhenqiang wrote: > Hi Bruno, > > Thank you very much for your response and clarification. > I agree with you that as of today RFC8200 rejects EH insertion. Since  > draft-ietf-spring-srv6-network-programming is NOT updating RFC8200, it should > not contain

Re: [spring] SRv6 Network Programming: ENH = 59

On 07-May-19 12:20, Mark Smith wrote: > > > 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

Re: [spring] For the fairness and justice of the IETF culture//Re: [mpls] What to do with draft-ietf-mpls-sfc-00.txt

I absolutely cannot comment on this specific case, but the normal and polite way to handle such a situation is a clear reference to the older draft, and some text such as "A very similar proposal was originally made by XXX in [reference]." That would apply both to an earlier IETF contribution or

Re: [spring] [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

Hi, > but this field is, according to [RFC6294], not used in practice. I don't think it's very useful to cite in 2017 a document published in 2011 based on realities in 2010 or earlier. Actually I think you can actually delete the whole phrase; since the proposal tries to respect RFC6437, it is

Re: [spring] Genart last call review of draft-ietf-spring-resiliency-use-cases-08

Stefano, I won't argue further about the general issues, they are really between you and the ADs. About this: ... >> Minor issue: >> >> >> The text of section 3 doesn't explain what requirements for SPRING it >> generates. Really it just describes what any IGP will do anyway. > >

Re: [spring] working group last call for draft-ietf-spring-segment-routing

Hi, It seems very strange to me that [I-D.previdi-6man-segment-routing-header] is an Informative reference. Surely it is Normative (i.e., required reading for an implementer)? That leads to another comment. As we know, if 6man accepts that I-D, it will certainly be on the basis that the header