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 For example, for the following SR path PE1-P2-P3-PE4 does the segment list == [PE4,P3,P2,PE1] or [PE4,P3,P2] 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
