Subject: [spring] End.DT/End.DX SIDs (was Re: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt)

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Thu, 19 Dec 2019 11:46:58 +0000

Gyan,

The End.DX4/End.DX6 can be seen as an equivalent to the MPLS per-CE VPN label.
The End.DT4/End.DT6 can be seen as an equivalent to the MPLS per-VRF VPN label.

I believe that they cannot be combined.

Cheers,
Pablo.

From: Gyan Mishra <[email-masked]>
Date: Sunday, 15 December 2019 at 08:29
To: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Cc: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Voyer, Daniel" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

Hi Wang & Pablo & Spring Authors,

Had another question?

These 4 sections.  Trying to understand the difference between end.dx4 end.dx6 and end.dt4 and end.dt6.  They both seem very similar.  One says xconnect but other has v4 v6 lookup but for both you have to signal  L3 vpn services sid.  Not sure why both SIDs dx dt Sid function why they cannot be combined.

I noticed this difference below that the dx4 dt4 account for the global table scenario where the PE-CE is native IPv4 or IPv6.  In the MPLS world that use case is very different in that there is not any L3 vpn label and do the label stack only had a single topmost label.  Also in the MPLS scenario with IPv6 global table PE-CE with a IPv4 core you require BGP -LU labeled unicast “send label” to label all the IPv6 prefixed tunneled over IPv4.   Since that scenario is very different with global table does it make sense to have a separate End.x variant for global table for both IPv4 and IPv6.

   Note that an End.DT6 may be defined for the main IPv6 table in which

   case and End.DT6 supports the equivalent of an IPv6inIPv6

   decapsulation (without VPN/tenant implication).

     4.4<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.4>.  End.DX6: Decapsulation and IPv6 cross-connect . . . . . .  12<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-12>

     4.5<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.5>.  End.DX4: Decapsulation and IPv4 cross-connect . . . . . .  13<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-13>

     4.6<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.6>.  End.DT6: Decapsulation and specific IPv6 table lookup . .  14<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-14>

     4.7<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.7>.  End.DT4: Decapsulation and specific IPv4 table lookup . .  15<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-15>

Also I was trying to understand end.dt46.

So if the PE-CE edge is dual stacked anhas both v4 and v6 you have a VRF tenant v4 and v6 separate peers signaled via L3 vpn services TLV.  So why do you need this end.dt46 sid

4.8<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.8>.  End.DT46: Decapsulation and specific IP table lookup  . .  16<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-16>

Kind Regards,

Gyan

On Sun, Dec 15, 2019 at 2:06 AM Gyan Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Hi Wang

I have a question regarding the PSP, USP and USD sections I pasted below.

I just sent an email to Spring WG related to PSP and technically why that is necessary as that is a legacy concept that has parity to MPLS but is not used today due to QOS issues.  Please see that email related to that topic.

In the PSP section can If we have to keep PSP can we add verbiage that states that PSP removal of the SRH header occurs on the Penultimate egress P node.

In the USP section can we also add that all remaining SRH present in the packet are popped on the egress PE ultimate node.

In looking at these 3 SID functions the PSP and USP pop the EH and the USP removes the 6in6 encapsulation so that the other end.x dt4 dt6 etc can pop the services L3vpn headers.

Why can’t the USD 6in6 encapsulation removal be done on with the USP SID?

Why does the USP and USD SID have to be separate?

4.16.1<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.1>.  PSP: Penultimate Segment Pop of the SRH

   The SRH processing of the End, End.X and End.T behaviors are

   modified: after the instruction "S14.  Update IPv6 DA with Segment

   List[Segments Left]" is executed, the following instructions must be

   executed as well:

   S14.1.   If (updated SL == 0) {

   S14.2.      Pop the SRH

   S14.3.   }

4.16.2<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.2>.  USP: Ultimate Segment Pop of the SRH

   The SRH processing of the End, End.X and End.T behaviors are

   modified: the instructions S02-S04 are substituted by the following

   ones:

   S02.   If (Segments Left == 0) {

   S03.       Pop the SRH

   S04.   }

4.16.3<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.3>.  USD: Ultimate Segment Decapsulation

   The SRH processing of the End, End.X and End.T behaviors are

   modified: the instructions S02-S04 are substituted by the following

   ones:

   S02.   If (Segments Left == 0) {

   S03.      Skip the SRH processing and proceed to the next header

   S04.   }

   Further on, the Upper-layer header processing of the End, End.X and

   End.T behaviors are modified as follows:

Kind regards,

Gyan

On Sat, Dec 14, 2019 at 9:08 PM Wang, Weibin (NSB - CN/Shanghai) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pablo:

After the 2 context assumption in previous version of this draft,  “we assume that there is no other extension header than the SRH.”  and  “We assume
   that the SRH may be present multiple times inside each packet”, are removed in this last draft, I feel a bit confusion on USD SID, as well as combination of USD & USP.

First, within the content of this last draft, the word “Further on” marked red in the following pseudocode in section “4.16.3” is hard to understand if the packet being processed has other EH embed between SRH and Upper-layer header, such as AH or other EH, then the processing control of this packet will be passed to normal IPv6 module from current SRH processing module in SR-Node, so my question is : Can its control after completing AH processing (for example)  be back to SRH module (or call it pseudocode module) to proceed the next header like “upper-lay header type ==41 or 4”.
Or, if not, Did you created a new EH processing protocol stack instance in parallel to normal IPv6 module within the scope of SRH processing in SR-node.

4.16.3.  USD: Ultimate Segment Decapsulation

S02.   If (Segments Left == 0) {
   S03.      Skip the SRH processing and proceed to the next header
   S04.   }

Further on, the Upper-layer header processing of the End, End.X and
   End.T behaviors are modified as follows:

   End:
   S01. If (Upper-layer Header type == 41 || 4) {
   S02.    Remove the outer IPv6 Header with all its extension headers
   S03.    Submit the packet to the egress IP FIB lookup and
              transmission to the new destination
   S04. } Else {
   S05.    Send an ICMP Parameter Problem message to the Source Address
              Code 4 (SR Upper-layer Header Error),
              Pointer set to the offset of the upper-layer header.
              Interrupt packet processing and discard the packet.

   S06. }

From my understanding, the all processing action about specific SID must be completed successively. That is to say, upon USD, the upper-layer header (type 41 or 4) must be followed the SRH header being processed currently, or second SRH following the same rule (of course, the draft not considering 2 or more successive SRHs).

Second, the mixed SIDs function with combination of USD and USP (even PSP&USD&USP), I think, it is easy to understand when the two assumption above exist, but now I think it isn’t clear if you only provide the following sentence in this draft, i.e.  “if … else…” statement:
“An implementation that supports the USD flavor in conjunction with
   the USP flavor MAY optimize the packet processing by first looking
   whether the conditions for the USD flavor are met, in which case it
   can proceed with USD processing else do USP processing.”
This confusion is also described in my another mail. Of course, if the first question is addressed then this confusion does not exist.

By the way, is it really no different in text description before and after the two context assumption above removed?

Cheers !

WANG Weibin
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>

--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 19 Dec 2019 16:28:06 +0000

Pablo,

In L3VPN, all of these are combined into a single 20-bit MPLS label. Why can SRv6 not do likewise?

                                             Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, December 19, 2019 6:47 AM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: [email-masked]; Voyer, Daniel <[email-masked]>
Subject: [spring] End.DT/End.DX SIDs (was Re: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt)

Gyan,

Cheers,
Pablo.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 15 December 2019 at 08:29
To: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]<mailto:[email-masked]>>
Cc: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "Voyer, Daniel" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt

Had another question?

I noticed this difference below that the dx4 dt4 account for the global table scenario where the PE-CE is native IPv4 or IPv6.  In the MPLS world that use case is very different in that there is not any L3 vpn label and do the label stack only had a single topmost label.  Also in the MPLS scenario with IPv6 global table PE-CE with a IPv4 core you require BGP -LU labeled unicast "send label" to label all the IPv6 prefixed tunneled over IPv4.   Since that scenario is very different with global table does it make sense to have a separate End.x variant for global table for both IPv4 and IPv6.

     4.4<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.4__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JAaJnI7_$>.  End.DX6: Decapsulation and IPv6 cross-connect . . . . . .  12<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-12__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JH8Abwf7$>

     4.5<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.5__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JEh8sRB2$>.  End.DX4: Decapsulation and IPv4 cross-connect . . . . . .  13<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-13__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JHAg09NC$>

     4.6<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.6__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JHVgWtPg$>.  End.DT6: Decapsulation and specific IPv6 table lookup . .  14<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-14__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JA89XfKV$>

     4.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.7__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JF59SaCO$>.  End.DT4: Decapsulation and specific IPv4 table lookup . .  15<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-15__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JICjeckL$>

4.8<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.8__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JMbbI6-v$>.  End.DT46: Decapsulation and specific IP table lookup  . .  16<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-16__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JMihsn8k$>

Kind Regards,

Gyan

Why can't the USD 6in6 encapsulation removal be done on with the USP SID?

4.16.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.16.1__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JNXuPqZh$>.  PSP: Penultimate Segment Pop of the SRH

   executed as well:

   S14.2.      Pop the SRH

   S14.3.   }

4.16.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.16.2__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JLGcpaqu$>.  USP: Ultimate Segment Pop of the SRH

   ones:

   S03.       Pop the SRH

   S04.   }

4.16.3<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.16.3__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JKFZ-dKZ$>.  USD: Ultimate Segment Decapsulation

   ones:

   S04.   }

Kind regards,

Gyan

After the 2 context assumption in previous version of this draft,  "we assume that there is no other extension header than the SRH."  and  "We assume
   that the SRH may be present multiple times inside each packet", are removed in this last draft, I feel a bit confusion on USD SID, as well as combination of USD & USP.

First, within the content of this last draft, the word "Further on" marked red in the following pseudocode in section "4.16.3" is hard to understand if the packet being processed has other EH embed between SRH and Upper-layer header, such as AH or other EH, then the processing control of this packet will be passed to normal IPv6 module from current SRH processing module in SR-Node, so my question is : Can its control after completing AH processing (for example)  be back to SRH module (or call it pseudocode module) to proceed the next header like "upper-lay header type ==41 or 4".
Or, if not, Did you created a new EH processing protocol stack instance in parallel to normal IPv6 module within the scope of SRH processing in SR-node.

   End:

   S06. }

>From my understanding, the all processing action about specific SID must be completed successively. That is to say, upon USD, the upper-layer header (type 41 or 4) must be followed the SRH header be…

Second, the mixed SIDs function with combination of USD and USP (even PSP&USD&USP), I think, it is easy to understand when the two assumption above exist, but now I think it isn't clear if you only provide the following sentence in this draft, i.e.  "if ... else..." statement:
"An implementation that supports the USD flavor in conjunction with
   the USP flavor MAY optimize the packet processing by first looking
   whether the conditions for the USD flavor are met, in which case it
   can proceed with USD processing else do USP processing."
This confusion is also described in my another mail. Of course, if the first question is addressed then this confusion does not exist.

Cheers !

WANG Weibin
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JI97MuU_$>
--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JI36IPfx$>

www.linkedin.com/in/networking-technologies-consultant<https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JI36IPfx$>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Dec 2019 17:12:12 -0500

> I believe that they cannot be combined.

   I was proposing if possible to combine End.DX4 with End.DT4 and End.DX6
with End.DT6.

Also noticed that dx4 and dx6 also have global table IPv4 IPv6 PE-CE
scenario where there is not any vpn label signaled.  The L3 vpn service sid
is signaled only for tenant VRF vpnv4 vpnv6.  Since global does not have
vpn service label how would that work.

I think you would have to create a separate End.x variant for global v4 v6.

For the end.dt46  I am not sure why you would have a combined 46 sid as v4
and v6 would have their separate edge PE-CE peering and the other separate
end. dx4 dx6 dt4 dt6 should accommodate.  The only think I am guessing is a
Recent update on BESS WG regarding sending IPv4 prefixes with IPv6 NLRI.
In that scenario you would just have a PE-CE v6 peer only and that would
fall under dx6 dt6.  So even then I don’t think this dt64 is necessary.

>
> Cheers,
>
> Pablo.
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Sunday, 15 December 2019 at 08:29
> *To: *"Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
> *Cc: *"Pablo Camarillo (pcamaril)" <[email-masked]>, "Voyer, Daniel" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [spring] USD/USP question in
> draft-ietf-spring-srv6-network-programming-06.txt
>
>
>
>
>
> These 4 sections.  Trying to understand the difference between end.dx4
> end.dx6 and end.dt4 and end.dt6.  They both seem very similar.  One says
> xconnect but other has v4 v6 lookup but for both you have to signal  L3 vpn
> services sid.  Not sure why both SIDs dx dt Sid function why they cannot be
> combined.
>
>
>
> I noticed this difference below that the dx4 dt4 account for the global
> table scenario where the PE-CE is native IPv4 or IPv6.  In the MPLS world
> that use case is very different in that there is not any L3 vpn label and
> do the label stack only had a single topmost label.  Also in the MPLS
> scenario with IPv6 global table PE-CE with a IPv4 core you require BGP -LU
> labeled unicast “send label” to label all the IPv6 prefixed tunneled over
> IPv4.   Since that scenario is very different with global table does it
> make sense to have a separate End.x variant for global table for both IPv4
> and IPv6.
>
>
>
>      4.4 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.4>.  End.DX6: Decapsulation and IPv6 cross-connect . . . . . .  12 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-12>
>
>      4.5 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.5>.  End.DX4: Decapsulation and IPv4 cross-connect . . . . . .  13 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-13>
>
>      4.6 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.6>.  End.DT6: Decapsulation and specific IPv6 table lookup . .  14 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-14>
>
>      4.7 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.7>.  End.DT4: Decapsulation and specific IPv4 table lookup . .  15 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-15>
>
>
>
> 4.8 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.8>.  End.DT46: Decapsulation and specific IP table lookup  . .  16 <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#page-16>
>
>
>
>
>
> Kind Regards,
>
>
>
> Gyan
>
>
>
> On Sun, Dec 15, 2019 at 2:06 AM Gyan Mishra <[email-masked]> wrote:
>
> Hi Wang
>
>
>
> I just sent an email to Spring WG related to PSP and technically why that
> is necessary as that is a legacy concept that has parity to MPLS but is not
> used today due to QOS issues.  Please see that email related to that topic.
>
>
>
>
>
> In the PSP section can If we have to keep PSP can we add verbiage that
> states that PSP removal of the SRH header occurs on the Penultimate egress
> P node.
>
>
>
> In the USP section can we also add that all remaining SRH present in the
> packet are popped on the egress PE ultimate node.
>
>
>
> In looking at these 3 SID functions the PSP and USP pop the EH and the USP
> removes the 6in6 encapsulation so that the other end.x dt4 dt6 etc can pop
> the services L3vpn headers.
>
>
>
> 4.16.1
> <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.1>.
> PSP: Penultimate Segment Pop of the SRH
>
>
>
>
>
> 4.16.2
> <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.2>.
> USP: Ultimate Segment Pop of the SRH
>
>
>
>
>
> 4.16.3
> <https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05#section-4.16.3>.
> USD: Ultimate Segment Decapsulation
>
>
>
>
>
> On Sat, Dec 14, 2019 at 9:08 PM Wang, Weibin (NSB - CN/Shanghai) <
> [email-masked]> wrote:
>
> Hi Pablo:
>
>
>
> After the 2 context assumption in previous version of this draft,  “we
> assume that there is no other extension header than the SRH.”  and  “We
> assume
>
>    that the SRH may be present multiple times inside each packet”, are
> removed in this last draft, I feel a bit confusion on USD SID, as well as
> combination of USD & USP.
>
>
>
> First, within the content of this last draft, the word “Further on” marked
> red in the following pseudocode in section “4.16.3” is hard to understand
> if the packet being processed has other EH embed between SRH and
> Upper-layer header, such as AH or other EH, then the processing control of
> this packet will be passed to normal IPv6 module from current SRH
> processing module in SR-Node, so my question is : Can its control after
> completing AH processing (for example)  be back to SRH module (or call it
> pseudocode module) to proceed the next header like “upper-lay header type
> ==41 or 4”.
>
> Or, if not, Did you created a new EH processing protocol stack instance in
> parallel to normal IPv6 module within the scope of SRH processing in
> SR-node.
>
>
>
> From my understanding, the all processing action about specific SID must
> be completed successively. That is to say, upon USD, the upper-layer header
> (type 41 or 4) must be followed the SRH header being processed currently,
> or second SRH following the same rule (of course, the draft not considering
> 2 or more successive SRHs).
>
>
>
> Second, the mixed SIDs function with combination of USD and USP (even
> PSP&USD&USP), I think, it is easy to understand when the two assumption
> above exist, but now I think it isn’t clear if you only provide the
> following sentence in this draft, i.e.  “if … else…” statement:
>
> This confusion is also described in my another mail. Of course, if the
> first question is addressed then this confusion does not exist.
>
>
>
> By the way, is it really no different in text description before and after
> the two context assumption above removed?
>
>
>
>
>
> *Cheers !*
>
>
>
> *WANG Weibin*
>
> [email-masked]
> 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> Email: [email-masked]
>
> www.linkedin.com/in/networking-technologies-consultant
>
>
>
> --
>
> Gyan S. Mishra
>
> 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> FDC1 3rd Floor
>
> Silver Spring, MD 20904
>
> United States
>
> Phone: 301 502-1347
>
> Email: [email-masked]
>
> www.linkedin.com/in/networking-technologies-consultant
>
>
>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Dec 2019 17:51:08 -0500

On Thu, Dec 19, 2019 at 11:28 AM Ron Bonica <[email-masked]> wrote:

>  [Gyan] Very good point.  All of those are related to BOS=1 vpn service
> label.  This is covered with BESS in detail in the L3 vpn service SID.
>
https://tools.ietf.org/pdf/draft-ietf-bess-srv6-services-01.pdf
> SRv6 programming is related to the end.x cross connects within the SR
> domain similar to in MPLS terms “topmost label”.  So the external to SRv6
> domain,  PE-CE M-BGP BGP services is really separate covered by the draft
> above.
>

> *From:* spring <[email-masked]> *On Behalf Of *Pablo Camarillo
> (pcamaril)
> *Sent:* Thursday, December 19, 2019 6:47 AM
> *To:* Wang, Weibin (NSB - CN/Shanghai) <[email-masked]>;
> Gyan Mishra <[email-masked]>
> *Cc:* [email-masked]; Voyer, Daniel <[email-masked]>
> *Subject:* [spring] End.DT/End.DX SIDs (was Re: USD/USP question in
> draft-ietf-spring-srv6-network-programming-06.txt)
>
>
>
> Gyan,
>
>
>
>      4.4 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.4__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JAaJnI7_$>.  End.DX6: Decapsulation and IPv6 cross-connect . . . . . .  12 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-12__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JH8Abwf7$>
>
>      4.5 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.5__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JEh8sRB2$>.  End.DX4: Decapsulation and IPv4 cross-connect . . . . . .  13 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-13__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JHAg09NC$>
>
>      4.6 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.6__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JHVgWtPg$>.  End.DT6: Decapsulation and specific IPv6 table lookup . .  14 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-14__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JA89XfKV$>
>
>      4.7 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.7__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JF59SaCO$>.  End.DT4: Decapsulation and specific IPv4 table lookup . .  15 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-15__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JICjeckL$>
>
>
>
> 4.8 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.8__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JMbbI6-v$>.  End.DT46: Decapsulation and specific IP table lookup  . .  16 <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*page-16__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JMihsn8k$>
>
>
>
>
>
> Kind Regards,
>
>
>
> Gyan
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.16.1__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JNXuPqZh$>.
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.16.2__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JLGcpaqu$>.
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05*section-4.16.3__;Iw!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JKFZ-dKZ$>.
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JI97MuU_$>
>
> --
>
> Gyan S. Mishra
>
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JI36IPfx$>
>
>
>
> --
>
> Gyan S. Mishra
>
> <https://urldefense.com/v3/__http:/www.linkedin.com/in/networking-technologies-consultant__;!!NEt6yMaO-gk!QzHlcRglDrowIq4p7kbUU8tNwsbwrneoRiLDYAClyLIXp1ZLWOSxDhU6JI36IPfx$>
>
>
>
-- 

Gyan S. Mishra

Silver Spring, MD 20904

United States

Phone: 301 502-1347

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 20 Dec 2019 17:31:09 +0000

Ron, Gyan,

Sections 4.4 to 4.8 of draft-ietf-spring-srv6-network-programming define the local dataplane processing on the egress PE.

As far as L3VPN signaling is concerned [draft-ietf-bess-srv6-services], the egress PE signals opaque behavior for the SID, so it is transparent to the control plane. Whether the egress PE is doing End.DX or End.DT is transparent to the ingress PE.

Happy holidays,
Pablo.

From: Ron Bonica <[email-masked]>
Date: Thursday, 19 December 2019 at 17:29
To: "Pablo Camarillo (pcamaril)" <[email-masked]>, "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>, Gyan Mishra <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Voyer, Daniel" <[email-masked]>
Subject: RE: [spring] End.DT/End.DX SIDs (was Re: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt)

Pablo,

                                             Ron

Gyan,

Cheers,
Pablo.

Had another question?

Kind Regards,

Gyan

   executed as well:

   S14.2.      Pop the SRH

   S14.3.   }

   ones:

   S03.       Pop the SRH

   S04.   }

   ones:

   S04.   }

Kind regards,

Gyan

   End:

   S06. }

Cheers !

WANG Weibin

---

From: Ron Bonica <[email-masked]>
Date: Sun, 29 Dec 2019 17:37:56 +0000

Camillo,

I may be misunderstanding something. Do the numeric constants defined in Section 9.2.1 of draft-ietf-spring-srv6-network programming appear in SIDs?

For example, assume that a node advertises the locator 2001:db8:0:1::/64. Can we assume that all END.DX6 SIDs instantiated on that node will be drawn from  2001:db8:0:1:10::/80?

                                           Ron

Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <[email-masked]>
Sent: Friday, December 20, 2019 12:31 PM
To: [email-masked]; [email-masked]; Ron Bonica <[email-masked]>
Cc: [email-masked]; Voyer, Daniel <[email-masked]>
Subject: Re: [spring] End.DT/End.DX SIDs (was Re: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt)

Ron, Gyan,

Happy holidays,
Pablo.

From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 19 December 2019 at 17:29
To: "Pablo Camarillo (pcamaril)" <[email-masked]<mailto:[email-masked]>>, "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]<mailto:[email-masked]>>, Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Voyer, Daniel" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] End.DT/End.DX SIDs (was Re: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt)

Pablo,

                                             Ron

Juniper Business Use Only
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Thursday, December 19, 2019 6:47 AM
To: Wang, Weibin (NSB - CN/Shanghai) <[email-masked]<mailto:[email-masked]>>; Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Voyer, Daniel <[email-masked]<mailto:[email-masked]>>
Subject: [spring] End.DT/End.DX SIDs (was Re: USD/USP question in draft-ietf-spring-srv6-network-programming-06.txt)

Gyan,

Cheers,
Pablo.

Had another question?

Kind Regards,

Gyan

   executed as well:

   S14.2.      Pop the SRH

   S14.3.   }

   ones:

   S03.       Pop the SRH

   S04.   }

   ones:

   S04.   }

Kind regards,

Gyan

   End:

   S06. }

Cheers !

WANG Weibin