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.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
