Hi Cheng,
Sounds good, and the diff looks good, thanks. One further comment:
> On Nov 29, 2023, at 5:46 AM, Cheng Li wrote:
>
> [Cheng] In the beginning, we have some text related to SRv6, but Bruno
> suggested to delete it to keep this draft clean, so we deleted it.
> But don't worry, we do
John Scudder has entered the following ballot position for
draft-ietf-spring-mpls-path-segment-19: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
John Scudder has entered the following ballot position for
draft-ietf-spring-nsh-sr-12: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
John Scudder has entered the following ballot position for
draft-ietf-spring-nsh-sr-12: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https
Tue, Mar 22, 2022 at 11:20 PM John Scudder
mailto:j...@juniper.net>> wrote:
Hi Ketan,
Thanks as always for your quick reply.
> On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar
> mailto:ketant.i...@gmail.com>> wrote:
>
>
> Hi John,
>
> I dug into my emails and
sue paper, and displaying the string in magenta not a whole lot more
than that — but it’s still better to disclose the cocnern than not to.
Regards,
—John
> Thanks,
> Ketan
>
> On Tue, Mar 22, 2022 at 2:54 AM John Scudder wrote:
>> Hi Ketan,
>>
>> You asked "whe
them: we’ve had a discussion, we
don’t completely agree, these things happen. On point 4 however, I don’t think
our discussion has concluded. At least, if you replied to this, I missed it:
> On Feb 16, 2022, at 2:42 PM, John Scudder
> wrote:
>
>> 4. In §2.1 you talk about the s
segment-routing-te-policy :
> https://mailarchive.ietf.org/arch/msg/idr/3F2m4usa-uahnriF6fFh5F9wlQA/
>
> Looking forward to your response on your discuss & comments on this document.
> Please let know of any outstanding discuss or comments that remain to be
> addressed in
Hi Ketan,
> On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar wrote:
>
> Hi John,
>
> Thanks for your review and please check inline below for responses.
Thanks for your reply. For this response I’m confining myself to points 3 and 4.
[snip]
> 3. Related to the above, at least one of the
John Scudder has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-17: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
h
distractions like bringing up CRH.
Regards,
—John
[*] I count fifteen messages not including this one.
[**] Obviously, beyond the fact that I quoted a paragraph from a document you
cited, that included the letters C, R, and H.
>
> Many thx,
> R.
>
>
> On Tue, Oct 26, 2
t still fails the test I proposed in my initial note.
Regards,
—John
>
>
>
> Kind regards,
>
> Robert
>
>
>
>
>
>
> On Tue, Oct 26, 2021 at 7:55 PM John Scudder wrote:
> (For clarity: I’m not wearing any hats other than “WG contributor”.)
>
&g
(For clarity: I’m wearing no hats other than “WG contributor”.)
As noted in
https://mailarchive.ietf.org/arch/msg/spring/5HF4wM5ZDcw5DeL_klXmKf1UP0E/, I’m
opposed to adoption until the issue raised there has been addressed. (Repeating
the point here to aid in issue tracking.)
Regards,
—John
Hi Stefano,
We agree on the overarching point, which is that the statement isn’t clear as
written.
I take your point about reading it in the context of SRv6 Network Programming,
and I would absolutely agree that it’s right to talk about “the Network
Programming paradigm”, but right now I
hat cSIDs should be possible to be
used without SRH if no special functions are needed at each segment endpoint.
On Thu, Oct 14, 2021 at 12:28 AM John Scudder
mailto:j...@juniper.net>> wrote:
Hi Folks,
I’m struggling with the claim repeated throughout the beginning of
draft-filsfil
Hi Folks,
I’m struggling with the claim repeated throughout the beginning of
draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1, §3) that
“this solution does not require any SRH data plane change”.
I’m not aware of a standardized formal definition of “data plane”, it seems to
Peter,
On May 29, 2020, at 10:36 AM, Peter Psenak
mailto:ppse...@cisco.com>> wrote:
well, advertising the local CRH identifier for every node and adjacency
in the network from every other node is clearly a no-go from the IGP
perspective.
(Of course this objection only applies to the final
On May 29, 2020, at 10:28 AM, Peter Psenak
mailto:ppse...@cisco.com>> wrote:
how do nodes in the network learn about the local CRH identifier a node
X allocated for a prefix residing on node Y?
This is also answered in section 4, AFAICT:
The CRH-FIB can be populated:
o By an operator,
[long list of individual email addresses trimmed from cc, mailing lists left]
Peter,
On May 29, 2020, at 5:11 AM, Peter Psenak
mailto:ppsenak=40cisco@dmarc.ietf.org>>
wrote:
if CRH-SIDs are of local significance how is the loose source routing
going to be supported?
By having the
Robert,
On May 26, 2020, at 5:17 PM, Robert Raszuk
mailto:rob...@raszuk.net>> wrote:
- In what context have we spent so many emails discussing "escaping packets to
the Internet" or protecting infrastructure (SID addresses from "entering your
network from Internet" ?
The difference is between
On May 26, 2020, at 3:52 PM, Sander Steffann
mailto:san...@steffann.nl>> wrote:
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.
This is
.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/nX5-1rdXKOw6ks73VYfwvn7iaI8__;!!NEt6yMaO-gk!UQ0I1bS1wq5FzS6jaV7eUMZNPAMYflW9wRKuToT4DkDMzAu4ryIP5RHKQ_PKkw$>
Darren Dukes
https://mailarchive.ietf.org/arch/msg/spring/v8UAgBGQ0yp0VBwGkZ3RwzH1MME<https://urldefense.com/v3/__https://mailarc
tes-105-spring-00__;!!NEt6yMaO-gk!QbAHSQ3t9Po0n90FQqYbHv8VOpFpwcb739Wzojg7KC2emCeE6TroAjlIlCFOvg$>
Video: Under: Ron’s session on IPv6 Support for Segment Routing: SRv6+
(10:44)
Thanks
Regards … Zafar
From: ipv6 mailto:ipv6-boun...@ietf.org>> on behalf of
John Scudde
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
nd new encapsulation of the packet based on the
SRH content. If so there is no violation of anything. /* And in this mode at
least SR nodes could be PLRs for TI-LFA without the need for yet one more
encapsulation */.
Robert.
On Sat, Feb 29, 2020 at 8:23 PM John Scudder
mailto:j...@juniper.net&g
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
ultimate destination for the outer header
in the same time
The same node is penultimate destination for SR path
in the same time
The same node is just regular IPv6 transit from the perspective of the original
non encapsulated packet
Kind regards,
R.
On Sat, Feb 29, 2020 at 6:46 PM J
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
(ketant)
mailto:ketant=40cisco@dmarc.ietf.org>>
wrote:
Hi John,
Please check inline below.
From: spring mailto:spring-boun...@ietf.org>> On
Behalf Of John Scudder
Sent: 28 February 2020 02:41
To: SPRING WG mailto:spring@ietf.org>>; 6man WG
mailto:i...@ietf.org>>
Cc
I have an additional observation, or question, about Dan’s scenario. Almost all
communication is bidirectional. Presumably this means a router that’s the tail
end of an SRv6 path in one direction is the head end in the other. Doesn’t a
head end need to add an SRH? If I’ve gotten that right,
On Feb 26, 2020, at 8:14 PM, Brian E Carpenter
wrote:
>
> I don't know about you, but when I see a message whose only content is "+1" I
> just delete it.
+1
;-)
—John
___
spring mailing list
spring@ietf.org
[re-sending from proper account]
Andy,
Thanks very much for doing this review.
Authors,
Can you please (at minimum) acknowledge that you've received Andy's comments
and (preferably) respond to them, either by updating the draft or by discussing
them on the SPRING list? For what it's worth,
Sorry I missed that -- thanks!
--John
On Nov 11, 2014, at 10:23 AM, Stefano Previdi (sprevidi)
sprev...@cisco.commailto:sprev...@cisco.com wrote:
Hi John,
I already ack'ed Andrew' s comments and will address them asap.
Thanks.
s.
-Original Message-
From: John Scudder [jg
33 matches
Mail list logo
