> On Apr 27, 2016, at 4:09 PM, [email protected] 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 = segment list[n-1], > Do you consider that the first segment of the SR path (the last one in the > segment list field) is the ingress or the next node in the SR path
not the ingress. The ingress is the node that sets the segment list. > For example, for the following SR path PE1-P2-P3-PE4 does the segment list == > [PE4,P3,P2,PE1] or [PE4,P3,P2] if the segment list is created at the source of the packet then it will be: [PE4,P3,P2,PE1] if the segment list is created at the ingress (PE1) then it will be: [PE4,P3,P2] s. > > Bests > > 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 > > s. > > >> >> >> 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
