assist with issue
tracking.
> On Oct 13, 2021, at 6:28 PM, John Scudder
> wrote:
>
>
> 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 do
(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
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
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
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 refere
-idr-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
> addresse
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
ion
as wet tissue 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
On 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 a
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 h
[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, I'
Sorry I missed that -- thanks!
--John
On Nov 11, 2014, at 10:23 AM, Stefano Previdi (sprevidi)
mailto: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...@
Minutes are at https://www.ietf.org/proceedings/93/minutes/minutes-93-spring
Please send any corrections.
--John
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi All,
The document is adopted as a working group item. Authors, please resubmit as
draft-ietf-spring.
Thanks,
--John and Bruno
> On Jul 22, 2015, at 11:13 AM, John G. Scudder wrote:
>
> [re-send with correct address for isis-wg]
>
> Dear WG,
>
> As we discussed at our meeting yesterday,
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
https://www.ietf.org/mailman/listinfo/spr
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, then
(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
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 before
same node is 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 2
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
decasulation and 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..
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
/minutes-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 S
fense.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://ma
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 a
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
[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 locally-
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,
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 (“dis
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
fol
nline comment that 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
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 don’t
Hi Gunter, Joel, all,
I hope you don’t mind if I chime in.
Hopefully, we all agree that it’s within the remit of a WG and its chairs to
decide on their procedures, for the most part. These procedures could include
things like those that are being discussed. As a thought experiment, let’s
suppo
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
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
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 to
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
charter-ietf-spring-02-01: 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.)
The document, along
38 matches
Mail list logo
