Bruno's statement, which you chose to quote, was that all it takes is
for one person to find something useful. I was responding to what the
chair said. It is not true as stated.
Having said that, I agree that more than one person has asked for this.
But the actual requirement is that there b
Hi Joel,
Surely you are exaggerating when you say "one person" asked for something in
the context of PSP? 😊
Would you like to clarify?
And also respond on the real life and practical deployment scenarios and
considerations that I've pointed out below? I doubt you meant to just
dismissing the
If we really want to say that it takes only one person asking for
something to put it in a planned RFC, then I guess we have to publish
all of the competing versions of route headers for v6, since we clealry
have more than 1 party asking for each variant?
Put differently, no, putting something i
Hi Joel,
I would like to echo the arguments that Bruno has made (and quote part of it)
in his summary and then previously on this thread.
QOUTE
The point was related to the usefulness of the optional feature, which has been
challenged.
I was trying to say the required argumentation to dec
In this case, it is even less relevant. The PSP for SRv6 does not
remove the double-processing. It merely removes the need to ignore the
SRH at the ultimate node.
Yours,
Joel
On 3/3/2020 6:27 PM, Andrew G. Malis wrote:
MPLS PHP was invented to solve a particular issue with some forwarding
e
Hi Chris,
You are right in that there is no assumption that all SRv6 locators in a domain
are allocated from the same block. Therefore knowing the blocks used in the
domain is useful.
The IGP drafts covers the advertisement of the B and N parts of the locally
configured locator on the node via
Stewart, et.al.,
First, there has been some ambivalence regarding what the issue with
an AD taking this type of decission.
- there is no doubt that an AD may take this decision, module enough
involvement in the wg and giódd understanding of the issues
- it might be discussed if the right deci
Hi Forks,
We just updated the SRv6 Path Segment draft, welcome to review it. If you have
any comments, please feel free to let us know.
Since the content is mature and stable, authors would like to request for WG
adoption.
Thanks,
Cheng
-Original Message-
From: internet-dra...@ietf.o
On Tue, Mar 3, 2020 at 11:07 AM wrote:
>
> Sander,
>
> > -Original Message-
> > From: Sander Steffann [mailto:san...@steffann.nl]
> > Sent: Monday, March 2, 2020 9:03 PM
> > To: DECRAENE Bruno TGI/OLN
> > Cc: SPRING WG List; draft-ietf-spring-srv6-network-programming; 6man WG
> > Subject:
On Wed, 4 Mar 2020, 09:59 Robert Raszuk, wrote:
>
> You are right Mark ... I fully admit I have no clue what so ever about
> "IPv6 being a virtual MAC layer in SR" nor " IPv6 being used as a virtual
> link layer".
>
I didn't say you had no clue.
Saying things like "MPLS is not link layer." sugg
MPLS PHP was invented to solve a particular issue with some forwarding
engines at the time - they couldn't do a final pop followed by an IP lookup
and forward operation in a single forwarding cycle (it would impact
forwarding speed by 50% best case). 20 years later, is this still an issue
at the ha
You are right Mark ... I fully admit I have no clue what so ever about
"IPv6 being a virtual MAC layer in SR" nor " IPv6 being used as a virtual
link layer".
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, Mar 3, 2
On 3/3/20 12:49, bruno.decra...@orange.com wrote:
Fernando
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont
Sent: Monday, March 2, 2020 9:23 PM
To: Martin Vigoureux; spring@ietf.org
Cc: 6...@ietf.org; 'i...@ietf.org'; draft-ietf-spring-srv6-network-programming
Subject: R
On Wed, 4 Mar 2020, 08:50 Robert Raszuk, wrote:
>
> MPLS is not link layer.
>
I did not say that. I described how MPLS uses link-layers.
It is Layer 2.5 if you really want to squeeze it to OSI.
>
> Regardless of IPv4, IPv6 or MPLS MACs are replaced at each L3 hop
>
IPv6 is your virtual MAC l
MPLS is not link layer. It is Layer 2.5 if you really want to squeeze it to
OSI.
Regardless of IPv4, IPv6 or MPLS MACs are replaced at each L3 hop - but
that has nothing to do with MPLS PHP. MPLS PHP is the result of LDP
signalling implicit null label from adjacent LSR.
And perhaps it may avoid u
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. Afte
Right, let's get the text clarified. Whether or not the IETF (not just these
two WGs, which plainly cannot agree) accepts or refuses this interpretation of
RFC 8200 is a separate question.
Regards
Brian
On 04-Mar-20 09:37, Pablo Camarillo (pcamaril) wrote:
> Brian, Bruno,
>
> Â
>
> Many th
Brian, Bruno,
Many thanks for your comments.
Based on the feedback I would propose to add Brian's proposed text as is into
the draft.
4.16.1. PSP: Penultimate Segment Pop of the SRH
SR Segment Endpoint Nodes advertise the SIDs instantiated on them via
control plane protocols as d
Hi Ron,
> MPLS PHP is a clear case of de-encapsulation.
Purely looking at technical aspect that is not true at all.
MPLS PHP does not remove label stack. MPLS PHP is just used to pop last
label. After MPLS PHP packets continue with remaining label stack to the
egress LSR (example L3VPN PE).
>
Folks,
I don't think that you can compare MPLS PHP with SRv6 PSP. MPLS PHP is a clear
case of de-encapsulation. We do that all the time. In SRv6 PSP, we are removing
something from the middle of a packet. That is quite a different story.
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
Note, I said "is not usually, in and of itself". Recognizing that there
are exceptions. There appears to be significant disagreement as to
whether the MPLS case was a good one. )There are lots of other aspects
for that case which do not apply here.)
Yours,
Joel
On 3/3/2020 12:17 PM, bruno.d
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> Sent: Tuesday, March 3, 2020 5:24 PM
> To: DECRAENE Bruno TGI/OLN; Martin Vigoureux; spring@ietf.org
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
>
> I'm sorry, but "in my gear I want an option to move some work
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 ad
I'm sorry, but "in my gear I want an option to move some work around, so
I need a protocol behavior for that" is not usually, in and of itself,
enough reason to add an optional feature to a protocol.
At one point there was an argument that PSP was needed for compliant
devices that would not be
Sander,
> -Original Message-
> From: Sander Steffann [mailto:san...@steffann.nl]
> Sent: Monday, March 2, 2020 9:03 PM
> To: DECRAENE Bruno TGI/OLN
> Cc: SPRING WG List; draft-ietf-spring-srv6-network-programming; 6man WG
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-pro
Fernando
> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont
> Sent: Monday, March 2, 2020 9:23 PM
> To: Martin Vigoureux; spring@ietf.org
> Cc: 6...@ietf.org; 'i...@ietf.org'; draft-ietf-spring-srv6-network-programming
> Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-
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,
Wh
Pablo,
My reading is that Brian is asking for a clarification of the text, not a
change in the behavior.
In general, I think that clarification is good and that Brian's request is
reasonable.
Related to Brian's comment, but on top of them, I have further points on this
section 4.16.1:
1)
" S
Hi Pablo,
It’s not clear to me whether this version -11 aims at addressing all received
comments, or only the one related to section 4.16.1.
Could you please clarify to avoid misunderstanding? And avoiding unnecessary
waiting or deadlock.
If -11 does not address all received comments (which is
> On 2 Mar 2020, at 21:43, Sander Steffann wrote:
>
> 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/avail
31 matches
Mail list logo
