Linda, John,
Your discussion is premised on the assumption that the remote endpoint sub-TLV
is optional. Consider this paragraph, from section 5:
When the Tunnel Encapsulation attribute is carried in an UPDATE of
one of the AFI/SAFIs specified in the previous paragraph, each TLV
MUST h
(As a WG member. I don’t speak from any authority, other than “a person who has
read the spec several times and worked with implementors”.)
> On Jun 26, 2019, at 2:46 PM, Linda Dunbar wrote:
>
> John and the Tunnel-Encap authors:
>
> The following text on page 9 of Section 3.1 states that Rem
On Jun 26, 2019, at 2:55 PM, Robert Raszuk
mailto:rob...@raszuk.net>> wrote:
There is nothing in the spec however which would stop basic recursion to work
including recursion via next hop which can be reached via some form of
encapsulation.
Agreed.
—John
_
(Still as an individual contributor of course.)
On Jun 26, 2019, at 4:02 PM, Linda Dunbar
mailto:linda.dun...@futurewei.com>> wrote:
[Linda] Your statement is indeed much clearer. Thank you.
You are welcome.
When a Node-A constructs this Tunnel-Encap UPDATE for routes attached to
Node-A, does
On Jun 26, 2019, at 4:32 PM, Robert Raszuk wrote:
>
> I can think of even more basic example .. when UPDATE crosses EBGP boundary
> between N number of ASes. Next hop field will be rewritten while tunnel
> endpoint will stay. For example for the purpose of providing end to end
> transport any
really want to have this behavior? Having it
optional would give us a lot more flexibility and I thought an attribute was
supposed to be associated with a route. Making the Remote Endpoint sub-TLV
mandatory effectively associates the attribute with the remote endpoint.
Yours Irrespecti
On Jun 28, 2019, at 2:40 AM, Ali Sajassi (sajassi) wrote:
>
> Tunnel-Encap draft also provides an example of such recursiveness in section
> 7.
Oh, right, of course. Thanks for pointing that out.
—John
___
rtgwg mailing list
rtgwg@ietf.org
https://ww
Heh. Thanks for pointing that out, I’ve forwarded it to Juniper’s legal
department to get the typo corrected if that’s possible.
—John
On Mar 5, 2020, at 3:04 PM, Robert Raszuk
mailto:rob...@raszuk.net>> wrote:
The IPR title starts:
REDUNDANT PSEUDOWIRES FOR BORDER GATEWAY PATROL-BASED ...
ks,
Yingzhen
From: John Scudder mailto:j...@juniper.net>>
Date: Tuesday, June 30, 2020 at 11:14 AM
To: "rtg-...@ietf.org<mailto:rtg-...@ietf.org>"
mailto:rtg-...@ietf.org>>
Cc: "rtg-...@ietf.org<mailto:rtg-...@ietf.org>"
mailto:rtg-...@ietf.org>>,
On Jul 7, 2020, at 11:35 AM, John G. Scudder wrote:
Hi Acee,
On Jul 7, 2020, at 11:16 AM, Acee Lindem (acee)
wrote:
Yes. I’d say we should just use the ip-prefix type from RFC 6021. This type has
the right semantics.
However, I’m wondering how we do the mask-length-lower checking with the
needs to be verified against mask-length.
Any comments and suggestions are welcome.
Thanks,
Yingzhen
From: John Scudder
Date: Tuesday, July 7, 2020 at 9:06 AM
To: "John G. Scudder"
Cc: "Acee Lindem (acee)" , Yingzhen Qu
, "rtg-...@ietf.org" ,
"rtg-...@ie
While reviewing a different document that uses a similar “aims at“
construction, it occurred to me that,
On Apr 16, 2024, at 4:14 PM, John Scudder via Datatracker
wrote:
Segment Routing aims at supporting services with tight SLA guarantees
[RFC8402].
… If you had written this slightly
714.
On May 12, 2024, at 11:02 PM, Ahmed Bashandy wrote:
Thanks for the thorough review
I am in the process of uploading version 15 of the document. So whenever I say
"fixed", "changed", "modified",..., etc, I am referring to version 15
See inline comments
Hi Ketan,
On Nov 15, 2024, at 9:48 AM, Ketan Talaulikar wrote:
I believe my text proposals do not dilute the post-convergence aspect of
TI-LFA. Please let me know if you see it otherwise.
No argument. I was harking back to the debate I addressed at (probably too
much) length in my message to
types of protection schemes and failures. This is nothing
new.
Thanks,
Ketan
On Fri, Nov 15, 2024 at 7:51 PM John Scudder
mailto:j...@juniper.net>> wrote:
[trimmed cc; presumably copying the WG is sufficient]
Hi Ketan,
Can you help me understand what you’re driving toward with this comme
[trimmed cc; presumably copying the WG is sufficient]
Hi Ketan,
Can you help me understand what you’re driving toward with this comment?
On Nov 15, 2024, at 5:44 AM, Ketan Talaulikar wrote:
In addition to the above text change suggestions, I would remind that strict
following of post-converge
Hi Ahmed,
Thanks for the update. I read the diff, and I listened to the recording of your
rtgwg presentation.
I've written a long message. For convenience, the bottom line (TL;DR as it
were) is that I think the conversation that was started with Stewart and Sasha
at the mic line at IETF-121 ne
Hi Ketan,
On Nov 15, 2024, at 10:23 AM, Ketan Talaulikar wrote:
Below is an additional text proposal (over and above what I have shared
previously) to cover, what I think, may be the essence of your discuss. It is
possible though that I've still missed your point.
As I mentioned in my earlier
On Sat, Feb 22, 2025 at 8:41 AM John Scudder
mailto:j...@juniper.net>> wrote:
Hi RFC 8678 Authors, RTGWG,
Alexander Patrakov filed
https://www.rfc-editor.org/errata/eid8002<https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8002__;!!NEt6
Hi RFC 8678 Authors, RTGWG,
Alexander Patrakov filed https://www.rfc-editor.org/errata/eid8002 against RFC
8678. I don’t see any reply to the erratum in the archives.
I’m hoping one of you can comment. In looking at the erratum, my first
inclination is to reject it, although there is also a cas
John Scudder has entered the following ballot position for
draft-ietf-rtgwg-policy-model-30: 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-rtgwg-yang-rib-extend-18: 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-rtgwg-vrrp-rfc5798bis-17: 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-rtgwg-segment-routing-ti-lfa-13: 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-rtgwg-net2cloud-problem-statement-41: 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
25 matches
Mail list logo
