Subject: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt

From: <[email-masked]>
Date: Wed, 27 Apr 2016 13:17:57 +0000

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.

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.

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?)

Bests.

[Orange logo]<http://www.orange.com/>

Rabah Guedrez
Thésard
ORANGE/IMT/OLN/WTC/IEE/ITEQ

Phone: +33 2 96 07 18 56 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2096%2007%2018%2056>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 27 Apr 2016 13:50:28 +0000

> On Apr 27, 2016, at 3:17 PM, [email-masked] wrote:
> 
> Hi, 

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.

> 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.

> Phone: +33 2 96 07 18 56 
> [email-masked]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: <[email-masked]>
Date: Wed, 27 Apr 2016 14:09:19 +0000

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 
 
Phone: +33 2 96 07 18 56 
[email-masked] 

-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Envoyé : mercredi 27 avril 2016 15:50
À : GUEDREZ Rabah IMT/OLN
Cc : [email-masked]; [email-masked]
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

  C-flag: Clean-up flag.  

> 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.

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 27 Apr 2016 14:15:20 +0000

> On Apr 27, 2016, at 4:09 PM, [email-masked] wrote:
> 
> 

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.

---

From: <[email-masked]>
Date: Thu, 28 Apr 2016 09:13:50 +0000

Rabah Guedrez 
Thésard 
 
Phone: +33 2 96 07 18 56 
[email-masked] 

-----Message d'origine-----

  C-flag: Clean-up flag.  

Rabah : >>>>>> do you consider that the c-flag must be set for all the packets.
 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
               The SRH has to be ignored based on RFC2460, is that corrects ? which in my opinion is not the intended behavior .
s.
Rabah

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 28 Apr 2016 10:30:47 +0000

> 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.

> 	2. a routing header is present

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.

---

From: <[email-masked]>
Date: Thu, 28 Apr 2016 10:58:12 +0000

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 
 
Phone: +33 2 96 07 18 56 
[email-masked] 

-----Message d'origine-----
Envoyé : jeudi 28 avril 2016 12:31

On Apr 28, 2016, at 11:13 AM, [email-masked] wrote:
> De : Stefano Previdi (sprevidi) [mailto:[email-masked]] Envoyé : 
> mercredi 27 avril 2016 15:50 À : GUEDREZ Rabah IMT/OLN Cc : 
> [email-masked]; [email-masked] Objet : Re: I-D Action: 
> draft-ietf-6man-segment-routing-header-01.txt
> 
> 
>> 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
>> 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,
>> 
>> 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?)
> 
> 

no.

> 	2. a routing header is present

when you use encapsulation and you don't set the c-flag, then the egress receives the packet as you described above.

> which in my opinion is not the intended behavior .

can you explain what you mean by "not the intended behavior" ?

s.

>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> 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.
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 28 Apr 2016 11:46:01 +0000

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: [email-masked] [[email-masked]]
Received: Thursday, 28 Apr 2016, 12:58
To: Stefano Previdi (sprevidi) [[email-masked]]
CC: [email-masked] [[email-masked]]; [email-masked] [[email-masked]]
Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

Rabah Guedrez
Thésard

Phone: +33 2 96 07 18 56
[email-masked]

-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
Envoyé : jeudi 28 avril 2016 12:31
À : GUEDREZ Rabah IMT/OLN
Cc : [email-masked]; [email-masked]
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

no.

s.

---

From: <[email-masked]>
Date: Fri, 29 Apr 2016 07:29:17 +0000

If we consider SRH insertion with IPv6 PHP, the original destination address would be lost when removing the SRH,
The packet reaches the egress with a DA that matches egress address, but no other information how to forward the packet to its final destination

Rabah Guedrez
Thésard

De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
Envoyé : jeudi 28 avril 2016 13:46
À : GUEDREZ Rabah IMT/OLN
Cc : [email-masked]; [email-masked]
Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

s.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [[email-masked]]
Received: Thursday, 28 Apr 2016, 12:58
To: Stefano Previdi (sprevidi) [[email-masked]]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]]; [email-masked]<mailto:[email-masked]> [[email-masked]]
Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

Rabah Guedrez
Thésard

Phone: +33 2 96 07 18 56

-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:[email-masked]]
Envoyé : jeudi 28 avril 2016 12:31
À : GUEDREZ Rabah IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt

On Apr 28, 2016, at 11:13 AM, [email-masked]<mailto:[email-masked]> wrote:
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Objet : Re: I-D Action:
>> On Apr 27, 2016, at 3:17 PM, [email-masked]<mailto:[email-masked]> wrote:
>>
>> Hi,

no.

s.

>> [email-masked]<mailto:[email-masked]>

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 29 Apr 2016 08:40:40 +0000

well, I think you missed how routing headers are handled in ipv6.

Please read rfc2460 section 4.4 and then draft-ietf-6man-segment-routing-header section 4 and especially section 4.3.

You’ll see that the routing header is not an mpls label stack.

s.

> On Apr 29, 2016, at 9:29 AM, [email-masked] wrote:
>