At Sat, 7 Mar 2020 12:13:23 +0100,
Robert Raszuk wrote:
> > But, again, I expect not everyone agrees on this idea. You probably
> > won't; then I'll respect that. Sometimes we just have to agree to
> > disagree.
>
> Well perhaps to your surprise I am all for clarity in the specifications.
> So
> But, again, I expect not everyone agrees on this idea. You probably
> won't; then I'll respect that. Sometimes we just have to agree to
> disagree.
Well perhaps to your surprise I am all for clarity in the specifications.
So I have nothing against this spec (or any other spec) to formally
At Fri, 6 Mar 2020 23:37:37 +0100,
Robert Raszuk wrote:
> But in the same time I hear from both SR folks as well as 6man AD that the
> current language of RFC8200 is purposely left to only say that only pure
> transit nodes can not mess with the the IPv6 headers in any way while in
> the same
Dear Jinmei-san,
Thank you for your efforts to explain the spirit of RFC8200. I think we all
agree now that those who worked on IPv6 from the start by ultimate
destination consider either the destination which src host's socket puts in
the packet or (which I admit I never realized before this
At Thu, 5 Mar 2020 04:08:28 +,
"Ketan Talaulikar (ketant)" wrote:
> If we argue this behavior as not violating "extension headers cannot be
> removed from a packet until it has arrived at its ultimate destination"
> because "segment left" is 0 at that point (and therefore
> S2 is the
k
> Subject: Re: [spring] Suggest some text //RE: Request to close the LC and
> move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
>
>
>
> At Wed, 4 Mar 2020 12:17:07 +,
>
> "Pablo Camarillo (pcamaril)" <mailto:pcamaril=40cisco@dma
and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
At Wed, 4 Mar 2020 12:17:07 +,
"Pablo Camarillo (pcamaril)"
mailto:pcamaril=40cisco@dmarc.ietf.org>>
wrote:
> Inline PC1.
Thank you for the clarification. I'm not sure why you included the e
Thanks for writing this.
> On Mar 4, 2020, at 6:45 PM, 神明達哉 wrote:
[...]
> If I were to offer something in order to be hopefully more
> constructive, that would be something like this:
>
> - Add a tag of "Updates RFC8200 (if approved)"
[...]
Text elided not due to irrelevance, but because it’s
At Wed, 4 Mar 2020 12:17:07 +,
"Pablo Camarillo (pcamaril)" wrote:
> Inline PC1.
Thank you for the clarification. I'm not sure why you included the
expanded processing logic instead of just saying correct or incorrect
here:
> PC1:
>
> This is the exact processing at S2 combined End (4.1)
st some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
At Sat, 29 Feb 2020 12:06:17 +0100,
Robert Raszuk wrote:
> Even if RFC8200 section 4 text would say:
>
> "Extension headers cannot be
I read the updated version 11 and the verbiage looks very good and provides
all the necessary clarity in the process.
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-11#section-4.16.1
For 6MAN in terms of RFC 8200 as Brian Carpenter mentioned and noticed in
assistance in
Hi Jingrong, I notified Gyan yesterday that the version he was reviewing was
over a year old.
I expect when Gyan reviews the current version it should clear up any lingering
questions.
Darren
On Mar 3, 2020, at 1:34 AM, Xiejingrong (Jingrong)
mailto:xiejingr...@huawei.com>> wrote:
Hi Gyan,
Hi Gyan,
What revision are you reading ?
I found the 4.21.1 only in its very early revision (-00 and -01).
There is only 4.16 and the PSP is introduced in 4.16.1 in the latest draft is
rev-11 : https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming
And I think the explanation of
Hi Jingrong
I am following what you displayed and it makes sense. In section 4.21.1 for
the PSP flavor what was confusing was it said that the End.X with PSP
flavor can pop the SRH. The way it’s written, to me it reads that any P
router can pop the SRH when the last SID is written to the DA. So
At Sat, 29 Feb 2020 12:06:17 +0100,
Robert Raszuk wrote:
> Even if RFC8200 section 4 text would say:
>
> "Extension headers cannot be added to a packet after it has left its
> source node and extension headers cannot be removed from a packet until it
> has arrived at its ultimate destination".
Hi Gyan,
In my understanding, PSP is used right in a P node, works for both End and
End.X ( I haven’t known End.T very well yet).
Suppose:
CE1[PE1P2P3PE4]CE2
PE1 encapsulation the customer packet with an outer IPv6 header and an SRH, the
packet arriving P2 will be:
(SA=PE1,
Hi Jingrong,
Can you help provide some clarification on the use cases for PSP flavor
with end.X and end.T functions.
Under Ref1 where it mentions end.X and end.T functions to use PSP knob as
well if desired.
How would that work with any P node using the PSP function?
alpern" mailto:j...@joelhalpern.com>>,
神明達哉mailto:jin...@wide.ad.jp>>
*Subject: *Re: [spring] Suggest some text //RE: Request to close the LC
and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Robert,
yes, the path probably will be the same regardless whe
明達哉
*Subject: *Re: [spring] Suggest some text //RE: Request to close the LC
and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Robert,
yes, the path probably will be the same regardless whether PSP was
applied or not. But performance metrics, e.g. packet delay, may be
diff
on behalf of Greg Mirsky
Date: Sunday, March 1, 2020 at 8:32 AM
To: Robert Raszuk
Cc: "6...@ietf.org" <6...@ietf.org>, spring , "Joel M.
Halpern" , 神明達哉
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-sprin
Hi Robert,
yes, the path probably will be the same regardless whether PSP was
applied or not. But performance metrics, e.g. packet delay, may be
different for OAM and "regular" packets.
Regards,
Greg
On Sun, Mar 1, 2020, 14:08 Robert Raszuk wrote:
> Nope.
>
> Node can advertise two SIDs or PSP
While the node is "asserting" that the two are the same, if you use
different SIDs for OAM compared with data traffic then you are not
actually checking the same forwarding path. You are not using the same
FIB entries. Sure, if everything works right they are the same. But
the whole point
Nope.
Node can advertise two SIDs or PSP in a given network may be a well know
function (to limit IGP burden) Example: odd SID includes PSP and even SID
does not.
O*A*M packets can use on the exact same path but the penultimate hop
traversal is directed by even SID and is not subject to PSP.
jingr...@huawei.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Jingrong:
You may have some misun
, Weibin (NSB - CN/Shanghai)
Cc: spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Weibin,
I suppose “it (DCGW) *is* the penultimate endpoint in the SRH encapsulated by
VM
1, 2020 3:41 PM
To: Wang, Weibin (NSB - CN/Shanghai)
mailto:weibin.w...@nokia-sbell.com>>
Cc: spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto:6...@ietf.org>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-
mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>;
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-program
; 6...@ietf.org
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Weibin,
Thanks for sharing your points.
It remind me that, the PSP may not only be useful for X-in-IPv6 case, it may be
useful for host
Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>;
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉
mailto:jin...@wide.ad.jp>>
Subject: RE: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-pro
:47 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: spring@ietf.org<mailto:spring@ietf.org>;
6...@ietf.org<mailto:6...@ietf.org>; 神明達哉
mailto:jin...@wide.ad.jp>>
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-s
Presuming that by "OEM" you mean "OAM", then no, this does not work.
If the OAM is intended to monitor a path that has a last SID whose
flavor is PSP, then something will break. The monitoring will monitor
something else, or it won't monitor the last hop, or...
Given the point that was made
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Yes, this is essentially what my second paragraph said. So we agree as to what
our point of disagreement is :-) and I think we can leave it there until there
is something new to discuss.
—John
On Feb 29, 2020, at 3:55 PM, Robert Raszuk
t;6...@ietf.org" <6...@ietf.org>, 神明達哉
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and move
forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Hi Robert,
s/OEM/OAM/ ;)
True, active OAM should not generate excessive number of test packets and that
Yes, this is essentially what my second paragraph said. So we agree as to what
our point of disagreement is :-) and I think we can leave it there until there
is something new to discuss.
—John
On Feb 29, 2020, at 3:55 PM, Robert Raszuk
mailto:rob...@raszuk.net>> wrote:
John,
So for some
John,
So for some packet's final destination is the one located in the most inner
header of the packet. The one applied by the sender's socket.
For you apparently the final destination is the one encoded in the SRH (or
end of src route) - honestly I have not seen such definition in any IETF
Hi Robert,
s/OEM/OAM/ ;)
True, active OAM should not generate excessive number of test packets and
that might make selective non-use of PSP on these packets acceptable. But
some have made a use case for PSP by describing environment where the
ultimate tunnel endpoint is not capable to process SRH.
Greg,
You are thinking of PSP like MPLS PHP to apply to all packets towards the
guy who advertised implicit-null label.
That is not the case here at all.
You apply PSP when you like on a per segment endpoint basis. OEM as we have
all agreed will not be subject to PSP. Is there a value to keep
Hi Brian,
you've said
Also, answering
your question "what harm does it do?" I think the answer objectively is
"none, unless
you want to use AH".
On the other thread Ron and I have pointed that PSP does have decremental
effect on the ability to perform OAM, particularly performance monitoring,
Thanks, Brian.
On Feb 29, 2020, at 2:25 PM, Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>> wrote:
So I think the text needs to admit the trick it's playing on RFC 8200. Then the
IETF
can choose whether to let that trick pass.
I agree. (I’ve said as much before, as have others.)
—John
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
I see. So you are simply demonstrating that even the tightened language you
quoted is subject to the same difference of interpretation that’s at the root
of the controversy. That’s helpful to know.
Clearly (at least this is clear to me) the intent of that sentence is that a
source-routed
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 is still legal then ultimate destination
for a packet is
Robert,
I think your comment (emphasis added):
we are dealing here with an *encapsulated* packet which has as its ultimate
destination SR node X. That SR node X is to perform or not PSP.
Is wrong. It contradicts everything else that’s been said in the hundreds of
messages that have gone
Dear Jinmei,
Even if RFC8200 section 4 text would say:
"Extension headers cannot be added to a packet after it has left its
source node and extension headers cannot be removed from a packet until it
has arrived at its ultimate destination".
PSP would be still not be violating anything said in
Along those same lines of thought.
If you upgrade all your source SR node ingress PEs to be SRv6 capable you
have in fact upgraded all your final destination egress PE nodes to be SRv6
capable.
Gyan
On Fri, Feb 28, 2020 at 9:37 PM Gyan Mishra wrote:
> Jingrong & Bruno
>
> Here is another
Jingrong & Bruno
Here is another point for consideration related to PSP.
Drawing an analogy here between MPLS and SRv6 as SRv6 would be the Next Gen
replacement of MPLS.
Topology
A - B - C
An LSP is uni directional where the path to FEC destination egress PE can
be in either direction where
Got it.
Thanks for your clarification of your point.
Jingrong
-Original Message-
From: 神明達哉 [mailto:jin...@wide.ad.jp]
Sent: Saturday, February 29, 2020 9:28 AM
To: Xiejingrong (Jingrong)
Cc: Ted Lemon ; Pablo Camarillo (pcamaril)
; Brian E Carpenter ; Bob
Hinden ; Joel M. Halpern ;
Got it.
So the gap may be the 'protocol spec' and the 'code/implementation reality'.
"a non-SRV6 capable router receives SRV6 with segments-left == 0" may have many
reasons not implemented this well If Segments Left is zero, the node must
ignore the Routing header with an unrecognized
At Fri, 28 Feb 2020 07:54:28 +,
"Xiejingrong (Jingrong)" wrote:
> The design of PSP for the benefits of deployment is based on the understanding
> that it does not violate section 4 of RFC8200. In case the RFC8200 text may be
> modified in the future, the PSP may also need to change
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
Brian,
> On Feb 28, 2020, at 2:46 PM, Brian E Carpenter
> wrote:
>
> 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
Hi
Thanks Ted for the constructive suggestions, which remind me to try to
understand the questions. Here are the questions I think give the clear
suggestions for LC.
Brian: So could the draft make this explicit, because I guarantee you it is not
in the least obvious to the non-expert reader?
52 matches
Mail list logo
