I am in agreement with the RFC SR requirements for no next header.
Gyan S. Mishra
IT Network Engineering & Technology Consultant
Routing & Switching / Service Provider MPLS & IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000
Sent from my iPho
IPv6 Expert
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Mobile – 202-734-1000
Sent from my iPhone
> On Apr 14, 2019, at 7:54 PM, Ron Bonica
> wrote:
>
> Hi Robert,
>
> In order to make the CRH ASIC-friendly, we have the following constraints:
>
> Support
>> The Compressed Routing Header (CRH) has exactly one function. That is to
>> route a packet for segment to segment along an SR path. Therefore, SIDs
>> contained by the CRH have only one function. That is to steer packets to the
>> next segment.
>>
>>
>>
&
engineering of flows between data centers or access to data center and an
alternative to SD WAN application based routing solutions. But here as well
the use case benefit has to exist. Nobody wants to be forced into it if it’s
unnecessary added complexity.
My 2 1/2 cents
Regards,
Gyan Mishra
Daren
This is from 2019 CISCO Live presentation
https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKMPL-2132.pdf
IETF Standardization
• The work started by Cisco in 2014
• Significant industry collaboration
• There are over SRv6 50 IETF documents
• The work spans over 13 working
EH’s
Gyan
Sent from my iPhone
> On Sep 18, 2019, at 7:56 PM, Gyan Mishra wrote:
>
> Daren
>
> This is from 2019 CISCO Live presentation
>
> https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2019/pdf/BRKMPL-2132.pdf
>
> IETF Standardization
> • The
mbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: gyan.s.mis...@verizon.com
www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
Sent from my iPhone
> On Sep 7, 2019, at 11:39 AM, Xiejingrong wrote:
>
> +1.
> I didn't see the possibility of
through more
carefully but I am not seeing how an intermediate node would require EH
insertion since that function is always on the source node head end of the
traffic engineered path.
Regards,
Gyan
>> On Sep 19, 2019, at 18:06, Gyan Mishra wrote:
>>
>> Hi Robert
>>
>
every implementation even though IP LFA is much more widely used then
traditional TE FRR where Ti-LFA is providing both capabilities in one feature
Ti-LFA with SRv6 so we definitely have to get this figured out with the RFC
8200 violation from a 6MAN perspective.
Regards,
Gyan
> Many thx,
>
Hi Robin
Here are some details related to existing Inter domain MPLS which has come a
long ways since inception decades ago.
Inter AS options A, B, C & CSC
https://tools.ietf.org/html/rfc4364#section-10
Inter AS option AB
https://datatracker.ietf.org/doc/draft-mapathak-interas-ab/
Inter AS
Hi Stephanie
+ 6MAN & Spring
I was thinking about the BGP capability exchange between address families
concept from a 6MAN and operations perspective treating the next hop as a pure
ubiquitous transport carrying v4 and v6 NLRI and the significance and
advantages from a deployment
of a static explicit route object by selecting nodes
along a path based on hardware features?
In the deployments how was the binding SID used for TI-LFA fast reroute ar
tar PLR junction to the PQ loop free tunnel node?
Kinds Regards,
Gyan
On Sat, Nov 16, 2019 at 1:43 AM Gyan Mishra wrote:
or
centralized controller model.
Warm regards,
Gyan
On Sun, Dec 15, 2019 at 2:59 AM Gyan Mishra wrote:
> Jeff
>
> With SR-MPLS with SR-TR let’s say if you use cSPF snd don’t have an ERO
> strict explicit path defined or is a loose path, then the for the cSPF
> would the transp
Jeff
With SR-MPLS with SR-TR let’s say if you use cSPF snd don’t have an ERO
strict explicit path defined or is a loose path, then the for the cSPF
would the transport labels be 1. For loose would also be 1 also. If the
path were explicit defined to egress PE and was 7 hops from ingress to
All
The concept of PHP “Penultimate Hop POP” and UHP “Ultimate Hop POP” have
historical meaning as well as real consequences as far as a packet walk
through an mpls network.
>From a historical perspective which is really the correct way to look at
PHP in the MPLS world was designed by the
Hi Wang
I have a question regarding the PSP, USP and USD sections I pasted below.
I just sent an email to Spring WG related to PSP and technically why that
is necessary as that is a legacy concept that has parity to MPLS but is not
used today due to QOS issues. Please see that email related to
.dt46 sid
4.8
<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.8>.
End.DT46: Decapsulation and specific IP table lookup . . 16
<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-16>
Kind Regards,
Gyan
On Su
Jeff
>
> P.S. you might want to see the NANOG MSD presentation I did some time ago..
>
> https://pc.nanog.org/static/published/meetings/NANOG71/1424/20171004_Tantsura_The_Critical_Role_v1.pdf
> On Dec 14, 2019, 11:59 PM -0800, Gyan Mishra ,
> wrote:
>
> Jeff
>
> With
ption.
>
> Best,
> Robert.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Dec 15, 2019 at 6:10 PM Gyan Mishra wrote:
>
>>
>> Dan
>>
>> The concept of PHP “Penultimate Hop POP” and UHP “Ultimate Hop POP” have
>>
Dan
The concept of PHP “Penultimate Hop POP” and UHP “Ultimate Hop POP” have
historical meaning as well as real consequences as far as a packet walk
through an mpls network.
>From a historical perspective which is really the correct way to look at
PHP in the MPLS world was designed by the
On Tue, Dec 17, 2019 at 10:05 AM Ron Bonica wrote:
> Pablo,
>
> In your message below, are you arguing that it is easier for the
> penultimate node to remove the SRH than it is for the ultimate node to
> ignore it? I think that would be a stretch.
>
>
> Ron
>
>
>
> Juniper Business Use Only
n general, SID stack would grow when TE is in use (any time you need to
> use additional SID to deviate from SPT), another case is when additional
> SID’s are used for services on the nodes, other than the tail-end..
>
> That’s why we've designed MSD to be very flexible to accommodate all
On Wed, Dec 11, 2019 at 3:37 AM Robert Raszuk wrote:
> Hi Brian,
>
> > Each SR node (Segment Endpoint) is effectively applying new IPv6 encap
>> so is already doing an insertion of new SRH
>>
>> That isn't "insertion" in the sense of draft-voyer.
>
>
> Correct. But we are not discussing
On Mon, Oct 14, 2019 at 4:31 PM Mark Smith wrote:
>
>
> On Tue, 15 Oct 2019, 04:19 Ron Bonica, wrote:
>
>> Mark,
>>
>>
>>
>> Clearly, this does not comply with the addressing architecture. But I
>> think that the best we can do is to limit the damage.
>>
>
> Has SPRING tried?
>
> Assigning this
In-line comments
Thanks
Gyan
Sent from my iPhone
> On Oct 3, 2019, at 12:25 PM, Ron Bonica
> wrote:
>
> Fernando,
>
> Someone should. I think that the expertise to do this is in 6man.
>
> Ron
>
>
> Juniper Business Use Only
>
> -Original
ght
> represent the locator as B:N where B is the SRv6 SID block (IPv6
> subnet allocated for SRv6 SIDs by the operator) and N is the
> identifier of the parent node."
>
>Ron
>
>
>
> Juniper Bu
ork; how to allocate the SID and how to indicate length of SID prefix May
> be up to operator and its specific network scenario.
>
> --
> Cheers !
>
>
> WANG Weibin
>
> -Original Message-
> From: spring On Beha
o see a running implementation to judge what the behavior is
> supposed to be, it sounds like we could use clarifications of the
> specification.
>
> Yours,
> Joel
>
> On 10/11/2019 11:06 AM, Gyan Mishra wrote:
> >
> > Good point. I think we need someone who has thi
in-line comment
On Fri, Oct 11, 2019 at 12:38 PM Gyan Mishra wrote:
>
> Sorry I should have read through the draft more carefully as its depicted
> clearly in an example in section 3. So the SIDs must be "routable" within
> the SRv6 domain per the draft.
>
>
> h
thin the
domain to get to any node within the domain.
>
>
> *WANG Weibin *
>
>
>
> *From:* spring *On Behalf Of *Gyan Mishra
> *Sent:* 2019年10月12日 0:52
> *To:* Joel M. Halpern ; Ron Bonica <
> rbon...@juniper.net>
> *Cc:* SPRING WG List
> *Subject:* Re: [spring] draft-
In-line
Sent from my iPhone
> On Oct 14, 2019, at 12:47 AM, Gyan Mishra wrote:
>
> Rajesh
>
> I believe that is how it’s written but want to confirm that with SRv6 we
> added the PSP to mirror mpls and SR-MPLS PHP and added USP to mirror mpls and
> UHP penultimate
Rajesh
I believe that is how it’s written but want to confirm that with SRv6 we added
the PSP to mirror mpls and SR-MPLS PHP and added USP to mirror mpls and UHP
penultimate and ultimate hop pop that occurs either the default behavior on the
egress P or USP on the egress PE FEC destination.
On Mon, Oct 14, 2019 at 1:45 AM Wang, Weibin (NSB - CN/Shanghai) <
weibin.w...@nokia-sbell.com> wrote:
> Hi Ron:
>
>
>
> Make sense, If there is a dedicated IPv6 block for SRv6 SID within SRv6
> domain, then trouble situation you described does NOT occur, because the
> IPv6 address covered within
On Mon, Oct 14, 2019 at 10:34 AM Robert Raszuk wrote:
> Gyan,
>
> [Gyan] Spring WG -?? Because SRv6 uses the same IPv6 data plan as
"Business as Usual" NORMAL IPv6 traffic use case of the "internet" so
the an "SRv6 enabled router" that has the code that supports SRv6 has the
On Mon, Oct 14, 2019 at 10:12 AM Gyan Mishra wrote:
>
>
> On Mon, Oct 14, 2019 at 1:45 AM Wang, Weibin (NSB - CN/Shanghai) <
> weibin.w...@nokia-sbell.com> wrote:
>
>> Hi Ron:
>>
>>
>>
>> Make sense, If there is a dedicated IPv6 block for SRv
terms “topmost label”. So the external to SRv6
> domain, PE-CE M-BGP BGP services is really separate covered by the draft
> above.
>
>
> Juniper Business Use Only
>
> *From:* spring *On Behalf Of *Pablo Camarillo
> (pcamaril)
> *Sent:* Thursday, December 19, 2019 6:47
On Thu, Dec 19, 2019 at 4:17 PM Mark Smith wrote:
>
>
> On Thu, 19 Dec 2019, 22:48 Pablo Camarillo (pcamaril),
> wrote:
>
>> Hi,
>>
>> As mentioned in the draft, the choice of the locator length is deployment
>> specific.
>> LINE has deployed SRv6 using a locator different than a /64.
>>
>
>
o even then I don’t think this dt64 is necessary.
>
> Cheers,
>
> Pablo.
>
>
>
> *From: *Gyan Mishra
> *Date: *Sunday, 15 December 2019 at 08:29
> *To: *"Wang, Weibin (NSB - CN/Shanghai)"
> *Cc: *"Pablo Camarillo (pcamaril)" , "Voyer, Daniel
On Thu, Dec 19, 2019 at 8:45 PM Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:
> On 20-Dec-19 12:01, Robert Raszuk wrote:
> >> And where is it forwarded to, since we are already at the DA?
> >
> > PSP operates at the n-1 segment end of the SR path so naturally after
> swapping DA it is
On Fri, Dec 20, 2019 at 1:22 AM Gyan Mishra wrote:
>
>
> On Thu, Dec 19, 2019 at 8:45 PM Brian E Carpenter <
> brian.e.carpen...@gmail.com> wrote:
>
>> On 20-Dec-19 12:01, Robert Raszuk wrote:
>> >> And where is it forwarded to, since we are already at th
echnology
> behind the terminology.
> Let me know if anything is unclear.
>
> Cheers,
> Jeff
> On Dec 17, 2019, 3:45 PM -0800, Gyan Mishra ,
> wrote:
>
>
> Hi Ketan
>
> Is this the artificial boundary below for SR-TE from the document provided
> by Jeff.
>
> MSD suppo
Thank you Jeff for taking the time for the detailed response!!
Cheers & Happy Holidays!!
Gyan
On Wed, Dec 18, 2019 at 7:13 PM Jeff Tantsura
wrote:
> Pleasure, see inline
> /*somewhat philosophical ;-)
>
> Cheers,
> Jeff
> On Dec 17, 2019, 10:28 PM -0800, Gyan Mishra ,
ng Internet Standard 86/RFC8200 means this ID
> needs to have Experimental rather than Standards Track status.
>
>
>
>
>
>
>
>
> Cheers,
> Sander
>
> ___
> spring mailing list
> spring@ietf.org
> https://w
gt; insertion. On the other hand, pretending there's no violation will
> certainly trigger many appeals and objections at the IETF last call (I'll
> certainly object to it). In the end, it can easily take much longer, or
> even fail, than formally claiming an update to RFC8200.
>
>
Along those same lines of thought.
If you upgrade all your source SR node ingress PEs to be SRv6 capable you
have in fact upgraded all your final destination egress PE nodes to be SRv6
capable.
Gyan
On Fri, Feb 28, 2020 at 9:37 PM Gyan Mishra wrote:
> Jingrong & Bruno
>
> He
archive.ietf.org/arch/msg/spring/ErcErN39RIlzkL5SKNVAeEWpnAI>
>
>
>
> I don't see the point of starting a new thread from zero that discusses
> the same thing.
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> *From: *Gyan Mishra
> *Date: *Tuesday, 25 February 2020 at 00
.
>
> --
> JINMEI, Tatuya
> --------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
ith the
>Destination Address field of the IPv6 Header equal to its SID
>address. A penultimate SR Segment Endpoint Node is one that, as part
>of the SID processing, copies the last SID from the SRH into the IPv6
>Destination Address and decrements Segments Left value
Inline gyan>
On Thu, Feb 27, 2020 at 4:00 PM Pablo Camarillo (pcamaril) <
pcama...@cisco.com> wrote:
> Gyan,
>
>
>
> Inline [PC1].
>
>
>
> Thanks,
>
> Pablo.
>
>
>
> *From: *Gyan Mishra
> *Date: *Thursday, 27 February 2020 at 08:1
may just drop any packet with Next Header value other than 4/41/47/etc..
>
> It may send such packet with any routing header to its slow-path for the
> compliance but lose the necessary performance.
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Gyan Mishra [
header?
>
> The inner payload are IP frames, aren’t they?
>
>
>
> Thank you very much,
>
>
>
> Linda Dunbar
>
>
>
>
>
>
> _______
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mail
the knowledge that services are needed and I
think encoding the SFC in the ultimate segment egress PE would signal
egress PE to now steer the flow to the service SID endpoint.
Kind regards
Gyan
On Fri, Jan 17, 2020 at 12:13 AM Gyan Mishra wrote:
>
> Hi Linda
>
> Those are good questions
Chiming in on SR-MPLS and SRv6 feature parity discussion.
SRv6 and SR-MPLS serve as future MPLS replacement options for operators.
The architecture of both technologies are completely different as to how
they operate.
>From a timeline historical perspective we had atm and frame relay followed
I support early allocation as their are many IPv6 deployments around the
world.
Gyan
On Thu, Jan 2, 2020 at 11:00 PM Zhuangshunwan
wrote:
> I support this early allocation.
>
>
>
> Thanks,
>
> Shunwan
>
>
>
> *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *
>
On Fri, Dec 27, 2019 at 7:56 PM Mark Smith wrote:
> On Sat, 28 Dec 2019 at 09:45, Robert Raszuk wrote:
> >
> > Hi Mark,
> >
> > Happy New Year !
> >
> >>
> >> The key point is that RIDs look like IPv4 addresses, but are not. They
> only have adopted the formatting convention of IPv4 addresses.
On Fri, Dec 27, 2019 at 5:45 PM Robert Raszuk wrote:
> Hi Mark,
>
> Happy New Year !
>
>
>> The key point is that RIDs look like IPv4 addresses, but are not. They
>> only have adopted the formatting convention of IPv4 addresses. They're 32
>> bit quantities. They could have just as easily been
Thank you
Gyan
On Sun, Apr 5, 2020 at 12:09 PM Peter Psenak wrote:
> Hi Gyan,
>
> On 01/04/2020 03:43, Gyan Mishra wrote:
> > Thank you both for your feedback. That really helps a lot and clarifies.
> >
> > So flex-algo can be used with SR-TE as part of the po
half Of Peter Psenak
> Sent: 31 March 2020 13:42
> To: Gyan Mishra ; SPRING WG
> Subject: Re: [spring] SRV6 - SR-TE support & Flex Alg support ? and
> comparison and contrast of those two steering strategies
>
> Hi Gyan,
>
> let me comment on the flex-algo aspect. Please see
R-TE over flex Alg and vice versa?
Also can SR-TE use flex Alg steered paths as the dynamic cSPF paths?
Can SR-TE use and specify flex Alg to be used for traffic steering?
Kind regards
Gyan
Verizon
Cell 301 502-1347
--
Gyan Mishra
Network Engineering & Technology
Verizon
Silver Spr
sing prefix SID of egress PE to replicate to and build P2MP tree
instantiation via SR-TE.
Is that possible?
Kind regards
Gyan
--
Gyan Mishra
Network Engineering & Technology
Verizon
Silver Spring, MD 20904
Phone: 301 502-1347
Email: gyan.s.mis...@ver
questions are implementation specific and should be addressed
> off the mailing list. Please contact me at ripar...@cisco.com.
>
> -Rishabh
>
> On Fri, Mar 20, 2020 at 6:41 PM Gyan Mishra wrote:
> >
> >
> > Daniel & Authors
> >
> > I had a question relate
On Sun, Mar 22, 2020 at 4:45 PM Gyan Mishra wrote:
>
>
> On Sat, Mar 21, 2020 at 3:22 PM Rishabh Parekh wrote:
>
>> Gyan,
>>
>> >The SR replication segment tree sid draft states that it can only be
>> used for PCE centralized controller model.
IP
address bindings that are required for the correct operation of mLDP.
>
> -Rishabh
>
> On Sat, Mar 21, 2020 at 11:11 AM Gyan Mishra
> wrote:
> >
> >
> > Thank you Rishabh!
> >
> > I will contact you regarding Cisco specific questions.
> >
On Sun, Mar 22, 2020 at 4:59 PM John E Drake wrote:
> https://tools.ietf.org/html/draft-shen-spring-p2mp-transport-chain-01
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* spring *On Behalf Of *G
nd control traffic. And even for IPv4 traffic that
>
> > gets collected by a central router that injects a default route.
>
> >
>
> > However, depending on the exact interpretation of the above
> paragraph,
>
> > an implementor might feel obliged to chose the next paragraph:
>
> >
&
t;
> part of the issue in a more elegant way.
>
>
> Yet they don't cover all possible failure cases.
>
>
>
>
>
> Best regards, Martin
>
>
>
>
>
>
>
>
> Am 30.08.20 um 16:21 schrieb Gyan
>
> Mishra:
>
>
>
>
>
>
>
> >>> https://www.ietf.org/mailman/listinfo/spring
>
> >>
>
> >> ___
>
> >> spring mailing list
>
> >> spring@ietf.org
>
> >> https://www.ietf.org/mailman/listinfo/spring
>
> document. Looking at the archive, there was anot a lot of discussion, and
>>
>>
>> some concerns. Rather than try to infer the current state from the old
>>
>>
>> discussions, the WG Chairs have decided to issue a WG call for adoption.
>> If
>>
>>
>> you support this becoming a WG document, please explai
t any design objective.
Comments welcome.
Kind Regards
Gyan
On Sat, Oct 10, 2020 at 3:26 PM Gyan Mishra wrote:
>
> Dear TEAS, PCE, IDR, LSR, BESS, BIER Spring Working Groups,
>
> I have noticed that after reviewing many drafts across many WGs it seems
> in the industry that the l
ought I would bring
up to the WG as an important discussion point.
Lots of food for thought. Welcome all comments as well as concerns related
to this topic.
Kind Regards,
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver
t;
> On 28.07.2020, at 10:11,
>
> thomas.g...@swisscom.com wrote:
>
>
>
>
>
>
>
>
>
>
>
> Dear lsr,
>
>
>
>
>
>
>
>
>
>
>
>
>
> I presented the following draft
>
>
>
>
>
>
>
>
>
ts for in the IANA
> IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types
> to gain further insights into the MPLS-SR forwarding-plane.
>
>
>
>
>
>
>
>
>
>
>
>
>
> I have been asked to not only gather feedback from spring a
cline 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
Fdraft-tgraf-ipfix-mpls-sr-label-type-04=02%7C01%7CThomas.Graf%40swisscom.com%7Cb7d5f12ae9054d04978608d8407869f6%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330233200625087=q9GCxkzGIMx9p4WsXwITL4t1GMaP6dj6H4gu7hJAROY%3D=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
&g
t;> > > <mailto:alexander.vainsht...@ecitele.com
>> >
>>
>>
>> > > >
>>
>>
>> > > > -Original Message-
>>
>>
>> > > > From: spring > > <mailto:spring-bou
l not be considered consent.
>
>
>
>
>
> Thanks!
>
>
>
>
>
> Jim, Joel & Bruno
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
>
> spring mailing list
>
> spring@ietf.org
>
> https://www.ietf.org/mailman/listinfo/spring
>
> --
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
s.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-tgraf-ipfix-mpls-sr-label-type-04=02%7C01%7CThomas.Graf%40swisscom.com%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465815966=1DIvkRCu5tKMVSooUnsF%2B5R1h12rVOkbYyYzqvKSgV4%3D=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> at the spring working group at IETF 108 yesterday
>
>
>
>
>
>
>
> https://www.ietf.org/proceedings/108/slides/slides-108-spring-ip-flow-information-export-ipfix-00.pdf
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-spring-ip-flow-information-export-ipfix-00.pdf=02%7C01%7CThomas.Graf%40swisscom.com%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465815966=OM8BhFC%2FQJL3h%2FjqQPULt1c5SBTaz6yp%2Bj6i0QOjJJQ%3D=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
> and today at OPSAWG where I call for adoption.
>
>
>
>
>
>
>
>
>
>
>
>
>
> This draft adds additional segment routing code points for in the IANA
> IPFIX registry for IS-IS, OPSFv2 and OPSF v3 and segment routing SID types
> to gain
>
> further insights into the MPLS-SR forwarding-plane.
>
>
>
>
>
>
>
>
>
>
>
>
>
> I have been asked to not only gather feedback from spring and opsawg but
> also from lsr and mpls working groups since these code points are related
> to link
>
> state routing protocols and mpls data plane.
>
>
>
>
>
>
>
>
>
>
>
>
>
> I am looking forward to your feedback and input.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Best Wishes
>
>
>
>
>
>
> Thomas Graf
>
>
>
>
> ___
>
>
> Lsr mailing list
>
>
> l...@ietf.org
>
>
> https://www.ietf.org/mailman/listinfo/lsr
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7CThomas.Graf%40swisscom..com%7Cdef70609f2d843c24ad908d840d954dc%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330649465825923=PHRjGhYIP%2FLnBUvtjdbv%2FweQzspjf640vWDAovlS5Is%3D=0>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
>
> OPSAWG mailing list
>
> ops...@ietf.org
>
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
S PST this coming
> Friday.
>
>
>
>
>
> Thanks!
>
>
>
>
>
> Jim, Joel & Bruno
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
>
> spring mailing list
>
> spring@ietf.org
>
> https://www.ietf.org/mailman/listinfo/spring
>
> --
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Bruno,
On Mon, Sep 28, 2020 at 4:43 AM wrote:
> Hi Gyan,
>
>
>
> *From:* Gyan Mishra [mailto:hayabusa...@gmail.com]
> SID Design Team
>
>
>
>
>
> Hi Jim, Bruno & Joel
>
>
>
> I was wondering if it would be possible to provide a brief
documents under discussion.
>
> Please access following link, if you hope to get more information.
>
> https://github.com/IETF-srcomp/documents
>
>
>
> B.R.
>
> Weiqiang Cheng
>
>
>
> *发件人:* bruno.decra...@orange.com [mailto:bruno.decra...@orange.com]
>
>>
>>
>> WH> My position remains that RFC8663 is a valid alternative and is
>> available; I am against WG adoption of CRH.
>>
>>
>>
>> The industry widely supports RFC8663.
>>
>>
>>
>> Instead of denying the evidence, could the CRH authors and proponents
>> finally understand that people are not opposed to new ideas?
>>
>>
>>
>> People are reminding a long-standing practice of the IETF process. Before
>> tackling a new piece of work, a working group must perform a due diligence
>> on
>>
>>1. whether this new work is redundant with respect to existing IETF
>>protocols,
>>2. whether this new work would deliver genuine benefits and
>>use-cases.
>>
>>
>>
>> It is factually and logically clear to the working-group that the
>> currently submitted CRH documents.
>>
>>1. fail to position CRH with respect to existing standard widely
>>supported by the industry (e.g., RFC8663)
>>2. fail to isolate new benefit or use-case [1]
>>
>>
>>
>> This positive collaborative feedback was already given in SPRING.
>>
>> The CRH authors may change this analysis. They need to document 1 and 2.
>>
>>
>>
>> Why did the CRH authors not leverage this guidance in SPRING WG?
>>
>> This was also the chair's guidance in Montreal [2] and Singapore [3]
>>
>>
>>
>> All the lengthy discussions and debates on the mailing list could be
>> avoided if only the CRH authors would tackle 1 and 2.
>>
>>
>>
>> The CRH authors must tackle 1 and 2.
>>
>>
>>
>>- This is the best way to justify a/the work from the IETF community
>>and b/ the hardware and software investment from vendors.
>>- True benefits must be present to justify such a significant
>>engineering investment (new data-pane, new control-plane).
>>
>>
>>
>> Thanks
>>
>>
>>
>> Regards … Zafar
>>
>>
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/
>> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl0PT0CIY$>
>>
>> [2]
>> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true
>> <https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl8aoFdbw$>
>>
>> [3]
>> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/
>> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVlypBDeuG$>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>> IETF IPv6 working group mailing list
>> i...@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>
>>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
CRH
>
>
>
> [SNIP]
>
>
>
> I am looking for explanation of the "other ways" that CRH can be used
> (i.e. those outside the Spring architecture). I am trying to understand
> from the authors what would be the applic
Sorry Typo 20 bit label not 2 byte label.
SR-MPLS still has the concept of FEC label binding but now just uses a
different range of 20 bit labels 16k-24k so is not overlapping with MPLS
LDP default label range.
Kind Regards
Gyan
On Thu, May 28, 2020 at 12:27 PM Gyan Mishra wrote:
>
>
ing
> >
> > - MPLS and uSID
> >
> > - To encoding instructions in IPv6 addresses.
> >
> > These operators want a compact routing header, nothing more.
> >
> >
>
> Ron
> >
> > Juniper Business Use Only
> >
> > -Origi
advertised by the controller
> is delivered to the headend through different RRs, the headend cannot
> distinguish whether it is the same CP because the node-address in the CPs'
> key comes from different RRs.
>
>
>
> To solve these problems, We recommen
since that is
> more of a local policy or implementation matter.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Gyan Mishra
> *Sent:* 01 June 2020 19:17
> *To:* Chengli (Cheng Li)
> *Cc:* Fangsheng ; Ketan Talaulikar (ketant) <
> ket...@cisco.com>; Rob
gt; > Universita' di Roma Tor Vergata
> > Viale Politecnico, 1 - 00133 Roma - ITALY
> >
> > http://netgroup.uniroma2.it/Stefano_Salsano/
> >
> > E-mail : stefano.sals...@uniroma2.it
> > Cell. : +39 320 4307310
> > Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
> > **
tered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> ___
;
>
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*
w.ietf.org/mailman/listinfo/spring
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
.
Kind Regards
Gyan
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*M 301 502-134713101 Columbia Pike *Silver Spring, MD
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
nsition via SR-MPLS. IMHO no need.
>
> Cheers,
> R.
>
>
>
>
>
> On Wed, Jun 24, 2020 at 8:56 AM Gyan Mishra wrote:
>
>>
>> Thanks Jeff
>>
>> I was looking for just vanilla SR-MPLS support natively using IPV6 data
>> plane.
>>
>>
e SR-MPLS signaling protocol (IS-IS or OSPFv3) does not required
>IPv4 to be enabled on the network.
>
>
>
>Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Jeff Ta
ahead expeditiously. We are
> currently finalizing those plans and will make an announcement to the WG
> very shortly.
>
>
>
> Thanks!
>
>
>
> Jim, Joel & Bruno
>
>
>
>
>
>
>
> *From:* spring *On Behalf Of *Gyan Mishra
> *Sent:* S
;
>
>
> Aijun Wang
>
> China Telecom
>
>
> --------
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> -
number
or next header is usually the upper layer protocol and not lower link
layer.
Is this for the 6in6 encapsulation that occurs on the SR source node ?
The next header would be IPv6 not ethernet I would think.
Gyan
On Mon, Jun 15, 2020 at 6:54 PM Gyan Mishra wrote:
> Hi Jingr
Daren
As SRv6 has its inherent MSD issues right out of the gate and requires use of a
myriad of compression techniques to make SRv6 viable for long SR-TE strict
paths.
Ref: List of competing solutions in SPRING
[1]
in a real world
deployments.
Kind Regards
Gyan
On Sat, Jun 27, 2020 at 9:13 PM Gyan Mishra wrote:
>
> Daren
>
> As SRv6 has its inherent MSD issues right out of the gate and requires use
> of a myriad of compression techniques to make SRv6 viable for long SR-TE
> strict pat
gt;
>
>
> Juniper Business Use Only
>
> *From:* spring *On Behalf Of *Gyan Mishra
> *Sent:* Tuesday, June 23, 2020 1:20 PM
> *To:* SPRING WG
> *Subject:* [spring] Spring SR question??
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
1 - 100 of 230 matches
Mail list logo
