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