On Apr 28, 2016, at 11:13 AM, [email protected] wrote: > > Rabah Guedrez > Thésard > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > Phone: +33 2 96 07 18 56 > [email protected] > > > > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:[email protected]] > Envoyé : mercredi 27 avril 2016 15:50 > À : GUEDREZ Rabah IMT/OLN > Cc : [email protected]; [email protected] > Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt > > >> On Apr 27, 2016, at 3:17 PM, [email protected] 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 >> [email protected] >> >> >> _________________________________________________________________________________________________________________________ >> >> 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 >> [email protected] >> 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. > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
