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...@orange.com wrote: > > 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 > > > <image001.gif> > > Rabah Guedrez > Thésard > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > Phone: +33 2 96 07 18 56 > rabah.gued...@orange.com > > > De : Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Envoyé : jeudi 28 avril 2016 13:46 > À : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; i...@ietf.org > Objet : RE: 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 [rabah.gued...@orange.com] > Received: Thursday, 28 Apr 2016, 12:58 > To: Stefano Previdi (sprevidi) [sprev...@cisco.com] > CC: spring@ietf.org [spring@ietf.org]; i...@ietf.org [i...@ietf.org] > Subject: RE: 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 modify the header of the client packets for security > reasons). > > If you only consider encapsulation, does keeping c-flag relevant? > > 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é : jeudi 28 avril 2016 12:31 > À : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; i...@ietf.org > Objet : Re: 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é : > > mercredi 27 avril 2016 15:50 À : GUEDREZ Rabah IMT/OLN Cc : > > spring@ietf.org; i...@ietf.org Objet : Re: 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 to be removed from > >> the packet when the packet reaches the last segment. > > > > > > the text is confusing but the semantic is correct ;-) > > > > the cleanup flag is processed so that the last segment receives a packet > > without any SRH. > > > > However, as you figured out, the processing of the C flag is done on the > > segment before last (penultimate segment). So, probably a more accurate > > text would be: > > > > C-flag: Clean-up flag. > > Set when the SRH has to be removed from > > the packet prior to forward the packet > > towards the last segment. > > > > > > > >> Which mean that the last node inspects the SRH flags if the c-flag is set, > >> the node has to remove the SRH before sending the packet to its final > >> destination. > >> > >> But In section 4.3. > >> > >> You say that the node that decrements the Segments left pointer has > >> to check if the c-flag is set when the new value of the segments left > >> point is equal to zero, If the c-flag is set and the segments left > >> pointer == 0 then remove the SRH, > >> > >> What is confusing for me is that the node that decrements the pointer is > >> not the last node in the SR path (behavior similar to PHP for MPLS) , > >> which I find in direct contradiction with section 3. > > > > > > you're right. The node that processes the cleanup flag is the penultimate > > segment, not the last. > > > > > >> Another question if a node receives a packet with the already segment > >> left == 0, what should that node do with the packet(e.g., drops it?) > > > > > > a node receiving a packet where: > > 1. DA == itself > > 2. a routing header is present > > 3. segments_left == 0 > > > > MUST ignore the routing header and process the packet normally. This > > is described in RFC2460 section 4.4 > > > > Rabah : >>>>>> do you consider that the c-flag must be set for all the > > packets. > > > no. > > The c-flag is to be set when you insert an SRH into an existing packet. > > You set the c-flag so to be sure the SRH is removed before delivering the > packet to its intended destination. > > > > if we consider that setting the c-flag is not obligatory, then the egress > > would receive an SRH with : > > 1. DA == itself > > 2. a routing header is present > > 3. segments_left == 0 > > > when you use encapsulation and you don't set the c-flag, then the egress > receives the packet as you described above. > > > > The SRH has to be ignored based on RFC2460, is that corrects ? > > > yes, the above is normal behavior when the path is completed (i.e.: all > segments have been processed and the DA is the intended destination of the > packet). > > > > which in my opinion is not the intended behavior . > > > can you explain what you mean by "not the intended behavior" ? > > s. > > > > s. > > Rabah > > > >> > >> > >> Bests. > >> > >> > >> <image001.gif> > >> > >> Rabah Guedrez > >> Thésard > >> ORANGE/IMT/OLN/WTC/IEE/ITEQ > >> > >> Phone: +33 2 96 07 18 56 > >> rabah.gued...@orange.com > >> > >> > >> _____________________________________________________________________ > >> ____________________________________________________ > >> > >> 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. > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> i...@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > 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. > > > > > _________________________________________________________________________________________________________________________ > > 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. > > _________________________________________________________________________________________________________________________ > > 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. > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
