Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

well, I think you missed how routing headers are handled in ipv6. Please read rfc2460 section 4.4 and then draft-ietf-6man-segment-routing-header section 4 and especially section 4.3. You’ll see that the routing header is not an mpls label stack. s. > On Apr 29, 2016, at 9:29 AM, rabah.gued..

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

If we consider SRH insertion with IPv6 PHP, the original destination address would be lost when removing the SRH, The packet reaches the egress with a DA that matches egress address, but no other information how to forward the packet to its final destination [Orange logo]

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

There are many operators and use cases where, instead of encapsulation, srh insertion is a far better option. In fact all current implementations are doing srh insertion. Still, from a spec perspective, the srh processis the same. s. -Original Message- From: rabah.gued...@orange.com [r

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

You have said in a previous response to a question that the draft only consider the encapsulation of client packet into a new IPV6 header with SRH, and not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunnel client traffic (not

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

On Apr 28, 2016, at 11:13 AM, rabah.gued...@orange.com wrote: > > Rabah Guedrez > Thésard > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > Phone: +33 2 96 07 18 56 > rabah.gued...@orange.com > > > > -Message d'origine- > De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Envoyé : m

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

  Rabah Guedrez Thésard ORANGE/IMT/OLN/WTC/IEE/ITEQ   Phone: +33 2 96 07 18 56 rabah.gued...@orange.com   -Message d'origine- De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] Envoyé : mercredi 27 avril 2016 15:50 À : GUEDREZ Rabah IMT/OLN Cc : spring@ietf.org; i...@iet

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

> On Apr 27, 2016, at 4:09 PM, rabah.gued...@orange.com wrote: > > > Yes, i think that a more accurate description is required. > > I have an additional question, > > In section 4.1 > You say that the source node initializes the Segments left & first segment > pointers to n-1, and the DA = se

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

Yes, i think that a more accurate description is required. I have an additional question, In section 4.1 You say that the source node initializes the Segments left & first segment pointers to n-1, and the DA = segment list[n-1], Do you consider that the first segment of the SR path (the last o

Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

> On Apr 27, 2016, at 3:17 PM, rabah.gued...@orange.com wrote: > > Hi, > I would like some clarification about the treatment of the SRH by an end > point (the node that its loopback matches the DA field), > > In section 3 : > You say that the > C-flag: Clean-up flag. Set when the SRH has t

[spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

Hi, I would like some clarification about the treatment of the SRH by an end point (the node that its loopback matches the DA field), In section 3 : You say that the C-flag: Clean-up flag. Set when the SRH has to be removed from the packet when the packet reaches the last segment. Wh