I support publication and I believe this SR Algo feature will be highly
beneficial for operators.
Thanks
Gyan
On Mon, Feb 19, 2024 at 11:26 PM Acee Lindem wrote:
>
> This starts the Working Group Last call for
> draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm
>
address or
Anycast SID. This should be made clear.
Kind Regards
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Tue, Mar 19, 2024 at 2:43 PM Acee Lindem wrote:
>
> This starts the Working Gr
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Thu, Mar 21, 2024 at 9:32 PM Dongjie (Jimmy) wrote:
> Hi Peter,
>
>
>
> Please see inline:
>
>
>
> *From:* Peter Psenak
> *
+1
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Sat, Mar 9, 2024 at 4:37 PM Acee Lindem wrote:
> All,
>
> With respect to the naming of the OSPF constants, I thi
Regards
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Fri, Mar 1, 2024 at 2:39 PM Tony Przygienda wrote:
> appreciate the ordering, some people start to get wild ideas especially
> now
>
> Yingzhen
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
I support adoption.
Thanks
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Fri, Feb 23, 2024 at 12:28 AM Yingzhen Qu
wrote:
> Hi,
>
> This email begins a 2 week WG adoption poll fo
NRP
and not the routing control plane itself.
Kind Regards
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Wed, Jan 10, 2024 at 7:21 PM Les Ginsberg (ginsberg) wrote:
> (NOTE: I am replying to Joel’
rk slicing to SR-MPLS or SRv6 forwarding plane using
IETF technologies, encoding NRP-ID using ISIS MT per MTID instance NRP
Network slice to be instantiated.
Thanks
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-
I support WG adoption.
Gyan
On Fri, Jan 5, 2024 at 7:23 PM Yingzhen Qu wrote:
> Hi,
>
> This begins a 2 week WG Adoption Call for the following draft:
> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
>
> Please indicate your support or objections by January 19th, 2024.
Les
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Thu, Dec 7, 2023 at 1:07 PM Les Ginsberg (ginsberg) wrote:
> Huaimo –
>
>
>
> There are some things on which people can legiti
Hi Les
Question in-line about the configuration controls being a recommended
solution or must as Bruno pointed out.
Responses in-line Gyan>
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Tue, Nov
Hi Acee
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Tue, Nov 21, 2023 at 1:19 PM Acee Lindem wrote:
> Speaking as WG member:
>
> I agree with Tony, the WG intent should be to make the
Hi Tony
Some comments in-line
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
On Tue, Nov 21, 2023 at 11:46 AM Tony Li wrote:
>
> Hi Bruno,
>
> Thank you for your comments.
>
>
>
Dear WG
I agree with Bruno about the concerns with brownfield multi vendor
forwarding loops regarding deployment of MP TLV extension.
+1 one comments by Bruno
Comments in-line
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
Thanks Acee
On Mon, Oct 9, 2023 at 9:34 AM Acee Lindem wrote:
> Hi Gyan,
>
> > On Oct 9, 2023, at 02:07, Gyan Mishra wrote:
> >
> >
> > Dear authors
> >
> > I reviewed this draft presented at IETF 117 and would like to provide
> some feedbac
Dear authors
I reviewed this draft presented at IETF 117 and would like to provide some
feedback.
I agree with the problem statement that the restart router all its LSAs
still exist on all routers in the area until they maxage naturally. Am
wondering if this is really a problem that needs to be
I support adoption.
Thanks
Gyan
On Wed, Aug 23, 2023 at 3:58 PM Acee Lindem wrote:
> LSR Working Group,
>
> This begins the working group adoption call for “IGP Unreachable Prefix
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection
, your knowledge of any IPR related to this
> work.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Soluti
st and make
> the others contributors (which still requires an IPR response).
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gy
LS Inspection MSD
>> Date: 2023-08-27
>> Group:Individual Submission
>> Pages:7
>> URL:
>> https://www.ietf.org/archive/id/draft-liu-lsr-mpls-inspection-msd-01.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-liu-lsr-mpls-inspection
-inspection-msd
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-liu-lsr-mpls-inspection-msd-01
>
> Abstract:
>
>This document defines a new type of MSD, Base MPLS Inspection MSD to
>reflect the Readable Label Depth(RLD), and the mechanism to signal
>this MSD
ber
> 7th, 2023.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Emai
27, 2023 at 9:31 AM wrote:
> Hi Gyan,
>
>
>
> Please see inline.
>
>
>
>
>
> *From:* Gyan Mishra
> *Sent:* Thursday, July 27, 2023 6:38 AM
> *To:* DECRAENE Bruno INNOV/NET
> *Cc:* Peter Psenak ; lsr
> *Subject:* Re: [Lsr] draft-ppsenak-lsr-igp-ureach
.
>
> The issue arise when you are not doing end to end encapsulation as
> current UPA draft does not preclude using UPA for such networks where
> routing decision is made at each transit node of the domain or at each
> segment endpoint.
>
> Rgs,
> Robert
>
>
> On
o account for the IETF being next
> week.
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*E
ete altere,
> deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> > > they should not be distributed, used or copied without authorisation.
> > > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > > Thank you.
> > >
> >
>
> Orange Restricted
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
readers/implementors have the same "intuition" isn’t sufficient.
>
> Les
>
> > [/lc]
>
> >
>
> > 4)Section 4.3
>
> >
>
> > "R" and "N" flags are now defin
Reviewer: Gyan Mishra
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more
ll that has been
> at a previous IETF.
>
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solut
dicate to the list, your knowledge of any IPR related to this
> work.
>
> Thanks,
> Chris.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mis
ke
> the others contributors (which still requires an IPR response).
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gy
our knowledge of any IPR related to this
> work.
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solut
ational or
> Experimental track.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.c
t level of granularity. A system that is going to
> support MP-TLVs should take care to operate correctly for ALL TLVs before
> advertising that it supports them.
>
> Tony
>
>
>
> _______
> Lsr mailing list
> Lsr@ietf.org
> https:
>
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>
>
>
>
>
> Thanks,
>
> Acee & Chris
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/l
ware of
> any IPR that applies to these drafts.
>
> Thanks,
> Chris.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions
www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > <https://www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://%0b>> www.ietf.org/id/
> > draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>>>
> > > > > > >
> > > > > > > > to some section which
> > specifies based
> > > on exactly
> > > > > what network
> > > > > > > flooding
> > > > > > > > changes UPA will be
> > generated by ABRs ?
> > > > > > >
> > > > > > > Section 4:
> > > > > > >
> > > > > > > "The intent of UPA is to
> > provide an
> > > event driven
> > > > > signal of the
> > > > > > >transition of a destination
> > from
> > > reachable to
> > > > > unreachable."
> > > > > > > >
> > > > > > > > I think such text is not an
> > > implementation
> > > > detail,
> > > > > but it is
> > > > > > > critical
> > > > > > > > for mix vendor
> > interoperability.
> > > > > > > >
> > > > > > > > Can UPA also be generated by
> > P node(s) ?
> > > > > > >
> > > > > > > only if they are ABRs or ASBRs.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Specifically I was looking
> > to find some
> > > > information on
> > > > > > how do you
> > > > > > > > achieve assurance that UPA
> > really
> > > needs to
> > > > be generated
> > > > > > when using
> > > > > > > > various vendor's nodes with
> > very
> > > different
> > > > flooding
> > > > > behaviours
> > > > > > > and when
> > > > > > > > subjects PEs may have a
> > number of
> > > different
> > > > links
> > > > > each with
> > > > > > > different
> > > > > > > > node/link down detection
> > timer ?
> > > > > > >
> > > > > > > sorry, I don't understand the
> > above.
> > > > > > >
> > > > > > > thanks,
> > > > > > > Peter
> > > > > > >
> > > > > > > >
> > > > > > > > Many thx,
> > > > > > > > R.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Hi Acee
Responses in-line
On Mon, Jul 11, 2022 at 10:44 AM Acee Lindem (acee) wrote:
> Hi Gyan,
>
>
>
> *From: *GROW on behalf of Gyan Mishra <
> hayabusa...@gmail.com>
> *Date: *Monday, July 11, 2022 at 1:41 AM
> *To: *Yingzhen Qu
> *Cc: *IDR List , &q
ovides mechanisms to advertise
> non-routing information, and remote neighbor is supported.
>
> Reviews and comments are welcome.
>
>
> Thanks,
> Yingzhen
>
>
> On Jul 9, 2022, at 5:33 PM, Gyan Mishra wrote:
>
>
> During the interim meeting we should keep it
gt; PS, I do believe this work belongs in LSR WG pretty squerly.
>
>
>
> Let’s see how many stakeholders actually want to this protocol - then we
> can talk about a WG home. By stakeholders, I mean operators and vendors
> who are committed to implementing and deploying it - not simply those who
> you are able to enlist as co-authors. Note that our IETF 114 LSR agenda is
> full (with multiple agenda items not making the cut).
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
> ___
> Idr mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> ___
> GROW mailing list
> g...@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
n installed base of BGP and folks
> are not open to experimenting with anything else.
>
> So, can we PLEASE stop beating a dead horse?
>
> Tony
>
>
> On Jun 14, 2022, at 1:43 PM, Gyan Mishra wrote:
>
> All
>
> I agree this is important work for operators in DC net
summary prefixes? this worked very well during
> last two decennia. Are we not over-engineering with PUAs?
>
> G/
>
> --
> External Email: Please use caution when opening links and attachments
> / Cou
ation track
> > > > > is explicitly considered to be OK.
> > > > >
> > > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/sta
> > > > > tements/designating-rfcs-__;!!NEt6yMaO-gk!GYT66d5pSskUh-
> > > > l3RWY9vSXdEA8b
> > > > >
> > > >
> > > Ue7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0DvppQpFMmp2bSw
> > > HRw
> > > > YyGo$
> > > > > historic-2014-07-20/ sez
> > > > >
> > > > > "An RFC may be published directly as Historic, with no earlier
> > > > > status to change (see, for example, RFC 4870). This is usually
> > > > > done to document ideas that were considered and discarded, or
> > > > > protocols that were already historic when it was decided to
> > > > > document them. Those publications are handled as are any other
> RFCs.”
> > > > >
> > > > > $0.02,
> > > > >
> > > > > —John
> > > > ___
> > > > Lsr mailing list
> > > > Lsr@ietf.org
> > > >
> > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
> > > !NEt
> > > > 6yMaO-gk!GYT66d5pSskUh-
> > > >
> > > l3RWY9vSXdEA8bUe7d8_9gGpIfpVLwvuDJs5gcVY6ekmyERneakOWjjjCfV0Dv
> > > ppQ
> > > > pFMmp2bSwFi578Bc$
> > > ___
> > > Lsr mailing list
> > > Lsr@ietf.org
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_
> > > _;!!NEt6yMaO-
> > gk!FgD3U4E76lPBUWCjE2THKu9v6Ky9kpkbKKM5bm__xq22wLi0NUYiVw
> > > lsok2zdPLSLPRhfqAx2bDuepvCjy_F-M4kM4FMo7I$
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
ou are aware of
> any IPR that applies to these drafts.
> >
> > Thanks,
> > Chris.
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> _________
22.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
> _______
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitec
cker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-07.
> IMO both mechanisms have their targeted scenarios.
>
> Gyan> Understood. Perfect.
>
Kind Regards
Gyan
> Best regards,
>
> Jie
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> *Sent:* T
a plane. If
> needed we could have further discussion about whether and how IP Flex-Algo
> can be used for VTN or NRP.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> *Sent:* Wednesday, May 18, 2022 12:51 PM
> *To:
hat node to represent the [FAD, NRP] tuple.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Lsr *On Behalf Of * Gyan Mishra
> *Sent:* Wednesday, May 18, 2022 12:51 AM
> *To:* Dongjie (Jimmy)
>
t; > 3.
> >
> >In order to correlate the virtual or physical layer-2 member links
> >with the Flex-Algo ID which is used to identify the VTN, each VTN
> >SHOULD be assigned with a unique Admin Group (AG) or Extended Admin
> >Group (EAG), and the virtual o
ithm Prefix Metric Sub-TLV” are defined for advertisement of
> algorithm
>
> > specific metric for inter-area inter-AS prefixes for SR-MPLS data-plane.
>
> > >>>>>>
>
> > >>>>>> SR MPLS and IP are independent data-planes used fo
functionality in IS-IS would be RFC 8202.*
>
> * I agree w Ketan that there is no reason to discuss multi-instance
> here as (unlike MT) instance specific hellos are used.*
>
>
>
> * HTH.*
>
>
>
> * Les*
>
>
>
>
>
> --
<http://ww
Hi Ketan
Please see in-line, thanks
On Wed, Apr 20, 2022 at 6:59 AM Ketan Talaulikar
wrote:
> Hi Gyan,
>
> Please check inline below.
>
>
> On Wed, Apr 20, 2022 at 8:21 AM Gyan Mishra wrote:
>
>>
>> I support publication of this draft.
>>
>> The re
https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
; existing OSPF two-part metric mechanism RFC8042 for LANs.
>
> Thanks,
> Ketan
>
>
> On Mon, Apr 18, 2022 at 6:54 AM Gyan Mishra wrote:
>
>>
>> Hi Ketan
>>
>> I was mentioning the use case of LDP-IGP used in RFC 8500 for LAN use
>> case where with L
RFC8042.
>
> So I am not sure that I follow what is it that you are proposing to be
> added to the OSPF reverse metric draft that is related to IGP-LDP sync. Can
> you please explain or better still, propose text?
>
> Thanks,
> Ketan
>
>
> On Sun, Apr 17, 2022 at 5:09
Hi Ketan
Welcome.
Responses in-line
Kind Regards
Gyan
On Thu, Apr 14, 2022 at 3:04 AM Ketan Talaulikar
wrote:
> Hi Gyan,
>
> Thanks for your review and feedback. Please check inline below.
>
>
> On Thu, Apr 14, 2022 at 11:47 AM Gyan Mishra
> wrote:
>
>> Hi Ke
tion being applied to a data
> plane is no doubt confusing.
>
I am good with “logical data plane”. Data plane instance, identifier,
slice or transport would work as well.
>
>
> Thanks,
> Acee
>
>
>
> *From: *Gyan Mishra
> *Date: *Saturday, April 16, 2022 at 1
ng here?
>
Nope. All set. We just need the IP Flex Algo authors to concur with
the Option 2 verbiage I proposed.
> This question is for Ketan as well…
>
> Thanks,
>
> Acee
>
>
>
>
>
> *From: *Lsr on behalf of Gyan Mishra <
> hayabusa...@gmail
ore 12 AM UTC on April 22nd, 2022.
>
>
>
> Thanks,
> Acee
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mis
"application" in this context.
>
> Thanks,
> Ketan
>
>
> On Sat, Apr 16, 2022 at 12:50 PM Gyan Mishra
> wrote:
>
>>
>> Hi Ketan
>>
>> My understanding was that IGP Flex Algo could only be used with SR-MPLS
>> or SRv6 data plane using prefix SID or
Algorithm to be
> > deployed in any IP network, even in the absence of SR.
> >
> >
> > NEW
> >
> > An IGP Flexible Algorithm (Flex-Algorithm) allows IGP to compute
> > constraint-based paths. The base IGP Flex-Algorithm document
> > specified use with
Hi Acee
Fixing a typo
On Fri, Apr 15, 2022 at 10:34 PM Gyan Mishra wrote:
>
> Hi Acee
>
> My question cane up from the list of questions posed by Ketan and Peter’s
> response to question #3.
>
> See excerpt below.
>
> I am confused by what Ketan stated in his ques
>
> What is your point here? Is this a trick question?
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Gyan Mishra
> *Date: *Friday, April 15, 2022 at 5:31 PM
> *To: *"Peter Psenak (ppsenak)"
> *Cc: *Acee Lindem , Ketan Talaulikar <
> ketant.i...@gmail.co
> > same time and and as such share the FAD for it. For example SR-MPLS
> > and IP can both use such common Flex-Algorithm. Traffic for SR-MPLS
> > will be forwarded based on Flex-algorithm specific SR SIDs. Traffic
> > for IP Flex-Algorithm will be forwarded based on Flex-Algorithm
>
larify ASLA for me and based on what your
> examples and analysis of Any bit draft, I don’t see any benefits to the
> draft and do agree it does add more complexity.
>
> Let me try to correct your statements – please see inline.
>
>
>
> *From:* Gyan Mishra
> *Sent:* W
t Call for
>> draft-ietf-lsr-ospf-reverse-metric - "OSPF Reverse Metric"
>>
>>
>>
>> This begins a Working Group Last Call for
>> draft-ietf-lsr-ospf-reverse-metric. While there hasn’t been as much
>> discussion as I would like on the draft, it is filling a gap in OSPF
>> corresponding to IS-IS Reve
more efficient.
> >
> > I think if we were defining a new encoding, having this
> > functionality makes sense, but we aren't defining a new encoding.
> > The proposal is to change an existing published encoding, and the
> > bar has to be higher for that I think.
> >
> > Thanks,
> > Chris.
> > [as wg member]
> >
> >
> > >
> > > Thx.
> > > R.
> > >
> >
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
would be up to the AD to approve, communicate with the IESG,
> etc.
> >
> >
> > [BTW, I am not the AD for this WG, nor am I acting as an AD when
> discussing this document, and I will recuse myself from IESG discussions
> about it.]
> >
> >
> > Alva
in, I see sometimes
> mythical oddness in use-case requests and I can not predict what requests
> future will bring. I am not asking for bigger or multiple SRLG subTLVs, but
> hope to find guidance to have implementation X behave identical/similar as
> implementation Y when such conditi
support the "merge" at FAD sub-TLV
> level.
>
>
>
> I’ll agree that that’s lower priority. I think we should, as a matter of
> completeness.
>
> Tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://w
o be injecting or
> relaying discovery information related to IGP or BGP (for example RRs).
>
>
>
> Have you considered widening the scope a bit to accomplish this extra
> delta ?
>
>
>
> Thx
>
> Robert
>
>
>
>
>
> On Mon, Mar 7, 2022 at 1:17 PM Alvaro Retana
> wrote:
966) carefully maintained
> this route type preference when defining preference for route types
> advertised using TLVs 128 and 130.
>
>
>
> RFC 7775 owes a great deal to RFC 5302. We simply updated the rules based
> on the different set of route types available when using TLVs 135
3. L2->L1 inter-area routes; L2->L1 external routes; L1->L1 inter-
>area routes
>
>
>
>
> RFC5308 however says:
>
>
>
>If multiple paths have the same best preference, then selection
>occurs based on metric.
>
>
>
>
>
> It is not clear whether metric is to be used for selection among L1
> intra-area and external routes or is to be used for selection only with a
> given route type. Can someone please clarify?
>
>
>
> Regards,
>
> Muthu
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
be used as
> a way to bring up BFD session between peers.
>
> Rgs,
> R.
>
>
> On Sun, Feb 13, 2022 at 9:05 PM Gyan Mishra wrote:
>
>>
>> Hi Robert
>>
>> Would this BFD strict mode apply to unsolicited BFD of which you are
>> author?
>>
>&g
-04
>
>
>
> LSR WG,
>
>
>
> This begins a two week last call for the subject draft. Please indicate
> your support or objection on this list prior to 12:00 AM UTC on February 11
> th, 20222. Also, review comments are certainly welcome.
>
> Thanks,
> Acee
>
ain in the Up state until either
> >connectivity fails or the session is taken down administratively.
> >
> >
> > Rgs,
> > Robert.
> >
> >
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.or
established, and implies that connectivity between the systems is
>
>working. The session will remain in the Up state until either
>
>connectivity fails or the session is taken down administratively.
>
>
>
> Rgs,
>
> Robert.
> __
FD session transitions
> to UP state is neither a good thing nor should be stated so by the subject
> draft to bring up OSPF adj. without risk of it to shortly go down.
>
> Thx,
> R
>
>
>
> On Sun, Feb 6, 2022 at 6:24 PM Gyan Mishra wrote:
>
>> Hi Rober
.
Gyan
On Sun, Feb 6, 2022 at 12:24 PM Gyan Mishra wrote:
> Hi Robert
>
> On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk wrote:
>
>> Gyan,
>>
>> > Overall I believe the goal of the strict mode BFD “wait for BFD” is
>> accomplished
>> > and solve all p
still sent. Most operators don’t use
echo mode for that reason.
If you want to "fix" BFD go for it, but for now the delay associated with
> any client action should be based on how BFD works per definition in
> RFC5880 and therefore should be specified on the client side.
>
> Rgs,
A quick question:
>>
>> Should it describe the applicability of the mechanism over OSPF virtual
>> links and unnumbered interfaces? With virtual links, one would have to
>> establish a multi-hop BFD session, so it is slightly different from a BFD
>> operational standpoint. For e.g, capability to support single-hop BFD may
>> not translate to the capability to support multi-hop BFD..
>>
>>
>>
>> Regards,
>>
>> Muthu
>>
>>
>>
>> On Thu, Jan 27, 2022 at 10:38 PM Acee Lindem (acee) > 40cisco@dmarc.ietf.org> wrote:
>>
>> LSR WG,
>>
>>
>>
>> This begins a two week last call for the subject draft. Please indicate
>> your support or objection on this list prior to 12:00 AM UTC on February 11
>> th, 20222. Also, review comments are certainly welcome.
>>
>> Thanks,
>> Acee
>>
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Hi Kethan
Thank you for answering all my questions. I am all set.
Responses in-line
Kind Regards
Gyan
On Sun, Jan 30, 2022 at 11:48 PM Ketan Talaulikar
wrote:
> Hi Gyan,
>
> Please check inline with KT2.
>
>
> On Mon, Jan 31, 2022 at 1:20 AM Gyan Mishra wrote:
>
>
mode.
Kind Regards
On Sun, Jan 30, 2022 at 2:50 PM Gyan Mishra wrote:
> Hi Ketan
>
> Welcome. Responses in-line
>
> Kind Regards
>
> On Sun, Jan 30, 2022 at 12:34 PM Ketan Talaulikar
> wrote:
>
>> Hi Gyan,
>>
>> Thanks for your review and your co
Hi Ketan
Welcome. Responses in-line
Kind Regards
On Sun, Jan 30, 2022 at 12:34 PM Ketan Talaulikar
wrote:
> Hi Gyan,
>
> Thanks for your review and your comments/feedback. Please check inline
> below for responses.
>
>
> On Sun, Jan 30, 2022 at 12:29 PM Gyan Mishr
of suggesting any new text I would suggest to delete
>>> the two below sentences and it will be fine:
>>>
>>>
>>>
>>> *"In certain other scenarios, a degraded or poor quality link will allow
>>> OSPF adjacency formation to succeed*
>&
Sorry I meant publication.
I support publication.
Thanks
Gyan
On Sun, Jan 30, 2022 at 1:59 AM Gyan Mishra wrote:
>
> I support WG Adoption of this draft.
>
> This is a real world problem that has existed with BFD that operators have
> to deal with where OSPF adjacency come
not use the path
> without a working BFD adjacency.
>
>
>
> Without this standard, as per most current default OSPF BFD deployment,
> OSPF adjacency is established without BFD. OSPF adjacency then triggers the
> BFD session to be established. If a "break-in-middle" issue occurred (where
> last mile interface status remain
that need it by
terminating TCP sessions only on those PE devices.
The big question is does the WG want this solved with a solution that is
contained within the IGP or is having solution outside of the IGP ok such
the PUB/SUB model.
Thanks
Gyan
On Thu, Jan 27, 2022 at 12:32 AM Gyan Mishra wrote
addresses some concerns associated with any to any
>> registrations. No longer PEs need to register anything with ABRs nor ABRs
>> need to pass that information around.
>>
>> Best regards,
>> R.
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
lot of overhead in addition to the IGP!
>>
>> If "that" would be true maybe such a conclusion would be ok ... but it is
>> not.
>>
>> Thx,
>> R.
>>
>>
>>
>>
>> On Sun, Jan 23, 2022 at 10:18 PM Gyan Mishra
>> wrote:
&
lication is active on it.
> >>>>>>
> >>>>>> Best,
> >>>>>> R.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jan 11, 2022 at 1:07 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
> >>>>>> Robert -
> >>>>>>
> >>>>>> From: Robert Raszuk
> >>>>>> Sent: Monday, January 10, 2022 2:56 PM
> >>>>>> To: Les Ginsberg (ginsberg)
> >>>>>> Cc: Tony Li ; Christian Hopps ;
> Peter Psenak (ppsenak) ; Shraddha Hegde <
> shrad...@juniper.net>; Aijun Wang ; Hannes
> Gredler ; lsr
> >>>>>> Subject: Re: [Lsr] BGP vs PUA/PULSE
> >>>>>>
> >>>>>> Les,
> >>>>>>
> >>>>>> We have received requests from real customers who both need to
> summarize AND would like better response time to loss of reachability to
> individual nodes.
> >>>>>>
> >>>>>> We all agree the request is legitimate.
> >>>>>>
> >>>>>> [LES:] It does not seem to me that everyone does agree on that –
> but I appreciate that you agree.
> >>>>>>
> >>>>>> But do they realize that to practically employ what you are
> proposing (new PDU flooding) requires 100% software upgrade to all IGP
> nodes in the entire network ? Do they also realize that to effectively use
> it requires data plane change (sure software but data plane code is not as
> simple as PI) on all ingress PEs ?
> >>>>>>
> >>>>>> [LES:] As far as forwarding, as Peter has indicated, we have a POC
> and it works fine. And there are many possible ways for implementations to
> go.
> >>>>>> It may or may not require 100% software upgrade – but I agree a
> significant number of nodes have to be upgraded to at least support pulse
> flooding.
> >>>>>>
> >>>>>>
> >>>>>> And with scale requirements you are describing it seems this would
> be 1000s of nodes (if not more). That's massive if compared to alternative
> approaches to achieve the same or even better results.
> >>>>>>
> >>>>>> [LES:] Be happy to review other solutions if/when someone writes
> them up.
> >>>>>> I think what is overlooked in the discussion of other solutions is
> that reachability info is provided by the IGP. If all the IGP advertises is
> a summary then how would individual loss of reachability become known at
> scale?
> >>>>>> You seem focused on the notification delivery mechanism only.
> >>>>>>
> >>>>>> Les
> >>>>>>
> >>>>>> Many thx,
> >>>>>> Robert
> >>>>>>
> >>>>>> ___
> >>>>>> Lsr mailing list
> >>>>>> Lsr@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/lsr
> >>>>>
> >>>>
> >>>
> >>
> >
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
summarization.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
t Raszuk
> *Sent:* Friday, January 14, 2022 4:20 AM
> *To:* Gyan Mishra
> *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar <
> linda.dun...@futurewei.com>; lsr@ietf.org
> *Subject:* Re: [Lsr] Seeking feedback to the revised
> draft-dunbar-lsr-5g-edge-compute
>
>
>
>
if separate
> topology) based on that information.
>
> I do not see this like a move into the right direction. That is my input.
>
> Kind regards,
> Robert.
>
>
>
>
>
>
>
>
> On Fri, Jan 14, 2022 at 4:53 AM Gyan Mishra wrote:
>
>> Robert
>
rver teams
engineering the sizing of the server clusters to ensure what you described
won’t happen.
>
> For me the conclusion is that IGP transport level is not the proper layer
> to address the requirement.
>
> Cheers,
> Robert.
>
>
> On Thu, Jan 13, 2022 at 7:05
other responses on this thread.
>
>
>
> Thanx.
>
>
>
> Les
>
>
>
>
>
> *From:* Gyan Mishra
> *Sent:* Wednesday, January 12, 2022 5:26 PM
> *To:* Robert Raszuk
> *Cc:* Les Ginsberg (ginsberg) ; Linda Dunbar <
> linda.dun...@futurewei.com>; lsr@
lude SR-TE, SRv6 (ugh!), and any other controller based
>> TE that you care to name.
>>
>> Tony
>>
>> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
t and say per src-dst
>> tuple or more spreads the traffic. IGP does not play that game today I am
>> afraid.
>>
>> [Linda] There is one SRC and multiple paths to one DST. IGP has been used
>> for the Multi-path computation for a long time.
>>
>>
>>
>> Thank you, Linda
>>
>>
>>
>> Thx a lot,
>> R.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com *
*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
ch type uses a different assigned destination
> UDP port number.
>
> Regards,
> Greg
>
> On Mon, Jan 10, 2022 at 5:36 PM Gyan Mishra wrote:
>
>>
>> Greg
>>
>> I believe the scalability context for multi hop BFD is the operational
>> complexity introduced
1 - 100 of 282 matches
Mail list logo
