Hi David,
Thanks for your review and please check in-line below.
On Sat, 13 Nov 2021 at 00:27, David Schinazi via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: David Schinazi
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review
Hi Mike,
You are right that the SR Policy architecture draft does not talk about
reverse SLs. But it also doesn't talk about bidirectional paths or aspects
like the use of association objects for disjoint paths. At one point in
time, some of us (WG members) were of the view that these aspects may
Hi Benjamin,
Thanks for your review and please check in-line below for responses.
On Tue, 23 Nov 2021 at 23:22, Benjamin Schwartz via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Benjamin Schwartz
> Review result: Ready
>
> This document is ready with a few minor clarifications. It does
>> directories.
>> This draft is a work item of the Source Packet Routing in Networking WG
>> of the IETF.
>>
>> Title : Segment Routing Policy Architecture
>> Authors : Clarence Filsfils
>>
Hi Matthew,
Thanks for your detailed review and please find responses inline below.
Also, we've posted an updated version to address your comments. Request you
to please check and let us know your feedback.
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-16
On Fri
Thanks Matthew
On Wed, Feb 2, 2022 at 5:37 PM Bocci, Matthew (Nokia - GB) <
matthew.bo...@nokia.com> wrote:
> Hi Ketan
>
>
>
> Thanks for your quick response.
>
>
>
> Matthew
>
>
>
> *From: *Ketan Talaulikar
> *Date: *Saturday, 29 January
Hi Erik,
Thanks for your review and please check inline below for responses. We will
include these changes in the next update.
On Fri, Feb 11, 2022 at 10:40 AM Erik Kline via Datatracker <
nore...@ietf.org> wrote:
> Erik Kline has entered the following ballot position for
> draft-ietf-spring-se
Hi Cullen,
Thanks for your review.
We will include the range 0x20-0x7E in the spec and this was also what
Benjamin Kaduk had suggested. We will incorporate this in the next version
of the document.
Thanks,
Ketan
On Mon, Feb 7, 2022 at 3:10 AM Cullen Jennings via Datatracker <
nore...@ietf.org>
Hi Carlos,
Thanks for your review and please check inline below for responses. We will
include these changes as part of the next update.
On Mon, Feb 14, 2022 at 2:53 AM Carlos Bernardos via Datatracker <
nore...@ietf.org> wrote:
> Reviewer: Carlos Bernardos
> Review result: Ready with Nits
>
>
Hi Rob,
Thanks for your review and your comments. Please check inline below for
responses.
We will include these changes in the next update of the document.
On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton via Datatracker <
nore...@ietf.org> wrote:
> Robert Wilton has entered the following ballot
Hi Rob,
Thanks for your quick response and please check further inline below with
KT2.
On Tue, Feb 15, 2022 at 9:05 PM Rob Wilton (rwilton)
wrote:
> Hi Ketan,
>
>
>
> Please see inline …
>
>
>
> *From:* Ketan Talaulikar
> *Sent:* 15 February 2022 14:17
>
eview – I agree with you and have balloted No
> Objection. Authors: thank you for addressing Cullen’s comment in the next
> revision of the draft.
>
>
>
> Francesca
>
>
>
> *From: *art on behalf of Ketan Talaulikar <
> ketant.i...@gmail.com>
> *Date: *Friday
,
>
> Rob
>
>
>
>
>
> *From:* Ketan Talaulikar
> *Sent:* 15 February 2022 15:56
> *To:* Rob Wilton (rwilton)
> *Cc:* The IESG ;
> draft-ietf-spring-segment-routing-pol...@ietf.org; spring-cha...@ietf.org;
> SPRING WG ; james.n.guich...@futurewei.com
> *Subj
Hi John,
Thanks for your review and please check inline below for responses.
On Wed, Feb 16, 2022 at 10:29 PM John Scudder via Datatracker <
nore...@ietf.org> wrote:
> John Scudder has entered the following ballot position for
> draft-ietf-spring-segment-routing-policy-17: Discuss
>
> When resp
Hi Zaheduzzaman,
Thanks for your review and please check inline below for response.
On Thu, Feb 17, 2022 at 12:56 AM Zaheduzzaman Sarker via Datatracker <
nore...@ietf.org> wrote:
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-spring-segment-routing-policy-17:
Hi Alvaro,
Thanks for your review and comments/inputs. Please check inline below for
responses.
On Thu, Feb 17, 2022 at 3:29 AM Alvaro Retana via Datatracker <
nore...@ietf.org> wrote:
> Alvaro Retana has entered the following ballot position for
> draft-ietf-spring-segment-routing-policy-17: D
Hi Roman,
Thanks for your review and comments/inputs. Please check inline below for
responses.
On Thu, Feb 17, 2022 at 3:36 AM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-spring-segment-routing-policy-17: Di
Hi Ben,
Thanks for your detailed review and your comments/inputs. Please check
inline for responses.
On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-spring-segment-routing-poli
Hi Murray,
Thanks for your review and your comments. Please check inline below for
responses.
On Thu, Feb 17, 2022 at 12:06 PM Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-spring-segment-routing-policy-
Hi Eric,
Thanks for your review and your comments. Please check inline below for
responses.
On Thu, Feb 17, 2022 at 8:23 PM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-spring-segment-routing-policy-17: No Object
Hi Ben,
We've just posted an update to address the comments raised by you and other
ADs:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18
Thanks,
Ketan
On Thu, Feb 17, 2022 at 9:21 PM Ketan Talaulikar
wrote:
> Hi Ben,
>
> Thanks for your detai
Hi Roman,
We've just posted an update for the document to address the comments raised
by you and other ADs:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18
Thanks,
Ketan
On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar
wrote:
> Hi Roman,
>
> T
at earlier today.
Thanks,
Ketan
On Thu, Feb 17, 2022 at 8:36 PM Ketan Talaulikar
wrote:
> Hi Alvaro,
>
> Thanks for your review and comments/inputs. Please check inline below for
> responses.
>
>
> On Thu, Feb 17, 2022 at 3:29 AM Alvaro Retana via Datatracker <
> nore..
:
> On February 17, 2022 at 10:06:39 AM, Ketan Talaulikar wrote:
>
>
> Ketan:
>
> Hi!
>
> I am looking at -18. Thanks for adding the Updates tag -- you need to
> also add text to the Introduction about the update.
>
KT>
jamin Kaduk wrote:
> Hi Ketan,
>
> Thanks for the replies here and the updates in the -18.
> I think there are still some open topics, though; more inline.
>
> On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote:
> > Hi Ben,
> >
> > Thanks for your
ain to be addressed in the document.
Thanks,
Ketan
On Thu, Feb 17, 2022 at 1:12 AM John Scudder wrote:
> Hi Ketan,
>
> > On Feb 16, 2022, at 2:03 PM, Ketan Talaulikar
> wrote:
> >
> > Hi John,
> >
> > Thanks for your review and please check inline below fo
5:29:36 AM, Ketan Talaulikar wrote:
>
> Ketan:
>
> Hi!
>
> > We have also just posted an update to address some of the comments below
> and
> > from other ADs.
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19
updates
address your concerns.
Thanks,
Ketan
On Thu, Feb 17, 2022 at 11:53 PM Ketan Talaulikar
wrote:
> Hi Roman,
>
> We've just posted an update for the document to address the comments
> raised by you and other ADs:
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-se
Hi Ben,
Please let us know your feedback on whether the responses and draft updates
address your concerns.
The latest version is
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-20
Thanks,
Ketan
On Sat, Mar 5, 2022 at 4:06 PM Ketan Talaulikar
wrote:
> Hi
Hi John,
Please let us know your feedback on whether the responses and draft updates
address your concerns.
The latest version is
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-20
Thanks,
Ketan
On Mon, Mar 7, 2022 at 11:50 AM Ketan Talaulikar
wrote:
>
, 2022 at 6:33 AM Roman Danyliw wrote:
> Hi Ketan!
>
>
>
> I’m clipping the text a bit to make it readable …
>
>
>
>
>
> On Thu, Feb 17, 2022 at 8:38 PM Ketan Talaulikar
> wrote:
>
> Hi Roman,
>
>
>
> Thanks for your review and comments/inputs. Ple
> Hi Ketan,
>
> My apologies for the slow reply, there are quite a few things for me to
> wrap up before my term as AD ends. As you put it in your graceful note
> off-list, we are very close.
>
> More inline...
>
> On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ke
Hi Roman,
We've just submitted an update to address your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21
Please let us know if it addresses your concerns.
Thanks,
Ketan
On Fri, Mar 18, 2022 at 11:19 AM Ketan Talaulikar
wrote:
> Hi Roman
Hi Alvaro,
The update posted just now has incorporated your suggestion:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21
Thanks,
Ketan
On Thu, Mar 17, 2022 at 10:38 PM Ketan Talaulikar
wrote:
> Hi Alvaro,
>
> Thanks again for your detailed revie
n, Mar 20, 2022 at 08:52:41AM +0530, Ketan Talaulikar wrote:
> > Hi Ben,
> >
> > Thanks for your time and your response. Please check inline below with
> KT3.
> >
> > We've also posted an update with changes to address your comments:
> >
> https://datat
Hi John,
I dug into my emails and you are right that while we had a discussion on
point 4 (i.e. security considerations associated with the use of symbolic
names), it was not concluded. My apologies for the same.
It might be helpful to place a context on why the draft uses symbolic names
in the f
> Thanks as always for your quick reply.
>
> > On Mar 22, 2022, at 4:54 AM, Ketan Talaulikar
> wrote:
> >
> >
> > Hi John,
> >
> > I dug into my emails and you are right that while we had a discussion on
> point 4 (i.e. security considerations associa
Thanks John for your inputs and suggestions.
Thanks,
Ketan
On Tue, 22 Mar, 2022, 11:51 pm John Scudder, wrote:
> Looks good, thanks. I’ve cleared my discuss, thanks for your work on this.
>
> —John
>
> On Mar 22, 2022, at 2:11 PM, Ketan Talaulikar
> wrote:
>
>
>
Hi Yao,
Please check inline below.
On Wed, Mar 30, 2022 at 2:34 PM wrote:
> Hi all,
>
> We presented
> https://datatracker.ietf.org/doc/draft-peng-idr-segment-routing-te-policy-attr
> on IDR's session last week.
> This document defines two kinds of new Segment Sub-TLVs to carry SID
> related al
Hi Yao,
Thanks for your response. I don't see the need for the types L and Q. The
controller might as well use existing types if it is not sure of the
resolution.
Thanks,
Ketan
On Thu, Apr 7, 2022 at 6:57 AM wrote:
> Hi Ketan,
> Thanks for your further comments and explanation. Please see inl
+ 1 to Sasha and Jorge
The feature gaps to be addressed in BGP EVPN VPWS should be based on
operators' feedback so we add only those that are relevant.
Thanks,
Ketan
On Tue, May 31, 2022 at 4:59 PM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:
> Jorge and all,
>
> Here is a (adm
And ... the room is open now.
Thanks,
Ketan
On Wed, Jul 27, 2022 at 7:40 PM Ketan Talaulikar
wrote:
> There is some issue with meetecho it seems.
>
> I hope someone from the room will let us know once they get it sorted out.
>
> Thanks,
> Ketan
>
>
> On Wed, 27 Jul
Hi Joel/All,
Can the policy clarify some of the following points which are not
explicitly covered in its currently proposed text?
a) Whether a single implementation is sufficient or if we require at least
2 *independent* (i.e., by different implementors) ones?
b) There are some MUSTs that are ass
Hi Robert,
Let us consider RFC8402 which has a whole bunch of MUST clauses. An
implementation may choose not to support IGP Anycast Segment. The spec does
not say that any of the Segments are mandatory for SR. However, there are
some MUST clauses to follow should implementation support it.
I hope
report. You implement
> protocol specification not an architecture.
>
> I was more curious how many protocol extension RFCs say from IDR or LSR
> WGs have such "issue".
>
> Thx,
> R.
>
> On Fri, Aug 19, 2022 at 5:43 PM Ketan Talaulikar
> wrote:
>
>&g
Hi Sasha,
Your point is very valid and I assumed that the optical path is IP enabled
but there is no routing protocol running over it. There may be a mix up
between the terms L3 adjacency and IGP adjacency.
RFC8986 Section 4.2 End.X works for L3 adjacency (with or without routing
protocol running
t;
>
>
> Once this happens, End.X would work without any changes IMHO.
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* Dongjie (Jimmy)
> *Sent:* Tuesday, November 8, 2022 10:46 AM
> *To:* Ketan Talaulikar ; Alexander Vainshtein <
> alexander.vain
Hello Authors of draft-ietf-mpls-msd-yang,
Is it possible to refer to the IANA MSD Types registry to be mirrored into
YANG instead of defining in the way it is done currently?
Refer:
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types
We perhaps need some text ther
Hi Ran,
The questions/points raised by Sasha, et all on the thread below also
applies to this draft that you have brought up - i.e. how things work when
this is modeled as a L1 interface and why not L3.
https://mailarchive.ietf.org/arch/msg/spring/IrzGONQP1zXvBHkvmZyaHOEwC68/
Additionally, I am
Hello Authors,
Please find below some comments on the draft. I hope these can be addressed
to fix/improve the document.
Major:
1) Sec 1: The term "SR path" is not defined in either RFC8402 or RFC9256.
It seems this document is trying to introduce this terminology/concept. If
so, it needs to be d
Hi Joel/All,
I share some of the questions and concerns of the chairs and other WG
members.
Perhaps we need to give more time to the authors to add clarifying text to
the draft (what has been said on the list).
I suggest a dedicated section towards the start of the document that *only*
focuses o
same two
> mechanisms have been proposed: see draft-ietf-ippm-ioam-ipv6-options and
> draft-ali-spring-ioam-srv6
>
>
>
> Regards,
>
>
>
> Giuseppe
>
>
>
> *From:* spring *On Behalf Of *Ketan Talaulikar
> *Sent:* Friday, February 17, 2023 12:46 PM
&g
intended placement of
>>> this seems very different.
>>>
>>> In fact one could envision that there is indeed a class of applicability
>>> for various measurements which is sufficient to be done only on SRH parsing
>>> segment endpoints, he
Hi Hari,
Some of my comments posted during WGLC have not yet been addressed.
https://mailarchive.ietf.org/arch/msg/pce/kuI6HWcpOjbgnf331VJRick6NHw/
The authors have incorporated some of the editorial parts, but the major
concerns related to the signaling of SRv6 MSD are yet to be addressed. The
Hi Greg/Authors,
I believe this draft still needs work before it is ready for WGLC.
Specifically, it does not cover the use of S-BFD for the monitoring of SR
Policies and AFAIK this is the more widely used than the mechanism
specified in the draft currently (i.e. than the bootstrap via LSP Ping t
Hello All,
I support the adoption of this document since it provides an excellent
starting point for the WG to address the very important use case for SR
Policy deployment for delivering private line services with bandwidth
guarantee over SR networks. Documenting this solution will help the
implem
Hello All,
Sharing the comments made at the mike in today's session to the list as we
ran out of time:
1) The "path" to be monitored for SR Policy should be the Segment List and
not Candidate path. Perhaps
https://www.rfc-editor.org/rfc/rfc9256.html#section-2.13 will clarify the
model for SR Poli
tly appreciate it if you review the
> updates highlighted in the diff
> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-bfd-08> and
> would kindly share your feedback.
>
> Regards,
> Greg (on behalf of the authors)
>
> On Wed, Jul 26, 2023 at 10:30
gt;
> You can also review it from the Github repository.
> https://github.com/muzixing/SR-MPLS-Path-Segment/commit/343f7efe3f67a0bc2c02a239d575a2cc658c0aa5
>
>
>
>
>
> Thanks,
>
> Cheng
>
>
>
>
>
>
>
>
>
> *From:* Ketan Talaulikar
> *S
Hi Luc,
I've reviewed the SRv6 proposal along with the overall draft proposal and
it looks good to me.
Thanks,
Ketan
On Wed, Sep 6, 2023 at 9:55 PM Luc André Burdet
wrote:
> SPRING WG,
>
>
>
> My co-authors and myself have presented a document in BESS WG which
> describes fast convergence in
Hello Chongfeng/Authors,
I understand that the problem statement that you are looking to address is
to provide a connectivity service for two IPv4 hosts over a service
provider network with IPv6-only underlay that uses SRv6. Is this correct?
If so, this is a solved problem and documented in RFC92
Resending to the list alone since the authors' email provider is rejecting
emails from gmail :-(
On Thu, Nov 9, 2023 at 10:56 AM Ketan Talaulikar
wrote:
> Hello Chongfeng/Authors,
>
> I understand that the problem statement that you are looking to address is
> to provide a con
Hi Joel,
As a contributor, I am not aware of any undisclosed IPR related to this
document.
Thanks,
Ketan
On Thu, Feb 1, 2024 at 10:06 PM Joel Halpern wrote:
> 1) This email initiates an IPR call for the subject document. All
> authors and contributors, please confirm explicitly to the list th
Hi Yingzhen/All,
I have some concerns regarding the adoption of this document.
- Do we need these different solutions?
KT> No. There is one common author for both these drafts who is also from a
vendor. I hope that person is also able to evaluate implementation aspects
and pick one solution.
now
> the proposed process would have to be used (vs existing cases).
>
> On February 25, 2024 at 12:44:18 AM, Yingzhen Qu (yingzhen.i...@gmail.com)
> wrote:
>
> Dear SPRING WG and chairs,
>
> I'd like to bring your attention to this adoption call happening in the
> RT
Hi Alvaro,
I have some concerns about the second paragraph of your email. Compressed
SRv6 SIDs (C-SID) are still SRv6 and therefore everything from existing
SRv6 RFCs apply and those aspects are very much foundational to this C-SID
document as well.
RFC8754 has introduced the omission of SRH (sec
Hi Alvaro,
I find some level of confusion on the discussion threads and it might
perhaps be due to the inconsistent use of terminologies. It would help to
use the correct terminologies from RFC8754 (6man WG RFC) to bring clarity
on what is within the scope and what is beyond the scope of this docu
Hi Robert,
Please check inline below for some clarifications.
On Tue, Apr 9, 2024 at 12:06 AM Robert Raszuk wrote:
> Hi Ketan,
>
>
>> a) SR Source Node: the node originating the packet - it may have an SRH
>> or may skip it (section 4.1)
>> b) Transit Node: node doing IPv6 forwarding
>> c) (Ult
Hi Himanshu,
Thanks for taking the time to explain the specific deployment design that
is required along with the prerequisites for the use of the solution
proposed in draft-karboubi. I think it would benefit the WG if those
considerations and details were updated in the document so that WG is abl
Hi Alvaro,
I am not aware of any IPR related to this draft.
Thanks,
Ketan
On Tue, Jun 18, 2024 at 9:09 PM Alvaro Retana
wrote:
> Dear authors and contributors:
>
>
> Are you aware of any IPR that applies to this draft?
>
> If so, has it been disclosed in compliance with IETF IPR rules (see
>
Hello Bruno/All,
I support the adoption of this important document by the WG. The document
specifies the transport and service interworking between SRv6 and MPLS that
is essential for the deployment of SRv6 in existing MPLS networks. It is
also helpful for migration from MPLS to SRv6 as well as th
Hello All,
Please find below the shepherd review for this document as asked for by the
chairs.
Thanks,
Ketan
Major:
1) Alignment to SR Policy [RFC9256] terms is needed (e.g., what is
monitored is individual SLs instead of "tunnels"). The operations and
interactions between the SR Policy framew
Hello Authors,
The draft refers to
https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/
as the main framework document. However, that document does not reference
SRv6. Please correct if I have misread.
Further, there is a WG adopted draft in IDR (
https://datatracker.
Adding to what Sasha has said, RFC8986 that has specified End.X (refer
https://www.rfc-editor.org/rfc/rfc8986.html#section-4.2) also allows for
the same to be used for the underlying L2 bundle member links as well.
To me, the L3 interface with optical sub-channels under it, seems similar
and makes
01 AM Greg Mirsky wrote:
>
> Hi Ketan,
> thank you for your detailed review and thoughtful comments. Please find my
> notes below tagged GIM>>. Attached, please find the new working version and
> diff that highlights updates.
>
> Regards,
> Greg
>
> On Tue,
.
> Even the allocation from Return Codes registry is from the standards
> action block - perhaps it should be from the other two blocks?
>
> On Thu, Aug 29, 2024 at 5:01 AM Greg Mirsky wrote:
> >
> > Hi Ketan,
> > thank you for your detailed review and thoughtful comme
Hi Rajesh,
I believe the answer is no - please refer to
https://www.ietf.org/archive/id/draft-agrawal-bess-bgp-srv6-mpls-interworking-01.html#section-2.2.2
AFAIK there is no transposition scheme specified for SAFI 4 (BGP LU).
Thanks,
Ketan
On Sat, Nov 23, 2024 at 2:29 PM Rajesh M wrote:
> Hi
>
>| TBD | TBD |End.DPM | |
>
>+-++-+--+
>
>
>
> Thanks
>
> Rajesh
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar
> *Sent:* Monday, November 25, 2024 8
< copying SPRING WG and authors of the SR Policy YANG draft >
Hi Mahesh,
Thanks for your review of the document.
Since your comments are for draft-ietf-spring-sr-policy-yang, I should
relay them to the authors of that document and the SPRING WG. AFAIK that
document is still work-in-progress.
Th
Hi Haibo,
Thanks for your feedback and confirmation. Indeed the “alternate steering
mechanism” is better. Will push this change in the next revision.
Thanks,
Ketan
From: Wanghaibo (Rainsword)
Sent: 28 September 2021 15:31
To: Ketan Talaulikar (ketant) ; b...@ietf.org
Cc: draft-ietf-bess-srv6
Hi Mark,
The draft talks about "destination of the policy" as in the tail-end node of
the SR Policy. It does not talk about the destination IP address in the packet.
You can consider this as a "default policy" on similar lines as a default route.
Please see the section below which will cover on
previously that indicated an issue because someone was
using these zero addresses as destination IP in the packets. That would be an
incorrect analogy since there is no such proposal in this document.
Thanks,
Ketan
From: Mark Smith
Sent: 16 December 2019 12:27
To: Ketan Talaulikar (ketant)
Cc: SPRING
Hi Nat,
The MSD framework enables us to define more/new MSD types. If there is a real
use-case and requirement (as you express) and the necessary MSD type(s) can be
formally defined then perhaps the WG can evaluate it.
Thanks,
Ketan
From: spring On Behalf Of Nat Kao
Sent: 17 December 2019 17:
Support the early allocation.
Thanks,
Ketan
From: spring On Behalf Of bruno.decra...@orange.com
Sent: 19 December 2019 22:24
To: SPRING WG
Subject: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early
Allocation Call
Hi SPRING WG,
This begins a 2 week Early Allocation call f
Hi Spring WG colleagues,
I am really concerned at the attempts made to drag this WGLC out further. Let
me summarize why.
1. The only sticking point that I am aware of (since I’ve been following all
discussions closely) is about the claim being made by some members that PSP
violates RFC8200
Hi Brian,
It is likely that things are not clear if one were to just try to read the text
around just the specific section of the draft which covers PSP. The document
does needs prior understanding of the SR Architecture RFC8402 and SRH draft in
addition to reading of the entire network progr
Hi Ted,
I’ve tried to clarify Brian’s point :
https://mailarchive.ietf.org/arch/msg/spring/rb23KclF_SKqRsnjvm82192vBZ8/
The draft under WGLC review in Spring WG already has pointers to all those
drafts that I’ve mentioned.
Thanks,
Ketan
From: ipv6 On Behalf Of Ted Lemon
Sent: 28 February 202
Hi Mark,
Just to clarify, the SRv6 control plane is not being extended beyond the SRv6
data plane. Let me explain.
The legacy egress PE which does not have SRH processing capabilities is still
instantiating the SRv6 End.DT/DX SID [ref net-pgm draft sec 4.4-8] in its FIB.
That is still SRv6. No
Hi John,
Please check inline below.
From: spring On Behalf Of John Scudder
Sent: 28 February 2020 02:41
To: SPRING WG ; 6man WG
Cc: Ron Bonica ; daniel.vo...@bell.ca
Subject: Re: [spring] I-D Action:
draft-ietf-spring-srv6-network-programming-10.txt
I have an additional observation, or questi
Hi Chris,
I agree with Peter and I would suggest to drop LSR since this is not a protocol
specific thing.
I believe the text in draft-ietf-spring-srv6-network-programming clears says
what locator block and locator node are. What more details do you think are
required?
Thanks,
Ketan
From: Lsr
wait for him to clarify.
Thanks,
Ketan
From: Lsr On Behalf Of bruno.decra...@orange.com
Sent: 28 February 2020 14:34
To: Ketan Talaulikar (ketant) ; Chris Bowers
Cc: l...@ietf.org; SPRING WG List ;
draft-ietf-spring-srv6-network-programming
; Peter Psenak (ppsenak)
Subject: Re: [Lsr
March 2020 23:39
To: Ketan Talaulikar (ketant)
Cc: Ketan Talaulikar (ketant) ;
l...@ietf.org; SPRING WG List ;
draft-ietf-spring-srv6-network-programming
; Peter Psenak (ppsenak)
; Bruno Decraene
Subject: Re: [Lsr] clarification of locator block and locator node in
draft-ietf-spring-srv6-network
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
ust
dismissing them without sharing your views?
Thanks,
Ketan
-Original Message-
From: Joel M. Halpern
Sent: 04 March 2020 13:16
To: Ketan Talaulikar (ketant) ; bruno.decra...@orange.com;
Martin Vigoureux ; spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-pro
s.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-05#section-4.2
-Original Message-----
From: Joel Halpern Direct
Sent: 04 March 2020 13:26
To: Ketan Talaulikar (ketant) ; bruno.decra...@orange.com;
Martin Vigoureux ; spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-
e could just agree to disagree.
Thanks,
Ketan
-Original Message-
From: Joel M. Halpern
Sent: 04 March 2020 14:04
To: Ketan Talaulikar (ketant) ; bruno.decra...@orange.com;
spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Given that we are talking about
Hi Sasha,
There is the signalling from the "tail-end node" in SRv6 as well. Perhaps you
missed
https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-06#section-4.4 ?
Thanks,
Ketan
-Original Message-
From: spring On Behalf Of Alexander Vainshtein
Sent: 04 March 2020 15:09
To:
Hi Sasha,
Please check inline below.
From: Alexander Vainshtein
Sent: 04 March 2020 15:41
To: Ketan Talaulikar (ketant)
Cc: spring@ietf.org; Martin Vigoureux ; Joel M.
Halpern ; Andrew G. Malis
Subject: RE: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Ketan,
Lots of thanks
Hi Robert,
Please check inline below.
From: Robert Raszuk
Sent: 04 March 2020 16:07
To: Ketan Talaulikar (ketant)
Cc: Alexander Vainshtein ; spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
Hi Ketan,
Let's assume following sce
Hi Jinmei,
Please check inline below.
-Original Message-
From: ipv6 On Behalf Of
Sent: 05 March 2020 05:15
To: Pablo Camarillo (pcamaril)
Cc: spring@ietf.org; 6...@ietf.org; Bob Hinden ; Robert
Raszuk
Subject: Re: [spring] Suggest some text //RE: Request to close the LC and m
1 - 100 of 259 matches
Mail list logo
