Re: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

[Mark Smith]

On Thu, 12 Sep 2019, 00:56 Ron Bonica, 
wrote:

> Pablo,
>
>
>
> So, to make uSID work:
>
>
>
>- You have to get a large block (e.g., /32) from your RIR
>- You have to allocate a smaller block (e.g., /48)  to each router for
>uSIDs
>- You can’t use more specifics from that block for anything else
>(e.g., numbering interfaces)
>- If you do, you may cause multiple SR paths to black hole
>
>
+ Ignore the subnet ID field definition - RFC 3587.

+ Ignore the IID field definition - RFC 4291.

+ Ensure your combined set of uSID values in the IID field don't end up
being any of the reserved IID values - RFC 5453.


I realised quite a while ago to overcome some early Ethernet MTU issues
with MPLS, by, on a point to point Ethernet link, switching each end into
promiscuous mode and then putting MPLS labels in the 12 octets of the now
unused address fields. It should work although it is being non-obvious, and
may cause unexpected problems. For example, switching on the "multicast
bit" in the source address field actually says there is a Token Ring Route
Information Field after the Ethernet header.

Possibly useful hack, but not something I'd do by choice. Encoding uSIDs in
IPv6 addresses is similar and could possibly cause more problems, because
the domain or scope of transmission is much greater than a single
point-to-point link.


Regards,
Mark.




>-
>
>
>
> Do I have this right?
>
>
>
>Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Pablo Camarillo (pcamaril) 
> *Sent:* Tuesday, September 10, 2019 10:12 AM
> *To:* Ron Bonica ; SPRING WG 
> *Subject:* Re: [spring]
> draft-filsfils-spring-net-pgm-extension-srv6-usid-01
>
>
>
> Ron,
>
>
>
> SRv6 is based on IPv6 longest prefix match forwarding. You can shoot
> yourself in the foot by adding bad routes.
>
>
>
> Cheers,
>
> Pablo.
>
>
>
> *From: *spring  on behalf of Ron Bonica <
> rbonica=40juniper@dmarc.ietf.org>
> *Date: *Tuesday, 6 August 2019 at 22:46
> *To: *SPRING WG 
> *Subject: *[spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01
>
>
>
> Authors,
>
>
>
> Referring to the example in Section 5.2 of
> draft-filsfils-spring-net-pgm-extension-srv6-usid-01, what would happen if
> Node 7 instantiated the following:
>
>
>
> -  A uSID  identified by 2001:db8:0700/48
>
> -  A more specific route (e.g.., 2001:db8:0700::/49)
>
>
>
> Would the more specific route be ignored by the longest path lookup on
> Node 7? If not, would the more specific route cause all SR Paths whose
> penultimate segment is 2001:db8:0700/48 to black hole?
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Xiejingrong]

+1
I think the need to ‘walk through the EH chain’ in fast-path is difficult, for 
the last 2 decades, and will for the near future I guess.
The SRv6 is very careful not to ‘walk through the EH chain’.
Instead it just ‘handle the least leading header(s)’, with a preceding ‘FIB 
lookup’ indication, and ‘FIB lookup’ is a step that will need to do in chip 
anyway for any packet.
This makes SRv6 deployable in chips for the first time of EH invention by ISO 
and later by IPv6.
This makes SRv6 the paradigm of handling any EH in chips In my opinion.

One can check my understand on page 11 to 14 of the slides I prepared in 
ietf105 (though got no time slot to present):
https://datatracker.ietf.org/meeting/105/materials/slides-105-bier-bier-ipv6-encapsulation-00.pdf

DOH has it benefits, and is recommended in 8200, but the mix of many different 
EHs and different Option TLVs for a solution is obviously complex in data-plane.
Using a single EH to the best, with the appropriate preceding indication, is 
simple, ordered, friendly to chip, direct, perfect.
https://mailarchive.ietf.org/arch/msg/ipv6/SgkSGtSBmB4G51ajnBp3UbjJl8I

Thanks
Jingrong

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Bernier, Daniel
Sent: Thursday, September 12, 2019 11:41 AM
To: xie...@chinatelecom.cn; List 
Cc: Rob Shakir ; 6man <6...@ietf.org>; Tarek Saad 
; Robert Raszuk 
Subject: Re: [spring] Beyond SRv6.


+1



The ability of using a single SRH to convey behaviour information wether they 
are per-segment or per-path has proven to be very simple and quick to define in 
various data plane targets.



At first analysis, trying to replicate with CRH + DOH variants, the logic 
required for service programs is more com​plex.



What happens if I need TLVs mid-point in a path but not at its end (e.g. 
referring to the Ole's ACME analogy) ? Would they now be defined in a 
seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested 
midpoint devices will have to lookup beyond the TLVs to get to CRH for next 
segment ?



Similar question would be on how would we implement proxy behaviours either 
dynamic or static ? If I read 
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly, we then 
need NSH for richer service chains constructs (think Gi-LAN). This means I need 
CRH, some variants of DOH + NSH​.



I fail to see the simplicity there.



Dan B


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of xie...@chinatelecom.cn 
mailto:xie...@chinatelecom.cn>>
Sent: Wednesday, September 11, 2019 8:57 PM
To: List
Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk
Subject: [EXT]Re: [spring] Beyond SRv6.


Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for 
the bearing and interconnection of video platforms which are  located in 
different cities, service agilities,secure sepertion, traffic steering and 
other features of SRv6 have been demonstrated in this trial. Based on this, 
SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to 
reduce the the overhead of long SID in the long term, but it is better to be 
compatible withe SRH, instead of designing a complete new one. CRH is a 
complete new design, it move the complexities from SRH to DOH.
Moreover, I hope more efforts of SRv6 should be given on how to support new 
services,for instance, Application-aware network (APN). Meanwhile, we should 
consider more on how to implmement smooth transition and protect the network 
assetof carriers.

Best regards
Chongfeng


From: Dirk Steinberg
Date: 2019-09-09 21:31
To: Gyan Mishra
CC: SPRING WG List; 
6...@ietf.org; Robert Raszuk; 
Rob Shakir; Tarek Saad
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:

- Remote LFA tunnel is not used with SR, only TI-LFA which
  only operates on the node that is the PLR (point of local repair).

- Any encapsulation on the ingress PE with or without EH has nothing
  to do with TI-LFA except for the special case where the ingress PE
  itself is the PLR.

- TI-LFA is not an IGP extension and does not require one.
  It is a purely local computation based on IGP topology.

- The PLR for TI-LFA may need to insert some SIDs into the SID
  list to steer the packet around the failure. For the LFA base case
  no SIDs are needed at all. If SID insertion is needed, the PLR
  will push the required number of labels in the MPLS case.

  For SRv6, the equivalent operation to the label push is to
  insert an EH with the required SID list. The packet will already
  have been encapsulated on the ingress PE and in the most
  common Internet or VPN base use case it will not even have
  

Re: [spring] Beyond SRv6.

[Tom Herbert]

On Wed, Sep 11, 2019 at 5:58 PM xie...@chinatelecom.cn
 wrote:
>
>
> Hi, folks,
> Last year China Telecom begun to implement SRv6 trial in Sichun province for 
> the bearing and interconnection of video platforms which are  located in 
> different cities, service agilities,secure sepertion, traffic steering and 
> other features of SRv6 have been demonstrated in this trial. Based on this, 
> SRv6 will be implementated in larger-scale in CT.
> No technologies is 100% perfect,I agree that compression mechanism is needed 
> to reduce the the overhead of long SID in the long term, but it is better to 
> be compatible withe SRH, instead of designing a complete new one. CRH is a 
> complete new design, it move the complexities from SRH to DOH.
> Moreover, I hope more efforts of SRv6 should be given on how to support new 
> services,for instance, Application-aware network (APN). Meanwhile, we should 
> consider more on how to implmement smooth transition and protect the network 
> assetof carriers.
>
Chongfeng,

That presumes that SRv6 is a least common denominator in networks and
indispensable core functionality. It's not. As already pointed there
are existing alternatives that might be operative for adding services
like APN. SRv6 is one manifestation, but not the only one-- there's
NSH, SR-MPLS, other encapsulations, etc. From this POV, SRv6+, and
even SRv6, is just another mechanism. Naturally, we want solutions
that work across the broadest number of cases possible. So the
question is: what are the common functionalities that could work
across these different methods. In IPv6, it's DOH and HBH options that
are common across all forms of routing header and packets. So, IMO,
those should be considered first before investing in narrower
solutions (i.e. TLVs is the routing header). There is a similar
argument in security that AH should have been considered before
creating a point solution in the HMAC of SRv6.

Tom

> Best regards
> Chongfeng
>
>
> From: Dirk Steinberg
> Date: 2019-09-09 21:31
> To: Gyan Mishra
> CC: SPRING WG List; 6...@ietf.org; Robert Raszuk; Rob Shakir; Tarek Saad
> Subject: Re: [spring] Beyond SRv6.
> There seems to be some confusion regarding TI-LFA.
> A couple of comments:
>
> - Remote LFA tunnel is not used with SR, only TI-LFA which
>   only operates on the node that is the PLR (point of local repair).
>
> - Any encapsulation on the ingress PE with or without EH has nothing
>   to do with TI-LFA except for the special case where the ingress PE
>   itself is the PLR.
>
> - TI-LFA is not an IGP extension and does not require one.
>   It is a purely local computation based on IGP topology.
>
> - The PLR for TI-LFA may need to insert some SIDs into the SID
>   list to steer the packet around the failure. For the LFA base case
>   no SIDs are needed at all. If SID insertion is needed, the PLR
>   will push the required number of labels in the MPLS case.
>
>   For SRv6, the equivalent operation to the label push is to
>   insert an EH with the required SID list. The packet will already
>   have been encapsulated on the ingress PE and in the most
>   common Internet or VPN base use case it will not even have
>   an EH so that this EH insertion will result only in a single EH.
>
>   Alternatively, the PLR could also be configured to perform
>   encapsulation with a new IPv6 header using the repair SID
>   as IPv6 destination address, without needing any EH.
>   This will work for the vast majority of cases.
>   Remember that one 128-bit SID in SRv6 is in most cases
>   equivalent to 2 MPLS labels, i.e. a node label plus an
>   adjacency SID can be encoded in a single SRv6 SID.
>
>   Only in extreme cases would the PLR need to add an
>   EH to the new IPv6 header with more SIDs.
>
> - EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.
>
> Hope it helps.
>
> Cheers
> Dirk
>
> Am 08.09.2019 um 09:19 schrieb Gyan Mishra :
>
> From reading through all the discussion threads the SR insertion is two fold 
> one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up 
> requiring double EH insertions on the Ingress PE tunnel head end SRv6 source 
> node and then second scenario being a possible EH insertions occurrence on 
> intermediate nodes.  I have not read through the drafts or RFC regarding 
> Ti-LFA with SR but since that is an IGP extension I am guessing an opaque LSA 
> and is not the traditional MPLS FRR link/node/path protection that adds an 
> additional mpls shim so not sure why an EH insertion needs to occur for 
> Ti-LFA.  Can someone clarify that use case for me.  Also the EH insertion on 
> intermediate node what is the use case or reason for that.  My guess is it’s 
> for special use case of stitching SRv6 domains together.  Please clarify..
>
>
> 
> IETF IPv6 working group mailing list
> i...@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 

Re: [spring] Beyond SRv6.

[xie...@chinatelecom.cn]

Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for 
the bearing and interconnection of video platforms which are  located in 
different cities, service agilities,secure sepertion, traffic steering and 
other features of SRv6 have been demonstrated in this trial. Based on this, 
SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to 
reduce the the overhead of long SID in the long term, but it is better to be 
compatible withe SRH, instead of designing a complete new one. CRH is a 
complete new design, it move the complexities from SRH to DOH. 
Moreover, I hope more efforts of SRv6 should be given on how to support new 
services,for instance, Application-aware network (APN). Meanwhile, we should 
consider more on how to implmement smooth transition and protect the network 
assetof carriers.

Best regards
Chongfeng

 
From: Dirk Steinberg
Date: 2019-09-09 21:31
To: Gyan Mishra
CC: SPRING WG List; 6...@ietf.org; Robert Raszuk; Rob Shakir; Tarek Saad
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:

- Remote LFA tunnel is not used with SR, only TI-LFA which 
  only operates on the node that is the PLR (point of local repair).

- Any encapsulation on the ingress PE with or without EH has nothing 
  to do with TI-LFA except for the special case where the ingress PE
  itself is the PLR.

- TI-LFA is not an IGP extension and does not require one. 
  It is a purely local computation based on IGP topology.

- The PLR for TI-LFA may need to insert some SIDs into the SID
  list to steer the packet around the failure. For the LFA base case
  no SIDs are needed at all. If SID insertion is needed, the PLR 
  will push the required number of labels in the MPLS case. 

  For SRv6, the equivalent operation to the label push is to 
  insert an EH with the required SID list. The packet will already 
  have been encapsulated on the ingress PE and in the most 
  common Internet or VPN base use case it will not even have 
  an EH so that this EH insertion will result only in a single EH.

  Alternatively, the PLR could also be configured to perform
  encapsulation with a new IPv6 header using the repair SID
  as IPv6 destination address, without needing any EH.
  This will work for the vast majority of cases. 
  Remember that one 128-bit SID in SRv6 is in most cases
  equivalent to 2 MPLS labels, i.e. a node label plus an
  adjacency SID can be encoded in a single SRv6 SID.

  Only in extreme cases would the PLR need to add an 
  EH to the new IPv6 header with more SIDs.

- EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.

Hope it helps.

Cheers
Dirk

Am 08.09.2019 um 09:19 schrieb Gyan Mishra :

From reading through all the discussion threads the SR insertion is two fold 
one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up 
requiring double EH insertions on the Ingress PE tunnel head end SRv6 source 
node and then second scenario being a possible EH insertions occurrence on 
intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA 
with SR but since that is an IGP extension I am guessing an opaque LSA and is 
not the traditional MPLS FRR link/node/path protection that adds an additional 
mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can 
someone clarify that use case for me.  Also the EH insertion on intermediate 
node what is the use case or reason for that.  My guess is it’s for special use 
case of stitching SRv6 domains together.  Please clarify..


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Beyond SRv6.

[Bernier, Daniel]

+1


The ability of using a single SRH to convey behaviour information wether they 
are per-segment or per-path has proven to be very simple and quick to define in 
various data plane targets.


At first analysis, trying to replicate with CRH + DOH variants, the logic 
required for service programs is more com​plex.


What happens if I need TLVs mid-point in a path but not at its end (e.g. 
referring to the Ole's ACME analogy) ? Would they now be defined in a 
seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested 
midpoint devices will have to lookup beyond the TLVs to get to CRH for next 
segment ?


Similar question would be on how would we implement proxy behaviours either 
dynamic or static ? If I read 
https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly, we then 
need NSH for richer service chains constructs (think Gi-LAN). This means I need 
CRH, some variants of DOH + NSH​.


I fail to see the simplicity there.


Dan B


From: spring  on behalf of xie...@chinatelecom.cn 

Sent: Wednesday, September 11, 2019 8:57 PM
To: List
Cc: Rob Shakir; 6man; Tarek Saad; Robert Raszuk
Subject: [EXT]Re: [spring] Beyond SRv6.


Hi, folks,
Last year China Telecom begun to implement SRv6 trial in Sichun province for 
the bearing and interconnection of video platforms which are  located in 
different cities, service agilities,secure sepertion, traffic steering and 
other features of SRv6 have been demonstrated in this trial. Based on this, 
SRv6 will be implementated in larger-scale in CT.
No technologies is 100% perfect,I agree that compression mechanism is needed to 
reduce the the overhead of long SID in the long term, but it is better to be 
compatible withe SRH, instead of designing a complete new one. CRH is a 
complete new design, it move the complexities from SRH to DOH.
Moreover, I hope more efforts of SRv6 should be given on how to support new 
services,for instance, Application-aware network (APN). Meanwhile, we should 
consider more on how to implmement smooth transition and protect the network 
assetof carriers.

Best regards
Chongfeng


From: Dirk Steinberg
Date: 2019-09-09 21:31
To: Gyan Mishra
CC: SPRING WG List; 
6...@ietf.org; Robert Raszuk; 
Rob Shakir; Tarek Saad
Subject: Re: [spring] Beyond SRv6.
There seems to be some confusion regarding TI-LFA.
A couple of comments:

- Remote LFA tunnel is not used with SR, only TI-LFA which
  only operates on the node that is the PLR (point of local repair).

- Any encapsulation on the ingress PE with or without EH has nothing
  to do with TI-LFA except for the special case where the ingress PE
  itself is the PLR.

- TI-LFA is not an IGP extension and does not require one.
  It is a purely local computation based on IGP topology.

- The PLR for TI-LFA may need to insert some SIDs into the SID
  list to steer the packet around the failure. For the LFA base case
  no SIDs are needed at all. If SID insertion is needed, the PLR
  will push the required number of labels in the MPLS case.

  For SRv6, the equivalent operation to the label push is to
  insert an EH with the required SID list. The packet will already
  have been encapsulated on the ingress PE and in the most
  common Internet or VPN base use case it will not even have
  an EH so that this EH insertion will result only in a single EH.

  Alternatively, the PLR could also be configured to perform
  encapsulation with a new IPv6 header using the repair SID
  as IPv6 destination address, without needing any EH.
  This will work for the vast majority of cases.
  Remember that one 128-bit SID in SRv6 is in most cases
  equivalent to 2 MPLS labels, i.e. a node label plus an
  adjacency SID can be encoded in a single SRv6 SID.

  Only in extreme cases would the PLR need to add an
  EH to the new IPv6 header with more SIDs.

- EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.

Hope it helps.

Cheers
Dirk

Am 08.09.2019 um 09:19 schrieb Gyan Mishra 
mailto:hayabusa...@gmail.com>>:

From reading through all the discussion threads the SR insertion is two fold 
one being for FRR capabilities using Ti-LFA or remote LFA tunnel so end up 
requiring double EH insertions on the Ingress PE tunnel head end SRv6 source 
node and then second scenario being a possible EH insertions occurrence on 
intermediate nodes.  I have not read through the drafts or RFC regarding Ti-LFA 
with SR but since that is an IGP extension I am guessing an opaque LSA and is 
not the traditional MPLS FRR link/node/path protection that adds an additional 
mpls shim so not sure why an EH insertion needs to occur for Ti-LFA.  Can 
someone clarify that use case for me.  Also the EH insertion on intermediate 
node what is the use case or reason for that.  My guess is it’s for 

Re: [spring] Beyond SRv6.

[Mark Smith]

It's simple because IPv6 doesn't look past the fixed IPv6 header to perform
its forwarding, and matches on the Destination Address to determine if to
perform deeper packet host processing.


You're building much more complicated forwarding services if you're going
to be marching on TLVs etc. past the IPv6 fixed header.

However vendors and carrier engineering groups like selling and deploying
new gear, so I suppose that's ok. They don't have to operate it or fix it
when it breaks.

On Thu, 12 Sep 2019, 13:41 Bernier, Daniel,  wrote:

> +1
>
>
> The ability of using a single SRH to convey behaviour information wether
> they are per-segment or per-path has proven to be very simple and quick to
> define in various data plane targets.
>
>
> At first analysis, trying to replicate with CRH + DOH variants, the logic
> required for service programs is more com​plex.
>
>
> What happens if I need TLVs mid-point in a path but not at its end (e.g.
> referring to the Ole's ACME analogy) ? Would they now be defined in a
> seg-end-opt or a vpn-dest-opt ? If seg-end-opt then it means non-interested
> midpoint devices will have to lookup beyond the TLVs to get to CRH for next
> segment ?
>
>
> Similar question would be on how would we implement proxy behaviours
> either dynamic or static ? If I read
> https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-04 correctly,
> we then need NSH for richer service chains constructs (think Gi-LAN). This
> means I need CRH, some variants of DOH + NSH​.
>
>
> I fail to see the simplicity there.
>
>
> Dan B
> --
> *From:* spring  on behalf of
> xie...@chinatelecom.cn 
> *Sent:* Wednesday, September 11, 2019 8:57 PM
> *To:* List
> *Cc:* Rob Shakir; 6man; Tarek Saad; Robert Raszuk
> *Subject:* [EXT]Re: [spring] Beyond SRv6.
>
>
> Hi, folks,
>
> Last year China Telecom begun to implement SRv6 trial in Sichun province for 
> the bearing and interconnection of video platforms which are  located in 
> different cities, service agilities,secure sepertion, traffic steering and 
> other features of SRv6 have been demonstrated in this trial. Based on this, 
> SRv6 will be implementated in larger-scale in CT.
>
> No technologies is 100% perfect,I agree that compression mechanism is needed 
> to reduce the the overhead of long SID in the long term, but it is better to 
> be compatible withe SRH, instead of designing a complete new one. CRH is a 
> complete new design, it move the complexities from SRH to DOH.
> Moreover, I hope more efforts of SRv6 should be given on how to support new 
> services,for instance, Application-aware network
> (APN). Meanwhile, we should consider more on
> how to implmement smooth transition and protect the network assetof carriers.
>
> Best regards
> Chongfeng
>
>
> *From:* Dirk Steinberg 
> *Date:* 2019-09-09 21:31
> *To:* Gyan Mishra 
> *CC:* SPRING WG List ; 6...@ietf.org; Robert Raszuk
> ; Rob Shakir ; Tarek Saad
> 
> *Subject:* Re: [spring] Beyond SRv6.
> There seems to be some confusion regarding TI-LFA.
> A couple of comments:
>
> - Remote LFA tunnel is not used with SR, only TI-LFA which
>   only operates on the node that is the PLR (point of local repair).
>
> - Any encapsulation on the ingress PE with or without EH has nothing
>   to do with TI-LFA except for the special case where the ingress PE
>   itself is the PLR.
>
> - TI-LFA is not an IGP extension and does not require one.
>   It is a purely local computation based on IGP topology.
>
> - The PLR for TI-LFA may need to insert some SIDs into the SID
>   list to steer the packet around the failure. For the LFA base case
>   no SIDs are needed at all. If SID insertion is needed, the PLR
>   will push the required number of labels in the MPLS case.
>
>   For SRv6, the equivalent operation to the label push is to
>   insert an EH with the required SID list. The packet will already
>   have been encapsulated on the ingress PE and in the most
>   common Internet or VPN base use case it will not even have
>   an EH so that this EH insertion will result only in a single EH.
>
>   Alternatively, the PLR could also be configured to perform
>   encapsulation with a new IPv6 header using the repair SID
>   as IPv6 destination address, without needing any EH.
>   This will work for the vast majority of cases.
>   Remember that one 128-bit SID in SRv6 is in most cases
>   equivalent to 2 MPLS labels, i.e. a node label plus an
>   adjacency SID can be encoded in a single SRv6 SID.
>
>   Only in extreme cases would the PLR need to add an
>   EH to the new IPv6 header with more SIDs.
>
> - EH insertion for TI-LFA has nothing to do with stitching SRv6 domains.
>
> Hope it helps.
>
> Cheers
> Dirk
>
> Am 08.09.2019 um 09:19 schrieb Gyan Mishra :
>
> From reading through all the discussion threads the SR insertion is two
> fold one being for FRR capabilities using Ti-LFA or remote LFA tunnel so
> end up requiring double EH insertions on the Ingress PE tunnel head end
> SRv6 source node and 

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Robert Raszuk]

Hi Andrew,

> And yes, as was alluded to, I did raise the possibility of an inter-op
draft to facilitate
> forward movement here, and I had only one vendor out of all the vendors I
approached
> actually indicate opposition to this, so I would ask now directly on
list, can we work
> towards a situation where instead of all blocking each other – work
continues and we
> find a way to play nice, and indeed, inter-operate?

If so many vendors you approached indicated no opposition to work on
interop draft and solution where is it ?

Note that each piece wire or fiber has (at least) two ends. So if the SRv6+
side takes the burden of translation to and from new control plane
extensions of SRv6+ and new data plane encoding SRv6+ and if this is
clearly spelled out in the draft then perhaps you would see much easier or
say different acceptance or resistance level in IETF for SRv6+ ?

If I were to suggest strategy to introduce such proposal like SRv6+ I would
start with that then later focus on number of protocol extensions drafts.

Bottom line is that I seriously doubt that any vendor would support all
three: SR-MPLS, SRv6 & SRv6+ just to make few customers happy. And that is
regardless on the business case. It is just realistically too expensive to
develop and too support.

- - -

And as proposed before not only by myself but others what is functionally
missing if you were to use SR-MPLS with IP encap between segment nodes as
compared to SRv6+ ? If SRv6+ would find a cool and smart way to propose
stateless compression of  IPv6 address into SID it would perhaps had some
value, but it does not. It takes flat 16 or 32 bits and maps it to IPv6 ..
in exactly same way as you map MPLS label based SID to an IP address.

And for those who do not like to see MPLS even at service level they should
stop running L3VPNs over MPLS or over IP too. Note that SRv6+ still
proposes to use MPLS label in PPSI for VPN demux encoding see section 7 of
https://tools.ietf.org/html/draft-ssangli-idr-bgp-vpn-srv6-plus-02#section-7


Thx,
R.

>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Codepoint for OSPFv3 protocol in SPRING LSP-Ping and LSP-Trace

[Aissaoui, Mustapha (Nokia - CA/Ottawa)]

Thank you Ketan.

I believe it would be appropriate to have a separate codepoint for each OSPFv2 
and OSPFv3 protocols. Within OSPFv3 we can distinguish the family IPv4 and IPv6 
based on the prefix of the SID.

Mustapha.

From: Ketan Talaulikar (ketant) 
Sent: Wednesday, September 11, 2019 12:21 AM
To: bruno.decra...@orange.com; Aissaoui, Mustapha (Nokia - CA/Ottawa) 
; m...@ietf.org; 
draft-ietf-mpls-spring-lsp-p...@ietf.org
Cc: spring@ietf.org
Subject: RE: Codepoint for OSPFv3 protocol in SPRING LSP-Ping and LSP-Trace

Hi Mustapha,

The RFC8287 refers to OSPF and not OSPFv2. Conventionally, we use the term OSPF 
when we are referring to both OSPFv2 and OSPFv3. I am not sure if this was the 
authors' objective.

One might assume that OSPFv2 is purely for IPv4 and OSPFv3 for IPv6, but this 
is not true (see RFC5838).

I would it is better to have two separate code-points for OSPFv2 and OSPFv3 in 
this case.

Thanks,
Ketan

From: mpls mailto:mpls-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: 09 September 2019 18:23
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; 
m...@ietf.org; 
draft-ietf-mpls-spring-lsp-p...@ietf.org
Cc: spring@ietf.org
Subject: Re: [mpls] Codepoint for OSPFv3 protocol in SPRING LSP-Ping and 
LSP-Trace

RFC 8287 is a product of the MPLS WG so in the absence of answer on the SPRING 
mailing list, I'm redirecting the question to the MPLS WG.

--Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha 
(Nokia - CA/Ottawa)
Sent: Friday, August 2, 2019 12:29 AM
To: spring@ietf.org
Subject: [spring] Codepoint for OSPFv3 protocol in SPRING LSP-Ping and LSP-Trace

Dear all,
I am not sure if this was discussed during the development of RFC 8287 - "Label 
Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 
Planes", but I could not find anything in the SPRING mail archive.

Prefix SID and adjacency SID which are originated in an OSPFv3 instance (IPv4 
or IPv6 instance) do not have a protocol ID assigned to them in the Segment ID 
Sub-TLV, as well as in the Label Stack Sub-TLV of the Downstream Detailed 
Mapping TLV.

Should we assign the next available IANA codepoint values or was there a 
rationale for omitting them?

Regards,
Mustapha.

_



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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Sander Steffann]

Hi Andrew,

> There is a phrase that I have heard – and perhaps it applies here – perhaps 
> we need to put our guns down – and find a way to in which we can move forward 
> that while it probably will not satisfy everyone, will be in the interests of 
> the market in general by avoiding a total standoff.

Thank you for your wise words. I have also gotten carried away in this 
discussion. I'll take a step back and think more carefully before I post. I 
just saw Robert's reply and I hope that in time he'll do the same. Guns down...

Cheers,
Sander

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Satoru Matsushima]

2019/09/11 0:35、Sander Steffann のメール:

> Hi,
> 
>> If you say you are an operator, and ask us to disclose on where, for what, 
>> scale and use case, please describe yours at first in very detail.
> 
> ISP in The Netherlands, between 50k and 100k customers three datacenters, 
> multiple interconnect locations, currently using MPLS for L2VPN (as little as 
> possible), L3VPN, mVPN (mostly for streaming media distribution). Nothing 
> fancy. I'd love to use SR with plain IPv6 as one step towards the ultimate 
> goal of running the network as simply as possible (i.e. just IPv6) while 
> still having the possibility to steer traffic with as little complications as 
> possible, keeping it easy to learn, easy to understand by NOC engineers, easy 
> to debug and easy to adjust. KISS.
> 
> Cheers,
> Sander


Thanks. 

We run networks in Japan nation wide for our customers, 5M+ on fixed broadband, 
30M+ on 3G/4G cellular, and enterprise business. Bunch of MPLS boxes are 
deployed in both access aggregation in all 47 prefectural regions (varied size 
from dense/sub-urban to rural) and backbone networks.(NOTE: not big compare to 
US/China). Currently L3VPNs run on top of L2VPNs over MPLS(-TP). After long 
time investigation and discussions internally/externally, we decided to adopt 
SRv6 more than two years ago. Now SRv6 networks are being deployed, up and 
running, as part of 5G roll out in addition to those networks, and plan to 
migrate existing customers to it.

Cheers,
—satoru
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Codepoint for OSPFv3 protocol in SPRING LSP-Ping and LSP-Trace

[Carlos Pignataro (cpignata)]

+1. We should have different codepoints for OSPFv2 and OSPFv3.

I recall we actually planned to do that not too long ago, but I cannot find the 
draft on which we split the codepoint.

From: "Aissaoui, Mustapha (Nokia - CA/Ottawa)" 
Date: Wednesday, September 11, 2019 at 2:31 AM
To: "Ketan Talaulikar (ketant)" , "bruno.decra...@orange.com" 
, "m...@ietf.org" , 
"draft-ietf-mpls-spring-lsp-p...@ietf.org" 

Cc: "spring@ietf.org" 
Subject: RE: Codepoint for OSPFv3 protocol in SPRING LSP-Ping and LSP-Trace
Resent-From: 
Resent-To: , , 
, , 
, 
Resent-Date: Wednesday, September 11, 2019 at 2:31 AM

Thank you Ketan.

I believe it would be appropriate to have a separate codepoint for each OSPFv2 
and OSPFv3 protocols. Within OSPFv3 we can distinguish the family IPv4 and IPv6 
based on the prefix of the SID.

Mustapha.

From: Ketan Talaulikar (ketant) 
Sent: Wednesday, September 11, 2019 12:21 AM
To: bruno.decra...@orange.com; Aissaoui, Mustapha (Nokia - CA/Ottawa) 
; m...@ietf.org; 
draft-ietf-mpls-spring-lsp-p...@ietf.org
Cc: spring@ietf.org
Subject: RE: Codepoint for OSPFv3 protocol in SPRING LSP-Ping and LSP-Trace

Hi Mustapha,

The RFC8287 refers to OSPF and not OSPFv2. Conventionally, we use the term OSPF 
when we are referring to both OSPFv2 and OSPFv3. I am not sure if this was the 
authors’ objective.

One might assume that OSPFv2 is purely for IPv4 and OSPFv3 for IPv6, but this 
is not true (see RFC5838).

I would it is better to have two separate code-points for OSPFv2 and OSPFv3 in 
this case.

Thanks,
Ketan

From: mpls mailto:mpls-boun...@ietf.org>> On Behalf Of 
bruno.decra...@orange.com
Sent: 09 September 2019 18:23
To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
mailto:mustapha.aissa...@nokia.com>>; 
m...@ietf.org; 
draft-ietf-mpls-spring-lsp-p...@ietf.org
Cc: spring@ietf.org
Subject: Re: [mpls] Codepoint for OSPFv3 protocol in SPRING LSP-Ping and 
LSP-Trace

RFC 8287 is a product of the MPLS WG so in the absence of answer on the SPRING 
mailing list, I’m redirecting the question to the MPLS WG.

--Bruno

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Aissaoui, Mustapha 
(Nokia - CA/Ottawa)
Sent: Friday, August 2, 2019 12:29 AM
To: spring@ietf.org
Subject: [spring] Codepoint for OSPFv3 protocol in SPRING LSP-Ping and LSP-Trace

Dear all,
I am not sure if this was discussed during the development of RFC 8287 – “Label 
Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 
Planes”, but I could not find anything in the SPRING mail archive.

Prefix SID and adjacency SID which are originated in an OSPFv3 instance (IPv4 
or IPv6 instance) do not have a protocol ID assigned to them in the Segment ID 
Sub-TLV, as well as in the Label Stack Sub-TLV of the Downstream Detailed 
Mapping TLV.

Should we assign the next available IANA codepoint values or was there a 
rationale for omitting them?

Regards,
Mustapha.

_



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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Ron Bonica]

Andrew,

I would like to amplify something that you said. SRv6 and SRv6+ are both 
designed to operate within limited domains. Beyond competing for market share, 
the existence of one does not threaten the existence of the other.

I do not oppose the progressing of the SRv6 drafts (while, as a WG participant, 
I do reserve the right to comment on them). I would hope that the proponents of 
SRv6 would extend the same courtesy to SRv6+.


 Ron




Juniper Business Use Only
From: Andrew Alston 
Sent: Wednesday, September 11, 2019 1:04 AM
To: Zafar Ali (zali) ; Aijun Wang ; 
'Robert Raszuk' ; 'Sander Steffann' 
Cc: Ron Bonica ; 'SPRING WG List' ; 
'James Guichard' ; Shraddha Hegde 
; 'Rob Shakir' ; 'Voyer, Daniel' 

Subject: RE: 答复: [spring] Going back to the original question for the Spring WG 
(was: Re: Beyond SRv6.)

Ok, so couple of things.

I really think we need to clearly and totally divorce the comments on this list 
from those around SRH – since – there seems to be this kind of bizarre 
conflating of two issues, and while it’s a nice piece of obfuscation – let’s be 
clear on a number of things.


  1.  Almost every  objection on this list that I have seen has related 
directly to the NP and uSID drafts – not towards the SRH draft which does not 
sit within this working group.  The primary problem I see with the SRH draft is 
around overhead – and well – if people wish to live with that level of overhead 
– so be it – but, that does not relate to the complexity, the violations of 
RFC8200 and the wholesale re-definition of the address semantics as defined by 
RFC4291 that have been objected to here – those issues are directly related to 
the NP and uSID drafts.  Let’s be clear on that.
  2.  The constant citing of a marketing document – where almost everything in 
there is related to the use of SRv6 in the context of the SRH – again – not in 
this working group – with little evidence or citation of use of the NP draft or 
the uSID drafts which are what we sound be discussing here – is, in my view, 
really stretching for support – through an obfuscation of items that while 
related are not the same thing

Now, there is also an argument I have seen that you should not have two things 
that solve the same problem.  So, lets talk about the CRH for a second.  CRH 
does not address the same issues that the NP draft does – it addresses an 
insane and inescapable overhead issue.  In the process of doing that, it 
provides, in my view, a cleaner version of the functionality of that contained 
in the network programming draft and the uSID draft, without header insertion 
and without the burning of absolutely insane amounts of address space.  So 
again – let’s not conflate issues here.

Now – I would ask this, and I have asked the questions before and not seen them 
addressed – if they have been – I would be more than happy to be corrected and 
be pointed to the emails that address these things

  1.  Can someone explain how with the use of NP proper aggregation is going to 
work
  2.  Can someone please – as per the request made by the chairs in Montreal – 
supply an indication of the address space burn that is required – both in terms 
of the uSID draft and the NP draft
  3.  Can the authors please explain how either of these drafts is proposed to 
work in either an inter-asn or inter-igp area scenario – or – is this 
explicitly and unequivocally designed to work only within a single domain – and 
if that is the case – I’d be happy to explain how this would work with CRH – 
and why there is an additional requirement for CRH beyond the removal of the 
overhead
  4.  In the case of uSID – can we get an explanation of how it is compatible 
with the network programming draft outside of end point programming – since the 
way I see it – if you’re shifting bits to effectively perform “routing by NAT” 
– you’re throwing away the locator bits as defined in the network programming 
draft.  If the answer to this is to retain the entire SID list – then the 
overhead reduction disappears – and at which point, please can someone explain 
to me why you would run uSID at all if you are doing this.
  5.  Since we have had constant references to multiple platforms supporting 
this – can we get a list of actual vendors and hardware that support the NP and 
uSID drafts in production today – not SRH – NP and uSID – and inter-op tests 
between these platforms.  Let’s separate the issues here.
I will also say – I do NOT oppose work continuing on SRH and SRv6 – never have 
– never will.  I also do not oppose work continuing on either the NP or uSID 
drafts – provided the issues that have been raised – time and again on this 
list are addressed.  However, I will also state that I do not believe that CRH 
performs the same function as the NP draft, what it does is include the 
functionality involved in the NP draft, while solving an overhead issue – and 
on 

Re: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

[Ron Bonica]

Pablo,

So, to make uSID work:


  *   You have to get a large block (e.g., /32) from your RIR
  *   You have to allocate a smaller block (e.g., /48)  to each router for uSIDs
  *   You can't use more specifics from that block for anything else (e.g., 
numbering interfaces)
  *   If you do, you may cause multiple SR paths to black hole

Do I have this right?

   Ron




Juniper Business Use Only
From: Pablo Camarillo (pcamaril) 
Sent: Tuesday, September 10, 2019 10:12 AM
To: Ron Bonica ; SPRING WG 
Subject: Re: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

Ron,

SRv6 is based on IPv6 longest prefix match forwarding. You can shoot yourself 
in the foot by adding bad routes.

Cheers,
Pablo.

From: spring mailto:spring-boun...@ietf.org>> on 
behalf of Ron Bonica 
mailto:rbonica=40juniper@dmarc.ietf.org>>
Date: Tuesday, 6 August 2019 at 22:46
To: SPRING WG mailto:spring@ietf.org>>
Subject: [spring] draft-filsfils-spring-net-pgm-extension-srv6-usid-01

Authors,

Referring to the example in Section 5.2 of 
draft-filsfils-spring-net-pgm-extension-srv6-usid-01, what would happen if Node 
7 instantiated the following:


-  A uSID  identified by 2001:db8:0700/48

-  A more specific route (e.g., 2001:db8:0700::/49)

Would the more specific route be ignored by the longest path lookup on Node 7? 
If not, would the more specific route cause all SR Paths whose penultimate 
segment is 2001:db8:0700/48 to black hole?


   Ron





Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Joel M. Halpern]

You are technically correct that the SR Architecture document does not 
require the separation of topological behavior from service behavior.


On the other hand, MANY of us have notied, and tried to find solutions 
for, the fact that the overloading of IP addresses for both identity and 
location causes significant problems.  Further overloading the same 
thing with service semantics as well makes this problem worse.  So yes, 
there are plenty of good reasons to be concerned about this overloading.


Yours,
Joel

On 9/10/2019 11:45 PM, Satoru Matsushima wrote:

Hi Aijun,

But the concept of SRv6+ is more clear than the SRv6(topology/service 
instruction separation;




The SR architecture never require such things. See RFC8402:

“Abstract

Segment Routing (SR) leverages the source routing paradigm. A node 
steers a packet through an ordered list of instructions, called 
"segments". A segment can represent any instruction, topological or 
service based.”



“3.1.3 . SRv6


  When SR is used over the IPv6 data plane:


  o A Prefix-SID is an IPv6 address.

  o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node 
addresses are not SRv6 SIDs by default.”




different instruction carried in different IPv6 EH).  It conforms to 
RFC8200 as well, seems will be less resisted within 6man WG.




SRH conforms RFC8200.


Will such enhancements accelerate the deployment of SR related 
technologies in service provider network? Anyway it is called SRv6+ J.




SRH has already accelerated SRv6 deployments.

Best regards,
—satoru

We have our own solutions for the similar scenarios that the SR 
technologies aims to solve, but will also keep eye on the advance of 
SR/SRv6/SRv6+ technologies.


Best Regards.

Aijun Wang

China Telecom

*发件人:*spring-boun...@ietf.org  
[mailto:spring-boun...@ietf.org] *代表 *Robert Raszuk

*发送时间:*2019年9月11日1:34
*收件人:*Sander Steffann
*抄送:*Ron Bonica; SPRING WG List; Andrew Alston; James Guichard; 
Shraddha Hegde; Rob Shakir; Zafar Ali (zali); Voyer, Daniel
*主题:*Re: [spring] Going back to the original question for the Spring 
WG (was: Re: Beyond SRv6.)


Hi Sander,

You keep saying SRv6 is complex. But it is only as complex as you are 
going to make it or as you will need it to be.


No one is mandating you to do any network programming or to use 
multiple TLVs. If you just need to use SR for basic TE you insert one 
or two SIDs and you are done. If you want to also enable L3VPN you 
configure it in pretty much identical way regardless if this is SRv6 
or SRv6+.


I know I am not going to convince you, but just for the record it is 
worh to note that what get's send on the wire is only the information 
what you as the vendor need. The fact that spec has prepared encoding 
to also be useful for not only you but other operators does not make 
the solution "complex".  Otherwise we will end up with protocol per 
customer which would be pretty bad I am afraid.


See many people say BGP is complex  and it is the same here - BGP 
is as complex as you require it to be. You can enable BGP 1/1 with 4 
lines of config. But if you need other address families if you need 
fancy policy you have all required tools for that on your keyboard.


- - -

Now point about SRv6+ ... see writing a drafts for it easy, Further 
even writing interop draft with SRv6 is also not that complex - day or 
two and you submit. But please tell me why any vendor who has been 
working in open IETF process on any new service for over 5 years now 
would have to put a lot of development resources on the table to 
develop data plane and control plane enhancements for essentially 
subset of functionality at best ?


It is nothing about anyone's good will or not ... it is all about 
limited resources. Features and extensions are not added to any vendor 
based on the RFC translation engine. It is pretty difficult and 
painful process. So without huge market demand behind it I would be 
highly surprised if any vendor who committed to SRv6 already would now 
take real on support for SRv6+.


Thank you,

R.

On Tue, Sep 10, 2019 at 6:21 PM Sander Steffann > wrote:


Hi,

> No. And that is why I want SRv6+ to move forward, to avoid getting 
trapped in the SRv6 walled garden.
> 
> The way IETF works (at least in vast majority of WGs) is that if you do not like a specific element of a solution or if something is missing from any solution during WG process - you contribute to it to either fix it or to make sure the WG product is the best possible.
> 
> So nothing prevented you for all the years IETF has been dealing with SRv6 process to take an active part in its standardization.
> 
> Asking for adoption of solution which brings nothing new to already shipping solution of SR-MPLS when it would travel over IPv4 or IPv6 is at best counterproductive.


No, something that today can 

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Ron Bonica]

Robert,

Are you suggesting an attempt to merge the best of SRv6 with the best of SRv6+? 
This might be a good idea.

 Ron


From: Robert Raszuk 
Sent: Tuesday, September 10, 2019 12:10 PM
To: Sander Steffann 
Cc: Voyer, Daniel ; Ron Bonica ; 
SPRING WG List ; Andrew Alston 
; James Guichard 
; Shraddha Hegde ; Rob 
Shakir ; Zafar Ali (zali) 
Subject: Re: [spring] Going back to the original question for the Spring WG 
(was: Re: Beyond SRv6.)

Hi Sander,

No. And that is why I want SRv6+ to move forward, to avoid getting trapped in 
the SRv6 walled garden.

The way IETF works (at least in vast majority of WGs) is that if you do not 
like a specific element of a solution or if something is missing from any 
solution during WG process - you contribute to it to either fix it or to make 
sure the WG product is the best possible.

So nothing prevented you for all the years IETF has been dealing with SRv6 
process to take an active part in its standardization.

Asking for adoption of solution which brings nothing new to already shipping 
solution of SR-MPLS when it would travel over IPv4 or IPv6 is at best 
counterproductive.

It is like now you would be asking to adopt some individual drafts which woke 
up and defined new data plane and new control plane for services you are 
running in your network - and call those MPLS+, L2VPN+, L3VPN+ and mVPN+ 
without any new functionality.

Would it make sense ?

Kind regards,
Robert



Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

[Ron Bonica]

Folks,

Can I ask those who have deployed SRv6 how they address SRHs that contain more 
than 5 or 6 SIDs?


 Ron

Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring