I will update it to P1' and P2' as suggested. Thank you.
Happy Holidays,
Pablo.
-Original Message-
From: spring on behalf of Alexandre Petrescu
Date: Thursday, 19 December 2019 at 15:09
To: "spring@ietf.org"
Subject: Re: [spring] Question about SRv6 Insert function
Le 1
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 is the benefit again” and now back to
“this is complex for an ASIC”.
As for how easy
Ron, Gyan,
Sections 4.4 to 4.8 of draft-ietf-spring-srv6-network-programming define the
local dataplane processing on the egress PE.
As far as L3VPN signaling is concerned [draft-ietf-bess-srv6-services], the
egress PE signals opaque behavior for the SID, so it is transparent to the
control pl
Mark,
Not the intention at all!
This thread started trying to fix a /64 locator with the following argument:
“While you might save a IPv6 address space with more specific locators, the
savings might not be worth the administrative headache.”
I don’t think that operators agree to the “administ
Inline.
Thanks.
-Original Message-
From: Brian E Carpenter
Date: Thursday, 19 December 2019 at 22:39
To: "Pablo Camarillo (pcamaril)" , "spring@ietf.org"
Subject: Re: [spring] I-D Action:
draft-ietf-spring-srv6-network-programming-06.txt
Sorry, I am still confused, see in line:
Ron,
I guess that draft-ietf-6man-segment-routing-header does not contain any
explicit text about it because it is not needed.
Instead draft-ietf-6man-segment-routing-header contains a reference to RFC4443
that details in section 2.2 how to select it.
There is no text in draft-ietf-spring-srv6-
Alex,
I will update the line 04 as suggested to clarify that it refers to the outer
IPv6 header. Thank you.
More inline.
Happy Holidays,
Pablo.
-Original Message-
From: Alexandre Petrescu
Date: Thursday, 19 December 2019 at 14:33
To: "Pablo Camarillo (pcamaril)" , "spring@ietf.org"
Hi SPRING,
A number of authors have asked for their document to be adopted or last called.
Chairs have some backlog on this. The WG has also been pretty busy over the
last 6 months with a set of subjects triggering many emails and this is not
always the best time to ask for review of additional
Really ?
If in an implementation SID would be just a logical interface on a box
doesn't it deserve to be both routable as well as have an arbitrary opaque
ID assigned to it ?
On Fri, Dec 20, 2019 at 5:18 PM Andrew Alston <
andrew.als...@liquidtelecom.com> wrote:
> In my view – there is a fundame
In my view – there is a fundamental difference.
The stated rfc refers to a derived interface identifier – with an interface
identifier being a well defined concept in RFC4291 – it specifies the actions
taken on said interface identifier – it does not alter the specification.
Here – you have gon
> Therefore – this redefines the address semantics – and that – should be
> accompanied by an update to said drafts to avoid confusion and to avoid
> potential future complications
>
Please observe that we have a lot of IETF documents putting various stuff
into IPv6 128 bits. Take rfc7599 as an ea
Which makes that an address in my book.
Let me put this another way – if a house is 194 drive – that is an
identifier. The moment you send mail to it – that is an address.
Therefore – this redefines the address semantics – and that – should be
accompanied by an update to said drafts to av
Hi Greg, Joel,
We can add clarification text.
Happy Holidays!
Thanks
Regards … Zafar
From: Greg Mirsky
Date: Thursday, December 19, 2019 at 12:44 PM
To: "Zafar Ali (zali)"
Cc: Robert Raszuk , SPRING WG , 6man WG
Subject: Re: [spring] 6man w.g. last call for
- END.OTP
Hi Zafar,
thank you
> So we are left with a chicken and egg situation – is the SID an address
or isn’t it.
I do not see here neither chicken nor an egg here. SID definition for SRv6
is very clear. It is .
Done.
Obviously LOCator part is routable.
Thx,
R.
On Fri, Dec 20, 2019 at 4:33 PM Andrew Alston <
andrew.als
Hi Ron,
Thanks for your review.
Unfortunately, you seem to have not get the latest version from the Github
(which was later posted as v03).
Good news is that your comments were addressed in the latest version.
Please see specifics in-line.
Happy Holidays!
Thanks
Regards … Zafar
From: spring
+1
I have long argued that SRv6 essentially redefines and overloads the ipv6
address as defined – the argument that I have been given is that the SID is in
fact not an address – however – by virtue of the fact that the SID in SRv6 is
copied into the address field during traffic steering – and r
Alexandre,
You are missing a huge two advantages of actually using part of SID to be a
routable prefix. You do not need a mapping plane + nodes not SR aware just
forward vanilla IPv6 packets. With basic IGP or BGP IPv6 reachability you
can easily construct you segment paths.
And to your point of
Le 20/12/2019 à 00:07, Robert Raszuk a écrit :
Fixed length of any field LOC:FUNC:ARGs makes no sense to me. What is
optimal for Ron or Mark may not be optimal for me.
I think I can legitimately wonder whether the 'SID' Segment Identfier
should not be something else than an IP address.
M
Hi Authors:
I have a bit confusion on understanding the meaning of "B2" in packet P1 and P2
in following section 5.1 in the latest draft;
I notice that "H.Encaps" cover two application scenario which you have
mentioned in text, one is for CE-ingress PE for L3VPN using SR-policy, the
other is TI
Hello Andrew.
Perhaps brevity can help here. I’m only replying to the last sentence of your
email.
Were you to have initiated this thread with “This implementation allocated
multiple END.X SIDs, is that in opposition to section... of draft...? I
interpret section ... to mean ”
My reply c
On 19/12/19 20:44, Brian E Carpenter wrote:
> 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 ar
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.
Of course the other way to look at this would be to conceptually describe
this as decapsulation at
22 matches
Mail list logo
