Re: [spring] RTG-DIR Last Call review of draft-ietf-spring-segment-routing-mpls-18

Thanks a lot for the review I uploaded version 19 of the draft, which, IMO, addresses all your comments See the reply "#Ahmed" On 3/10/19 9:55 AM, Alexander Vainshtein wrote: Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to rev

[spring] I-D Action: draft-ietf-spring-segment-routing-mpls-19.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking WG of the IETF. Title : Segment Routing with MPLS data plane Authors : Ahmed Bashandy

Re: [spring] IPv6-compressed-routing-header-crh

I would like to see working path MTU of some form for many different reasons. I would also like to see larger practical MTUs. However, history suggests that both goals may be more aspirational than practical. I tend to be very skeptical of any anlysis that says that user traffic is changing t

Re: [spring] IPv6-compressed-routing-header-crh

That was one of my points. We would want to substantiate both pps and bps sides for the overhead argument to work. Now, I would reserve the viewpoint whether it is useful or not. :-) Cheers, Rajiv On Mar 28, 2019, at 5:18 PM, john leddy.net mailto:j...@leddy.net>> wrote:

Re: [spring] IPv6-compressed-routing-header-crh

Joel, It would be good to factor in the ever growing amount of video on the Internet (and other large data transfer applications vs voice traffic). If larger MTU's could reliably be used, I think you would see a large amount of traffic starting to use something larger than 1500 byte Cells. Get

Re: [spring] IPv6-compressed-routing-header-crh

Hi Joel, Is your hidden message to express that neither TCP nor UDP with voice app should use IPv6 at all as overhead is just too big even without additional extension headers ? Best, R. On Thu, Mar 28, 2019, 16:44 Joel M. Halpern wrote: > One needs to be very careful about packet size reason

Re: [spring] [ippm] draft-gandhi-spring-twamp-srpm - comment

Hi Rajiv, Many thanks for your comments. We will incorporate the suggestion in the next revision of the document along the lines of “synthetic probes messages congruent to the data traffic”. Thanks, Rakesh On 2019-03-28, 3:17 PM, "ippm on behalf of Rajiv Asati (rajiva)" wrote: Hi Rakes

Re: [spring] IPv6-compressed-routing-header-crh

One needs to be very careful about packet size reasoning. For TCP, something like 1/3 of all packets are tiny (acks). A lot less than 1/3 of the bytes are in tiny packets :-) For voice traffic, almost all packets are small. Yours, Joel On 3/28/19 4:36 PM, Rajiv Asati (rajiva) wrote: Hi Ron,

[spring] IPv6-compressed-routing-header-crh

Hi Ron, Very Interesting idea that you presented during SPRING session today. Seems useful. Two comments/clarification - 1. One of the slides indicated that small packet size on the Internet was ~500B and calculated ~10% due to Routing EH overhead accordingly. Of course, if we look at mid p

[spring] draft-gandhi-spring-twamp-srpm - comment

Hi Rakesh, It is a useful draft. Simplifies TWAMP usage in SR networks. Given that the draft defines dedicated probes and response messages to measure PM/DM/LM, please consider not using the term Inband, as it would mean mucking up the user packets like specified in IOAM. Cheers, Rajiv __

[spring] RP1 research paper Technical feasibility of Segment Routing Traffic Engineering to steer traffic through VNFs

the research paper mentioned at the mike Cheers, Jeff ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] draft-bashandy-isis-srv6-extensions-05.txt

On 28/03/2019 11:09 , Rajesh M wrote: One more query guys 😊 draft-bashandy-isis-srv6-extensions-05.txt says: Section 3. Advertising Supported Algorithms SRv6 capable router indicates supported algorithm(s) by advertising the SR Algorithm sub TLV as defined in [I-D.ietf-isis-segment-routing-ext

Re: [spring] draft-bashandy-isis-srv6-extensions-05.txt

One more query guys 😊 draft-bashandy-isis-srv6-extensions-05.txt says: Section 3. Advertising Supported Algorithms SRv6 capable router indicates supported algorithm(s) by advertising the SR Algorithm sub TLV as defined in [I-D.ietf-isis-segment-routing-extensions]. https://tools.ietf.org/pdf/dr